Re: [Gnu-arch-users] signed archives and key management

[Johannes Berg]

On Tue, 2004-01-20 at 00:12, Colin Walters wrote:
> Now suppose that you use the above script as your =default.check.  What
> that means it that *any* of those users in your keyring can sign a
> change for *any* archive.

Yes, I also see this as a problem. In my archive at
http://johannes.sipsolutions.de/archives/address@hidden
there's a revision that says:
address@hidden/tla--smallfeatures--1.2--patch-3

This patch adds environment variable support to arch_exec_shell_command,
which works just like in arch_run_hook.
We then use this functionality to export a variable $ARCH_ARCHIVE to the
signature verification function, where it can be used for archive-dependent
keyrings.


What I've done then is link the archive name to a new keyring, and use
the command
        gpg --no-default-keyring --keyring 
/home/johannes/.arch-params/allowed-keys/$ARCH_ARCHIVE

So. What you propose (only checking a limited subset of keys) has been
done on my machine since around Jan 7th.

> So what's the solution?  You could separate out the keys for the
> developers associated with a particular project.  For example, 
> you could separate out Tom Lord's key into a keyring of its own:

Exactly, thats what I do, except my directory is below .arch-params and
has links to the various people from their various archives.
This has the advantage that when I use a new archive, I need to create a
new link, otherwise gpg will just complain that it couldn't find the key
(which is IMHO a good thing, it reminds me to check that key and put it
where it belongs before using an archive).

Oh, what you can currently do is have a default rule of this:
  echo "no rule for this archive" && false

> Then, you change your ~/.arch-params/signing/address@hidden
> to:

This part isn't needed if you know the archive name in the default.check
rule.

> Once we've downloaded the keyring, then for every future operation on
> that archive, we check whether it's been modified since then (doable for
> HTTP and perhaps sftp), and if so then we download the newer copy into a
> temporary location, show the user its contents, and prompt them to
> verify.

Still, if you reference a mirror and sometimes people don't know the
original archive name, so they have to use the mirrored keyring as
well... So the problem comes back, just harder to spot.

> This will make life a little more painful for people who aren't
> mirroring an archive locally.  But if you do mirror an archive locally,
> it should be quite usable.

With my scheme, I just link address@hidden to E9FAF129 (toms
key-id)

> The advantage of this whole scheme is that it greatly increases
> security.  The disadvantage is that AFAIK the keyring format is
> GPG-specific.  An alternative here would be to have the user provide a
> URL to a directory of ASCII-armored keys.

Well, I still think my approach is superior for people who care. And for
those who don't let them use the default keyring.
And besides, for people using other signing mechanisms it would be more
flexible as well, for openssl you could use
  openssl verify -CAfile /bla/bla/$ARCH_ARCHIVE

> First, assuming my above proposal is integrated, what I'd like to do is
> have tla understand how to invoke GPG to verify revisions against the
> keyring associated with that archive, without the user having to write
> any shell scripts or anything.  It should Just Work.

Actually, I don't think it should "Just Work". Because just working is a
sign that there's been no user verifying the integrity of the whole
trust chain. Actually, I'd much rather have

 a) tla write a default.check rule of
     gpgv --keyring ~/.arch-params/allowed-keys/$ARCH_ARCHIVE
 b) tla explain what it just did, printing an explanation of
    what to do (ie. verify the key if possible, and do
      gpg --export KEYID > ~/.arch-params/allowed-keys/KEYID
      cd ~/.arch-params/allowed-keys/
      ln -s KEYID archive-name
    etc.)
 c) tla to dump the output of gpgv to /dev/null _unless_ gpgv returned
    with an exit code != 0.

Right now you (in theory) need to check all the output gpgv makes,
because thats the only way to catch the problem. If that output would go
away in favour of per-archive keyrings, I'd be much happier :-)

Bottom-line: I think the security features shouldn't be too easy to use.

johannes
-- 
http://www.sipsolutions.de/
Key-ID: 9AB78CA5 Johannes Martin Berg <address@hidden>

signature.asc
Description: This is a digitally signed message part