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