On Mon, May 30, 2011 at 04:43:02AM -0500, Kerrick Staley wrote: > 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.
Any suggestions you might have in patch form are more than welcome, and will help get the ball rolling. > 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] Not a concern to be addressed on pacman-dev. > > 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. Not a concern to be addressed on pacman-dev. > 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. Not a concern to be addressed on pacman-dev. > 5) The existing packages and databases on the central repository need to be > signed. A single developer can do this. Not a concern to be addressed on pacman-dev. Also, insane. > 6) The entire signing process needs to be tested, and pactest tests should > be written for it. Standard release practice. > 7) The pacman manpage should be reviewed and finalized. Standard release practice. > 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. I consider this a blocker. Also note that if this had a simple solution, it would have been done by now. Ideas welcome. > 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. I consider this a blocker. To roll out a tool which implements a standard procedure, but which is only half complete, is a waste. > 3) The documentation for developer tools (makepkg, repo-add) should be > reviewed and finalized. Standard release practice. > 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. Not a concern to be addressed on pacman-dev. > 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. Not a concern to be addressed on pacman-dev. > 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. > tl;dr. You seem to have issues separating what happens here on pacman-dev from what happens in Arch Linux. Although the majority of pacman's userbase _is_ indeed Arch Linux, we maintain portability to OSX, cygwin, and the BSDs. Anything to do with Arch Linux packages _specifically_ has no effect on our ability to roll out a new release of pacman. Your original statement implied that you would be providing some sort of 'course of action'. All I see is a high level analysis of what we already know, with nothing in the realm of deliverables. regards, dave
