On Sat, Dec 1, 2012 at 7:32 AM, Tomáš Chvátal <tomas.chva...@gmail.com> wrote: > Bundling few libs and bundling 40 of them is bit of difference, will YOU do > the audit?
We don't require security audits for packages to be in portage. Any package can have a security problem, whether it is in a bundled lib or otherwise. Besides, if we can trust Google to audit their bundled libs, why can't we trust other upstreams to do the same if they do not have a bad reputation? And the last time I checked chromium had a ton of bundled libs - just extract the source tarball and note that about 90% of the file size is in the 3rd party tree (and as I said, to their credit the chromium team has done a wonderful job of eliminating the need to build a fair bit of that). > Still keep in mind most distros won't allow inclusion of such software into > main repositories at all, so we allow something fishy others avoid a lot. Yeah, but with other distros there is a much stronger tradition of alternate repositories. Half the stuff we stick in portage isn't in main repository for distros like Debian/Ubuntu. The other issue is that we're always tweaking ebuilds so that we can do dependency bumps. Packages not in portage don't benefit from that, so they're much more prone to breaking. A distro like Debian/Ubuntu freezes the core libs so that alternate repository maintainers only have to mess with their packages a few times per year on a well-defined schedule. And if we force some types of packages to be masked all the time, then what do we do if we actually need to mask them for removal or security. Users won't even realize they have a known flaw, because they had to unmask the package just to install it. I think there is a big difference between "bundles libs and therefore might have a security issue" and "has a known security issue." I also am not convinced that bundling libs actually exposes you to more security issues. It simply makes it more likely that you'll be exposed to a discovered security issue. If I have a million lines of code that is a million places I could be vulnerable. If I half half a million lines of original code and half a million lines of bundled libs, that is a million places I could be vulnerable, except that at least the libs have gotten more eyeballs. The reason that zlib issues get talked about is that people actually security audit zlib. Nobody security audits stuff like amarok so it could have 10x as many security holes and nobody would notice, but if it bundled a vulnerable zlib version suddenly everybody would notice that. I'm all for trying to unbundle things, but I don't think failure to do so is a reason to mask a package. That is an upstream quality issue, and if we can improve on it great, but if not, well, I think emacs is painful to use but I'm not going to ask for it to be masked until we can patch in the vim key bindings. I recall having a similar email discussion to this one years ago. I think an issue is that everybody wants quality but no two people can agree on what exactly the standards should be. I think we almost need some way to flag packages by quality level. If you could tag a package with "includes unaudited bundled libraries" the way you can tag it with "has a non-free license" then end users could choose the stance they want. Of course, to do that right you'd probably need context. As drobbins pointed out in the bug report my stance towards a media player is likely to be different from my stance towards a web server/browser or email client. And yet, I do use chromium as my browser despite the fact that it still bundles a ton of libs. Rich
