Bug#597301: apt should not ignore NotAutomatic and ButAutomaticUpgrades if key is missing
On Mi, 2010-09-22 at 14:02 +0200, David Kalnischkies wrote:
> 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).
I guess we might be able to just compare the mtime of release files as
well when checking whether a package file is valid. Or we store
MtimePackages=max(MtimeRelease,MtimePackages) and treat the cache as
up-to-date if the package file is older than the time stored in the
cache.
We could also just rebuild the caches during an apt-get update run.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Reply to: