Clarify our position on forks (was: Re: Plan for tomorrow's FESCo meeting (2012-02-27 at 18UTC))

[Stephen Gallagher]

On Mon, 2012-02-27 at 15:18 +0000, Matthew Garrett wrote:
> On Mon, Feb 27, 2012 at 08:14:13AM -0500, Stephen Gallagher wrote:
> 
> > Personally, my stance on this is that, provided that the forks are
> > properly renamed such that they will not conflict with other forks of
> > the same codebase, there's no reason to disallow them. As mentioned by
> > Toshio in the ticket, carrying forks provides a much better alternative
> > to bundled libraries in the situations where the primary codebase is
> > lacking certain features.
> 
> There's exactly the same reason to avoid closely-related forks as there 
> is to avoid embedded libraries - if you have a security issue you now 
> have more places to fix the same bug. The question is whether that cost 
> is larger or smaller than the gain from carrying the forked code.
> 

This is true, but it's also much more visible that the bug needs to be
fixed. With a static library, the community as a whole may be unaware
that the library is even in use under the hood.

> Simple thought experiment: memcpy() has always obviously had destination 
> and source the wrong way round. I can easily fix that in a forked glibc, 
> but then I need to rebuild the entire stack on top of that to fix up all 
> the callers. I think everyone would agree that that was unreasonable. 
> 

I think this is a bit of a straw-man. As I mentioned in my earlier email
(maybe I was ambiguous), I think that forks should be permitted so long
as they are parallel-installable. This means that they should not rely
on any of the same headers or use the same shared library name.

With this caveat, it becomes possible to have two parallel glibc stacks
on the system (ridiculous though that may be). You would have to choose
to build against libc-fixedmemcpy.so instead of libc.so.

> There's a continuum here, rather than a bright-line test. Any decision 
> we make (other than "accept everything" or "reject everything") is 
> going to be somewhat arbitrary.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120227/3de4799d/attachment.sig>