[arch-general] Package signing

[Denis A. Altoé Falqueto]

On Thu, Apr 29, 2010 at 12:40 PM, Allan McRae <allan at archlinux.org> wrote:
> Has anyone had a good look at the other implementations of package signing
> (Debian, Fedora, ...) and made a summary of how they handle it?

(Long email ahead, sorry...)

Good idea, indeed. This is what I've found about Debian:

http://www.debian.org/doc/manuals/securing-debian-howto/ch7.en.html#s-deb-pack-sign

Basically, they use gnupg and a private web of trust, managed by the
apt-key command. They keep a separated keyring and trustdb (which
keeps track of the web of trust). So, as I was thinking, they don't
use the root's keyring or trusdb. They have a main signing key, that
is shipped on the install cd and is installed by default on the
keyring of apt-key. The main key is trusted and is used to sign the
other keys used by the repositories, building up the web of trust. The
repositories keys package is debian-archive-keyring and is used to
distribute new keys and remove old ones.

Fedora uses the same approach:
http://docs.fedoraproject.org/drafts/rpm-guide-en/ch11s04.html

I think the solution will be something like that. Maybe we could have
like 2 or 3 signing keys, with the private part held by 2 or 3
developers. The keys are used to sign each other, so the level of
trust can be raised a little, since pgp doesn't have a Certificate
Authority concept.

These main keys must be verified and trusted explicitly by the root
user, at install time or after, in the case of a installed system (I
think that this is a little price to pay to increase the security). I
think that pacman could have some parameters to manage the keyring,
like rpm and apt-key, so the user doesn't need to handle it with gpg.
The verification is the process of the user verifying that the
fingerprint of a key is correct, based on other channels (website,
email, preferably in multiple sources).

After the main keys are trusted to accept other keys signed by them,
is possible to have a package of developer's keys, with a post-install
script to append or remove them from the keyring of pacman and update
the trustdb accordingly. We can choose the parameters of the trustdb,
so that a developer's key is trusted if it is signed by at least 2 of
the 3 main keys, or 1 of the 2 or 3. The developer's keys package
should be signed by one of the main signing keys, so it can be trusted
by pacman.

Another point worth discussing is what will be signed. I think we
should sign the repository metadata (repo.db.tar.gz) and each
developer would sign his/her package. I have some doubts about the
repository metadata signing, because I don't know exactly how the
repo.db is created today. Is it made by each developer that uploads a
package (in this case, the dev's key should be used to sign the
repo.db). Or is it a script in Arch's server? We need to discuss this
a little more.

For the package signing part, it can be made very easily with this
approach. The developer's public key is signed by a number of main
Arch keys. The pacman's keyring package is rebuilt to append the new
signed public key and is the resulting package is signed by one of the
main Arch keys. The package is downloaded by the users and the
post-install script updates the keyring and the trusdb. The updating
should add new keys and remove the ones that are not present in the
package (this will be a little tricky, but we can figure out a way).
The keyring package must be updated just like pacman, preferably
before pacman's package.

The mos sensitive part is the verification of the main Arch keys by
the user and the verification of the developer's public keys by the
developers that will sign with the main Arch keys. There should be
some secure channel of communication to guarantee that the
fingerprints will not be changed for malicious purposes.

C&C very much appreciated.

-- 
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

-------------------------------------------
Denis A. Altoe Falqueto
-------------------------------------------