I wrote about this topic ~1 month ago. You don't need PKCis or distribute the keyrings themselves. GPG supports transitive trust. The pacman keyring would be installed by default trusting on whatever keys a pacman root signature has signed (there could also be a different master key for community developers). The basic idea here is that you are not trusting the repository, but the individuals themselves. The master key -which can be kept offline and is only used when a developer joins/part- provides a basic default (people we generally trust) but a power user could reconfigure it to not accept packages signed by Pierre, because he distrusts him :), or he can add additional trusted people (a much more likely scenario) by just adding that person key to its keyring. A developer asks you to try a beta package -> You need to do nothing since you already have its key. Fetching from personal repo from a developer -> You need to do nothing since you already have its key. That really smart guy from the forum whose advice you follow blindly. -> Add its key. Packages built by you -> Add your own key. Sysadmin -> Add its key to the computers he administers. Paranoic sysadmin -> Add its key and remove the developers one. Then resign all packages after verifying that they work. I think this is more or less what Florian Pritz proposes, althouugh I think he was thinking in terms of the user gpg, while I would go using a different, pacman gpg. Denis A. Altoé Falqueto wrote:

The central point is the management of the keyring.

We could have a single key that all developers share, but this is troublesome as it would require some trusted channel to exchange the password (the first time and in the event of it changing). This approach is what others big distributions do, but the have a different structure than ours.

With this structure the developers never share the keys. You could even remove the master key and consider someone a developer when n developers signed him. But I find the master key method clearer.

We could have a keyring with all the trusted keys of the developers, but this could bring some problems as the keyring should be very well synchronized with the official one. Including a rule to upgrade the keyring package before others, as pacman. This requires intervention on user`s systems, so I think that it should be avoided, if possible.

There are two cases where the keyring could change due to distro changes. a) Add a new developer. b) Remove a developer. In case (a), pacman would find an unknown signature, an download [on user approval] the public key from the key servers. Case (b) is trickier, since no matter how it is done, I think there will always be a race condition on a roque developer. Luckily, the shouts of such case would make it difficult to have people holding outdated keys. I would probably make the key updating part of pacman -y to ensure that users are not using a revoked key.

My idea tries to give the best of both worlds. The management of trusted devs would be made by a few admins and users would just be exposed to an official Arch key that would change just a few times, if it is not compromised.

Your approach is more insecure, since you are removing the developer key (end-to-end signing) and putting instead a generic one. With the other schema, in case a developer key was compromised, you would only need to untrust that key, not the whole master key which signs everything. Plus, your key is used continously, so it is more exposed (the signing server is compromised, it signs a fake request...). IMHO trusting the individuals also facilitates forking. A derivative distribution could share arch packages by trusting the same devvelopers. With a master key owning everything, the child distro would need to have a second key resigning everything. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com