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.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
