On Mon 30 May 2011 at 04:43 -0500, Kerrick Staley wrote:
Blocking: 1) The option/function naming conventions need to be unified, per https://wiki.archlinux.org/index.php/User:Allan/Package_Signing . This will be significantly harder to fix once the signing feature is shipped.
There is not really a problem there (at least, it doesn't get worse currently).
2) A means of initially installing keys and of updating the list of keys must be created. This will be implemented as a package called pacman-keys. [1]
3) The Arch Developers must create keys. The page https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages must be finalized, and then an informational email can be posted to arch-general.
This process is already ongoing.
4) The Arch Developers must place their keys into the pacman-keys package. The developers that can access the central repository can update the package directly. The developers that lack this access (if any) can generate a fingerprint, email their key to a developer with access, and use Skype to verify the fingerprint. If this is a problem, other arrangements can be made.
Your proposed method of exchanging keys is absolutely against all my principles. The maintainer of the keyring already knows the list of developers (which is publicly available on archlinux.org). He/She adds keys according to a trust level, which is evaluated according to key signatures made by CACert and/or other Archlinux developers.
5) The existing packages and databases on the central repository need to be signed. A single developer can do this.
There is absolutely no way I sign a package that I didn't build myself, unless I feel personally linked to it. Moreover, a signed database is sufficient to initiate the process. Signed packages are an additional and independent security.
6) The entire signing process needs to be tested, and pactest tests should be written for it.
7) The pacman manpage should be reviewed and finalized.
Nothing specific to signing here, just the usual release process of pacman.
4) The output of tar -cf - /etc/pacman.d/gnupg/pacman_{valid,revoked}_keys | sha256sum as executed on an up-to-date system should be posted on an HTTPS page somewhere on archlinux.org and updated upon updates to the pacman-keys package.
This doesn't seem necessary if the pacman-keys package is itself signed.
Questions: 1) I am unsure as to who has access to the central repository regarding blocking issue 4, so if someone could clarify, I would appreciate it.
2) pacman-key should be updated after pacman but before any other packages. I am not sure if the SyncFirst field in /etc/pacman.conf supports this behavior. If not, the two packages will be both placed in this field and will be designed to install properly in either order until the SyncFirst functionality can be improved.
3) I don't know how quickly validated signatures from every single developer can be gathered, so maybe this will be an issue; I'm not sure.
I don't know what you mean, our signatures are uploaded along with packages.
4) I haven't yet had a chance to see how the documentation is, but pacman's manpage should be reviewed before shipping; manpages for developer-side tools can be reviewed after shipping.
This is part of the usual release process of pacman. -- Rémy.