[Proposal] Ring-based Packaging Policies

[Stephen Gallagher]

On Fri, 2015-02-13 at 13:54 +0100, Ralf Corsepius wrote:
> On 02/13/2015 10:56 AM, Petr Spacek wrote:
> 
> > Modified version of Zbyszek's idea with time constraints follows:
> >
> > 1) Accept the new package into Fedora N even with bundled libraries.
> 
> I am inclined to be Fedora needs to encounter a serious vulnerability 
> originating from bundling, such that you guys comprehend, why bundling 
> is utterly stupid ;)
> 
> 
> For those who don't know what I am talking about:
> Many years ago (IIRC, ~1999), nobody cared about static linkage or 
> bundling. At this time, it was common to statically link and/or bundle 
> libraries.
> 
> Then a critically vulnerability was found in libz affecting all Linux 
> distros. Nobody knew which packages all bundled and/or statically linked 
> against different versions of libz. It took months for all Linux 
> distributions to identify their vulnerable packages, to find solutions 
> and to release security-fixes.
> 
> Meanwhile, we've had much more critical vulnerablities in widely used 
> libs (Remember heartbleed), which all have been quite easy to fix 
> packaging-wise. IMO, to a great portion, thanks to having mostly banned 
> static linkage and bundling.

I'd like to point out something that I think you missed in my initial
email. I'm not saying that anything should be allowed to bundle software
transparently. The primary problem we faced back in '99 was that *we
didn't know what was bundling libz*. With an enforced virtual Provides:
bundled(foo) we can at least get an accurate listing of the set of
packages that would need to be updated in the event of a vulnerability.

Also, as mentioned in another thread, I'm certainly open to the idea of
making some specific exceptions to the rule (such as "you may not bundle
packages like libz that have a long history of vulnerability"). In other
words, I think it might be reasonable to have bundling in the outer
rings be a blacklist rather than a whitelist, so long as we can always
find out with a simple repoquery what contains a package.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150213/acd03263/attachment.sig>