All, I examined the code in pacman's git master branch, and I found that it appears nearly finished. There are some issues, both blocking and non-blocking. Note that the following statements are to be interpreted as suggestions and may be revised if anyone has objections; if there are no objections, then this is the course of action that should be taken. 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. 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. 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. 5) The existing packages and databases on the central repository need to be signed. A single developer can do this. 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. Non-blocking: 1) Package validation without root privileges must be implemented. Fixing this issue after the signing feature is introduced will not require more work than fixing it first. Omission of this feature will not decrease security but will cause inconvenience. 2) pacman-key should be made production-ready. pacman-key is nonessential because users will typically not edit pacman's trustdb, and pacman-key's functionality is available via sudo GNUPGHOME=/etc/pacman.d/gnupg gpg --options although this usage is cumbersome since it is not tailored for pacman usage. pacman-key should be renamed to pacman-manage-keys to avoid confusion with the pacman-keys package. 3) The documentation for developer tools (makepkg, repo-add) should be reviewed and finalized. 3) The page http://www.archlinux.org/download/ needs to be made to use HTTPS. This can be done independently of package signing implementation, but is necessary for complete security. 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. 5) Further issues are given at https://wiki.archlinux.org/index.php/User:Allan/Package_Signing . I have not had a chance to investigate these issues, but they appear to be non-blocking. 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. 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. 5) I'm not sure what "output when downloading signature file - name when downloaded" from https://wiki.archlinux.org/index.php/User:Allan/Package_Signing means. I think it means that there is no indication when a database signature is being downloaded. I realize this message was rather long and does not have any patches attached to it. I apologize, but I felt that these basic points should be straightened out as development work continues. Tomorrow, I will transcribe some of the information in this email to https://wiki.archlinux.org/index.php?title=Pacman_package_signing, with expanded information on outstanding issues. If you are interested, please adopt an issue and also inform others so that work is not duplicated. If you have information that may be useful to others working on package signing, please place it on this page. I am working on blocking issue 1 and will be done fairly soon. I will then start to work on 2 and 3. 6 and 7 are big issues, so if anyone wants to help out, that'd be a good place. 4 and 5 require action of the Arch Developers; I only list them for completion. [1] This package will place keys (as generated by gpg --export) into the /etc/pacman.d/gnupg/pacman_valid_keys and /etc/pacman.d/gnupg/pacman_revoked_keys directories. The .INSTALL file will update the /etc/pacman.d/gnupg/trustdb.gpg according to the directories' contents. The PKGBUILD for this package will download valid and revoked keys from an HTTPS page on archlinux.org. Before the package is updated, the HTTPS page will be updated, so that the package will contain the changes when built on the developer's machine. The PKGBUILD cannot just copy keys out of the trustdb (with a special option to add or revoke keys for developers) because the PKGBUILD should be able to make the package even when the package isn't already properly installed. Or maybe it can just copy them; I'm too tired right now to decide which is best. Carpe Noctem, Kerrick Staley