[Proposal] Ring-based Packaging Policies
sgallagh at redhat.com
Fri Feb 13 15:13:12 UTC 2015
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
> 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...
Size: 181 bytes
Desc: This is a digitally signed message part
More information about the devel