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

[Rémy Oudompheng]

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.