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-ag..., 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