[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#597301: apt should not ignore NotAutomatic and ButAutomaticUpgrades if key is missing

severity 596097 important


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 

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.

Reply to: