[arch-general] Package signing

Denis A. Altoé Falqueto denisfalqueto at gmail.com
Wed Apr 28 21:42:20 CEST 2010

On Wed, Apr 28, 2010 at 3:30 PM, Florian Pritz
<bluewind at server-speed.net> wrote:
> On 28.04.2010 19:18, Denis A. Altoé Falqueto wrote:
>> I'm thinking about a two way signing process. The dev signs the
>> package and send it to the server. The server would have a script or a
>> cron job to verify if the signature is valid and is from someone
>> trusted [1]. If so, the original signature is discarded and a new one
>> is made, with an official Arch key.
> If you do it that way you wouldn't have to sign the uploaded packages.
> I'd publish a list of developers' keys and the user has to add and trust
> (in GPG terms) those keys. If he trusts them pacman installs packages
> singed by those keys or keys that can be trusted because they have been
> signed by them (GPG's web of trust). Otherwise if the (untrusted) sig
> can be verified pacman could ask and if the sig is broken it could abort.
> If you do it that way you can also add URLs to binary packages to the
> AUR and let pacman download them if you trust the sig.

Your suggestion is similar to Daenyth`s (for what I understand), so I
will comment on both together.

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.

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.

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.

One weak point is the passphrase for the Arch key. It should not be
handed over to every dev [1] and should not be used in command line
scripts parameters or the cron job. It can be stored in some secure
file and applied with gpg`s --passphrase-file <filename> or
--passphrase-fd <file descriptor>. So, the effective user of the
script would have access to read the passphrase file, but the real
user would not.

Maybe this is a little overkill, but C&C are very welcome :)

[1] Maybe I`m just too paranoid with the dev team, but I don`t think
that all of them should have the passphrase (if I were a dev, I
wouldn`t want to have it). We have seem the group expanding and losing
components. No offence intended.

Denis A. Altoe Falqueto

More information about the arch-general mailing list