Bug#597301: apt should not ignore NotAutomatic and ButAutomaticUpgrades if key is missing
Hi,
2010/9/18 Carsten Hey <carsten@debian.org>:
> I just played a bit with Release files to be able to test this feature,
> it seems to work :)
Thanks for testing, good to hear that it works. :)
> 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.
Mhh, maybe the reasoning is that a man in the middle could send a wrongly
signed security.debian.org Release file with NotAutomatic which would
take effect. The counter argument would be that he could send also an
unsigned release file and drop the request for Release.gpg which wouldn't
even issue a missing key warning… (who will notice the Ign Release.gpg?)
Maybe security wise APT should ignore unsigned files and files it isn't
able to check the signature always - expect file:/// maybe instead of
giving unsigned files the favor of accepting them unconditional…
(or it should at least get [yet another] option for it).
> I found also an other minor issue, if the Release file in the archive
> changes but the Package file does not, it is necessary to remove
> /var/cache/apt/*bin to let apt use the new setting. This does not look
> like a bug that is worth the effort to fix it since such situations
> normally should not happen. Though, one way to fix it, would be to stat
> the Release files and compare the mtime of these files every time the
> cache is used.
Thats what Modestas Vainius describes after adding the key file.
The Packages files aren't changed so apt considers the caches still
valid - i guess the easiest workaround is nuking always the caches in
apt-get update so they get rebuild. Probing for mtime is a problem as
the caches have no record which Releasefiles were used to build them,
so if the user removes the release file apt didn't know that and the
caches would be considered still valid. I haven't checked it but i guess
introducing Release files to be PkgFiles which are checked is a bit harder
than allowed for squeeze (apt-get check -s -o Debug::pkgCacheGen=1).
Best regards
David Kalnischkies
Reply to: