[arch-general] [arch-dev-public] Can we trust our mirrors?

[Gerhard Brauer]

Am Sat, 29 Nov 2008 17:24:19 -0600
schrieb "Aaron Griffin" <aaronmgriffin at gmail.com>:
> 
> I talked to Dan about this briefly the other day. What we concluded
> was that the most proper and secure way to do this is as follows:
> * gerolde hosts a "developer keyring"
> * developers sign their individual packages with their own keys
> * the database file still contains the integrity checksums
> * the database file also includes package signing data

You were right: signing of packages must be done before it gets
transported do any destination. That's the part of each developer IMHO.
We trust them, we must trust them. Each developers public key must be
available in a arch-devel keyring. Pacman itself must pick the right
public key from this keyring (based of package signing data from the
db) to verify the downloaded package. Arch overlord must have the power
to revoke end delete the developers key from this keyring.
repo-add at gerolde could check the correct signing of new packages as
a "first instance". The public keyring must be available for the user
side - best with pacman itself and/or as a seperate package.

> The current proposition, with one key on gerolde used to sign the DB,
> is insecure in that it makes the developers the weak point. If all of
> gerolde, or even only those with sudo rights, can see this private
> key, all it takes is maliciousness on one person's part and all our
> packages are vulnerable.
> 
> The whole point of a private key is just that - that it's private. If
> we suddenly make this key "semi-public", we open the door to lots of
> other issues, at the human level.

AFAIK from Pierre is that repo-add i neither called directly by the
developers - only from scripts when they upload their packages. The
private key for signing the database files could be kept private by
using a dedicated user which runs repo-add under his uid. In the
scripts we could call repo-add with su/sudo and this uid. So the
private key is in $HOME, only available for users with super powers on
gerolde. If one must call repo-add directly this is also possible with
su/sudo. But all in all: signing the database files must be done on
gerolde from/during the process when they are created.

> When I last spoke to Dan, the biggest issue here was that gpg doesn't
> have a library interface. We'd have to call the binary directly from
> pacman.

THAT's sound bad! I'm not a c programmer but is there no useable
library from those on:
http://www.gnupg.org/related_software/libraries.en.html ?
What's with this gpgme also in [extra]?

> If we look at the above solution, we can leverage the
> XferCommand to cover this, without affecting pacman at all:
> * Create a download script that will download a package, check the
> integrity checksum, and verify the signature in the database using the
> archlinux.org keyring
> * Pacman will continue to work as is, considering the checksum is
> still in the DB
> 
> All we'd need is to patch repo-add to include signature data in the
> DB. To do this properly, signatures should be uploaded with the
> package itself, from the packager's machine... hmmm

In the starting mail on arch-dev-public Pierre attached a quick patch
and download script that i have tested with my own repo. This is
working in this way that a whatever modified database file don't get
installed as new data during -Syu when the signature could not be
verified. No new database -> no new packages.

Dirty things with such a solution (as special download script) is:
libalpm/pacman download mechanism gets broken/useless, and the gpg
output (and wget/curl output) is bad to integrate this way in pacman.

Regards
	Gerhard