| > Funny that you call the packaging scheme the "classical model" - to me that's the "[relatively] new and weird" scheme. I'd say that "everybody builds their own binaries" is the classical model. I stand corrected. > In my life, it never comes up. I am either using a personal machine or managing a server which is responsible for one single service. I just went back through my own update log a couple of months: You don't use anything that uses libxml [1], ffmpeg (audio/video Swiss army knife) [2], poppler (popular PDF library) [3] or openSSL [4]? Do you pay attention to the security notices of every program you have that bundled one of those? Are you sure that upstream is paying attention to the security ntoices of those libraries? > The idea that upgrading one library could affect the behavior of hundreds of programs is terrifying. How do I know they all still work? I don't. I have to go test them all. What this means is that I never update any libraries at all, on a linux machine, because I can't know in advance what the upgrade might break. For non-rolling distributions (for example Debian stable, Ubuntu, Fedora, RedHat) packages don't have their behavior changed throughout the lifetime of a release <6>. Security and bug fixes are backported to whatever version is in place for the lifespan of the distribution's release. This is part of the point of stable releases, and something that's routinely forgotten by those who hound package maintainers for newer versions of things! As an example, let's consider [1]. Ubuntu 13.04 uses libxml2 version 2.9.0 plus some Debian/Ubuntu patches. They released version 2.9.0+dfsg1-4ubuntu4.1 with the following changelog [5]: * SECURITY UPDATE: multiple use after free issues
- debian/patches/CVE-2013-1969.patch: properly reset pointers in
HTMLparser.c, parser.c.
- CVE-2013-1969
Only the security fix is applied, and after upgrade you know that libxml2 will continue as it has done for the lifetime of your distro release, except it's no longer vulnerable to CVE-2013-1969. Moreover, this applies to every program using libxml (i.e. a lot) with one update. Again: There's no other change in behavior for libxml!> This is exactly what I get on Mac OS X, and it's what I get when I build apps with statically linked libraries on Linux: stuff works until I break it, and then I know what I broke, so I can fix it. Stuff seems to work until you break it. Then a security hole is found, and it turns out things aren't really working very well at all. To me it seems like a lot of work to keep track of such things by yourself! [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1969 [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2496 [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1790 [4] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0169 [5] https://launchpad.net/ubuntu/+source/libxml2/2.9.0+dfsg1-4ub... <6> Firefox and a few other packages, mostly web browsers who are making it hard to provide security backports, are notable exceptions. |