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

[Kerrick Staley]

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