All,
What!!! There has there been no progress... in two weeks!!! That's right... it has been only two weeks since the last commit to do with package signing was pushed to the master git repo (http://projects.archlinux.org/pacman.git/commit/?id=70cf4546). In fact, it currently 10 days, so it was 9 days when the original emails to this thread were sent. Shock, horror development has stalled! Although work is happening, I think it's fair to say that it's not happening fast enough to cause problems with duplication. Also, compared to the amount of effort I would like to see going towards this idea, and the amount of effort I am willing to personally put into it, the work the main pacman devs are doing appears to be very little.
Note that how Arch will deal with signing in their repos is being finalised elsewhere, but to reiterate, that has nothing to do with the pacman implementation. Where?
This is why it needs to be kept completely separate from discussions about implementing signature verification work in pacman. Eh? pacman-dev is the most relevant list I've found for discussion of this issue. The key-signing mechanism in pacman (in particular, its ease-of-use) has a direct impact on its adoption, and the two conversations should not be separated.
With regard to key schemes, the security of your system is the security of any package you install into it; in particular, if an attacker has a developer key and controls any part of the connection between you and the central archlinux.org repository, they can modify the .install of the next package you happen to update, and do whatever they want to your system, including altering your GPG install, so there's no point to any sort of specialized key scheme. There will be a list of developer keys, and anyone who can log in to the central repository can change that list, so the responsiblity of key verification will fall on whoever manages the central repository. Revocation just means deletion from this list, and, as Ari correctly points out, a complexer revocation scheme is unnecessary [1]. The security of the central repository and of its contents are hairier issues, and since I don't know how this is implemented, I ask that someone inform me of how the central repository is managed (and of who has the ability to perform this management). It's probably already secure, though. With regard to verifying packages, it should be possible to verify signatures without root privileges as long as root is not updating pacman's keyring. This should be possible without any downsides or crude hacks. If it is necessary to attach an Arch-specific patch to Arch's GPGME package, then that can be done. Ari, you can do this if you want, and if not, I'll complete the task. Also, Ari, I would recommend not spending time theorizing about solutions to small issues such as this: it's better just to code out a solution (and of course test it) and then submit a patch. Discussion about how to implement an idea in code is rarely needed: just do it. For now, let's all just publish our changes to this list so that they can be integrated into the master branch of pacman's git. If people have a lot of code that is not polished enough for pacman's master branch, but that they'd like to share anyway, I'll set up a separate git repository that we can work out of, publishing finished code as patches when necessary. If you are interested cryptography and security, I would highly recommend reading Applied Security by Bruce Schneier (the protocol-related portions can be understood without reading the sections on mathematical and algorithmic underpinnings). Happy hacking and best wishes for Allan's health, Kerrick Staley [1] If a the compromise of a key is discovered and you are informed before updating your system, then a secure channel for key revocation that is independent of the repositories (best done with revocation certificates) would be useful, but this is irrelevant for practical and theoretical reasons. Practically, most people update daily, so there is a very small window in which the discovery of a compromise will be useful. Also, compromises should be rare enough that when they do happen, a news item can be posted on the Arch homepage informing users on how to manually revoke the keys [2]. Theoretically, there's no way to tell whether a compromise happened when you think it did or sometime before. [2] The Arch homepage is insecure (no SSL), so this is a further issue. However, this is all getting to be too scenario-specific; fine-grained analysis such as this should be done only after we have a basic implementation of package signing working.