On Thu, Apr 29, 2010 at 12:40 PM, Allan McRae <allan@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-pa... 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 -------------------------------------------