Am Sat, 29 Nov 2008 17:24:19 -0600
schrieb "Aaron Griffin"
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