Setting APT::Default-Release in Ubuntu blocks all future security fixes and updates.
This is related to all versions before Hardy (include). I haven't tested this on Intrepid so I'm not sure about those versions after Hardy.
According to apt_preferences manpage, the target release can be set on the apt-get command line or in the APT configuration file /etc/apt/apt.conf, and "APT::Default-Release "stable";" is given out as an example. This is a very common and popular practice used in Debian community to set the default release and using apt-pin, but doing this in Ubuntu leads to serious security impact with no obvious warning.
After setting APT::Default-Release to "hardy", which is the "Suite" name for main hardy source, no security fixes nor updates would be installed unless their priorities are also set explicitly in apt_preferences. This is because that in Ubuntu's world, security fixes are from "hardy-security" source and other updates are from "hardy-updates" source, which bear different "Suite" from the main source. Setting APT::Default-Release rises the priority of packages from main source to 990, but doesn't cover packages from hardy-security and hardy-updates, so the latter are ignored since their packages now has lower priority (priority 500 only) than those old ones in main source (990).
I set APT::Default-Release to "hardy" on Sep this year until I found this problem today. Removed that setting and I'm surprised to found that I can install 46 security fixes and updates accumulated. Which is pretty sad to me that got known I haven't got security fixes for more than 2 months.
This is a radical deviation from the Debian practice. In Debian all security fixes and updates bear the same "Suite" (etch or lenny) so setting APT::Default-Release to "etch" covers all security fixes and updates.
I think it's unlikely that Ubuntu changes the organization of it's source, so at least a fix to this problem is patching the apt_preferences manpage, alerting people not to use APT::Default-Release like they have used this in Debian and the reason and the following impacts.
I've opened a bug about this: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/295448
Subscribe to:
Post Comments (Atom)
2 comments:
Since this showed up as the first result on my search, I thought I'd add this.
There's a community page on the ubuntu help site about pinning:
https://help.ubuntu.com/community/PinningHowto
It recommends you don't use /etc/apt/apt.conf, but rather the /etc/apt/preferences file. This file has a different syntax.
I copied my /etc/apt/sources.list to /etc/apt/sources.list.d/testing.list and replaced "jaunty" with "karmic". In this way I can still pull from karmic-security should I need to.
I install with either "apt-get -t karmic install package" or if that fails due to library conflicts, "apt-get -t karmic build-dep package && apt-get -t karmic -b source package".
Here is my preferences file for example:
Package: *
Pin: release a=jaunty
Pin-Priority: 900
Package: *
Pin: release a=karmic
Pin-Priority: 500
Package: *
Pin: release a=jaunty-updates
Pin-Priority: 900
Package: *
Pin: release a=karmic-updates
Pin-Priority: 500
Package: *
Pin: release a=jaunty-backports
Pin-Priority: 900
Package: *
Pin: release a=karmic-packports
Pin-Priority: 500
Package: *
Pin: release a=jaunty-security
Pin-Priority: 900
Package: *
Pin: release a=karmic-security
Pin-Priority: 500
Package: *
Pin: release a=jaunty-proposed
Pin-Priority: 900
Package: *
Pin: release a=karmic-proposed
Pin-Priority: 500
To Bob/Paul:
Thanks for the comment. Your solution is correct for solving this problem. The reason I filed a bug for this is that Ubuntu has changed the Debian way (which is popular among Debian users) for no good reason and caused misunderstanding.
Post a Comment