[pacman-dev] GPG remote signing

[Dan McGee]

I've done a fair amount of research on what we might be able to do
with this during the afternoon here. Some observations below. This is
mainly addressing point four in Thomas' prior email
(http://mailman.archlinux.org/mailman/private/arch-dev/2011-May/014193.html).

There are hacks for forwarding a gpg-agent socket involving socat
(original one here
http://superuser.com/questions/161973/how-can-i-forward-a-gpg-key-via-ssh-agent,
more secure one here
http://www.debian-administration.org/users/dkg/weblog/68). The
problem? gpg 2.0.x and down (the current version) store only
passphrases in gpg-agent; either way, the gpg2/gpg binary itself still
needs access to the secure keyring to perform the encryption and
generate a signature for the file. So this seems like a dead end for
the time being. Rumor is 2.1 will fix this problem
(http://www.debian-administration.org/users/dkg/weblog/68#comment_5),
but I don't think we're in a position to wait for that.

I've seen suggestions revolving around signing remote files that say
the following instead- rather than sign the large file directly by
either putting your key out there, or pulling the big file to you,
sign a secure digest of the file. Something such as dropping the
SHA512 hash into a file, copying that to the machine with the key, and
then signing that instead. In a way, this is what GPG signing does
anyway (gpg --edit-key <yours>, showprefs, look at the "Digest" line;
also, the --show-mds option). The problem is GPG doesn't allow you to
separate the digest generation from the actual signing process, which
sucks.

This doesn't fully work for us- at least right now. I see a few
possibilities as to how to proceed.
1) suck it up, sign your packages locally.
2) live dangerously, copy your secret key out, use it to sign, delete
it from that location (you better have a passphrase).
3) do the above "sign the hash trick"; one would then upload the
package from location A, and the "special signature", we'll call it,
from location B. When these two files are on the main server, a master
key/verification program (running in a walled-off VM with very little
access) would basically say "is this special signature valid, and is
it blessed by our trust", and if so, truly sign the package (and the
special signature would not longer be needed). This is somewhat
similar to what Debian does with their dsc files (signing a little
more than a single hash, see for yourself:
http://ftp.us.debian.org/debian/pool/main/m/magit/magit_0.7-1.1.dsc)
4) do the above "sign the hash trick"; and teach pacman how to verify
both "real" signatures and "special" signatures on files.
5) ???

Thoughts? Other ideas? Things I'm forgetting? I'll withhold my
preference of option for now to prevent biasing any comments; the
above should not be seen as order of preference.

-Dan