On Fri, Mar 31, 2000 at 08:22:14PM -0700, Jason Gunthorpe wrote: > How exactly do you propose to transfer a verification key to the clients? > I can't think of any decent way to do this that isn't prone to some kind > of hack-a-mirror thing or involves annoying extra steps. Just about everything is prone to the hack-a-mirror thing at the very first point. If you hack-a-mirror and change James' key in debian-keyring, and no one has a copy of debian-keyring already do compare it against, you're stuck. The dinstall key could be verified by: * the web of trust, and having the ftp-team sign it * putting a fingerprint on the website and in Debian books, and making it easy for people to verify said fingerprint * getting copies of the key from multiple sites, and checking that all the copies you got are the same None of these are completely foolproof, of course. > In > particular, we could have a relatively insecure daily use dinstall key > [for unstable] and a strong release key (aka the key the security team > uses) When we do a release all the package files are signed using the > security key and we have a nice sealed package that can be checked quickly > and efficiently by the users. This key (or the private half thereof) wouldn't need to be anywhere near any public machines, either. > The trick however is to distribute the security key automatically and > efficiently. [The dinstall key can be derived from this one] Ponder > Ponder. Stick it on the ftp site, and use the web of trust. (If the secure-key that you currently have trusts it, then it's good. Either because it's an update of the old secure-key, or because it's an unstable-key). `Using' the web of trust is probably easier said than done, though. > Incidently the dinstall change is all of (basically) > cd .../dists/unstable/ > find -name "Packages" -or "Packages.gz" | xargs mymd5sum | gpg --clearsign > Packages.sig I'd have done: find -name Packages -o -name Sources -exec gpg --detach-sign --armor {} \ -o {}.gpg or so before gzipping anything. > APT would need to download this file, verify, then load the md5s > internally for checking the package files. I'd have made it download a Packages.gpg as well as Packages.gz and Release, and if: (a) Apt::Require-Gpg=true (or something) and: gpg isn't installed, or the unstable key/security key doesn't exist, or Packages.gpg doesn't exist or (b) The .gpg isn't a signature of the Packages file by one of the proper security or unstable keys then die horribly. Updating the key would need to be a completely separate operation to downloading packages (it'd have to be done first, in case the keys outdated, and it'd have to be verified differently). Or at least, that's how I was toying with doing it a while ago, and apart from not knowing how to make an Apt option, or wanting to do a system call properly and elegantly (as opposed to using system()) it was working fairly well. Cheers, aj -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds
Attachment:
pgp6quTw1ZzOX.pgp
Description: PGP signature