severity 596097 important thanks Hello, On šeštadienis 18 Rugsėjis 2010 17:38:51 Carsten Hey wrote: > There is one somehow related bug, which does not seem to be a problem > for backports.debian.org but a possible one for other repositories that > use a different key: apt ignores NotAutomatic and ButAutomaticUpgrades > from Release files (or rather the whole Release file) if it is signed > but the key is missing. > > I'm not sure what the reason to ignore signed Release files with missing > key is, but at least NotAutomatic and ButAutomaticUpgrades from such > repositories should not be ignored. > > To reproduce it in a more clean environment I removed all keys in > a fresh sid debootstrap, ran apt-get update and then added experimental > to the sources.list. After an other apt-get update, apt-cache policy > abook printed the following: > > abook: > Installed: (none) > Candidate: 0.6.0~pre2-1 > Version table: > 0.6.0~pre2-1 0 > 500 http://ftp.us.debian.org/debian/ experimental/main i386 > Packages 0.5.6-7 0 > 500 http://ftp.us.debian.org/debian/ sid/main i386 Packages I can confirm this bug. I'm rising the severity to important for now but only because it does not affect official archive. Otherwise I would consider it grave. However, I still view this a security issue where a glitch in the network connection or even smart remote attacker could cause NotAutomatic and ButAutomaticUpgrades repositories to get 500 priority and hence automatic installation against the will of the repository administrator. In general, Carsten put the main problem together very nicely. Release files are completely ignored if they are signed but the key is not available. As a result, Release-based pins and NotAutomatic/ButAutomaticUpgrades do not work. I also do not understand how this situation is worse than repository having no key at all (because then Release file is not ignored). But a much severe (IMO) problem follows next. User sees apt-get update message about missing key and installs the key via apt-key or via supplied package (aka $archive-archive-keyring). Then (s)he runs apt-get update again. But guess what... apt-get update seems to _revalidate_ the signature of the Release file but it does NOT (re)parse it. Which means that even with the key present Release-based pins still do NOT work nor NotAutomatic/ButAutomaticUpgrades have any effect nor apt-get update complains about signature. The only way to trigger reparse of the Release file is updating it on the server which would force apt-get update to redownload the file. This is obviously out of user control as well as it is out of control of repository administrator unless you consider `touch Release` each minute a solution. So now until Release file update happens on the server, apt considers the repository: 1) to have priority 500 (neither NotAutomatic/ButAutomaticUpgrades nor release-based pins can pin it down); 2) to have valid signature; so the next apt-get dist-upgrade will pull higher versions from this repository without a single warning (yes, even without invalid signature warning). I consider the latter a real show-stopper for sane maintenance of third party repositories. In general, Release files are too important to be ignored on signature errors since generally they might be used to bring repository priority down! I agree with Carsten here, apt should at least always accept NotAutomatic/ButAutomaticUpgrades despite signature problems. What's more, apt-get update should reparse Release more frequently to avoid running into situations like this. -- Modestas Vainius <modestas@vainius.eu>
Attachment:
signature.asc
Description: This is a digitally signed message part.