[arch-general] Package signing

[Linas]

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