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.
