On Mi, 2010-09-22 at 14:02 +0200, David Kalnischkies wrote: > Hi, > > 2010/9/18 Carsten Hey <cars...@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/. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
