[pacman-dev] Finishing off the package signing issue -- Update

[Dave Reisner]

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