[pacman-dev] Finishing off the package signing issue -- call for contributors

[Kerrick Staley]

All,

> What!!!  There has there been no progress... in two weeks!!!
> That's right...  it has been only two weeks since the last commit
> to do with package signing was pushed to the master git repo
> (http://projects.archlinux.org/pacman.git/commit/?id=70cf4546).
> In fact, it currently 10 days, so it was 9 days when the original
> emails to this thread were sent.  Shock, horror development has
> stalled!
Although work is happening, I think it's fair to say that it's not happening
fast enough to cause problems with duplication. Also, compared to the amount
of effort I would like to see going towards this idea, and the amount of
effort I am willing to personally put into it, the work the main pacman devs
are doing appears to be very little.

> Note that how Arch will deal with signing in their repos is being
finalised
> elsewhere, but to reiterate, that has nothing to do with the pacman
> implementation.
Where?

> This is why it needs to be kept completely separate from discussions about
> implementing signature verification work in pacman.
Eh? pacman-dev is the most relevant list I've found for discussion of this
issue. The key-signing mechanism in pacman (in particular, its ease-of-use)
has a direct impact on its adoption, and the two conversations should not be
separated.

With regard to key schemes, the security of your system is the security of
any package you install into it; in particular, if an attacker has a
developer key and controls any part of the connection between you and the
central archlinux.org repository, they can modify the .install of the next
package you happen to update, and do whatever they want to your system,
including altering your GPG install, so there's no point to any sort of
specialized key scheme. There will be a list of developer keys, and anyone
who can log in to the central repository can change that list, so the
responsiblity of key verification will fall on whoever manages the central
repository. Revocation just means deletion from this list, and, as Ari
correctly points out, a complexer revocation scheme is unnecessary [1].

The security of the central repository and of its contents are hairier
issues, and since I don't know how this is implemented, I ask that someone
inform me of how the central repository is managed (and of who has the
ability to perform this management). It's probably already secure, though.

With regard to verifying packages, it should be possible to verify
signatures without root privileges as long as root is not updating pacman's
keyring. This should be possible without any downsides or crude hacks. If it
is necessary to attach an Arch-specific patch to Arch's GPGME package, then
that can be done. Ari, you can do this if you want, and if not, I'll
complete the task. Also, Ari, I would recommend not spending time theorizing
about solutions to small issues such as this: it's better just to code out a
solution (and of course test it) and then submit a patch. Discussion about
how to implement an idea in code is rarely needed: just do it.

For now, let's all just publish our changes to this list so that they can be
integrated into the master branch of pacman's git. If people have a lot of
code that is not polished enough for pacman's master branch, but that they'd
like to share anyway, I'll set up a separate git repository that we can work
out of, publishing finished code as patches when necessary.

If you are interested cryptography and security, I would highly recommend
reading Applied Security by Bruce Schneier (the protocol-related portions
can be understood without reading the sections on mathematical and
algorithmic underpinnings).

Happy hacking and best wishes for Allan's health,
Kerrick Staley

[1] If a the compromise of a key is discovered and you are informed before
updating your system, then a secure channel for key revocation that is
independent of the repositories (best done with revocation certificates)
would be useful, but this is irrelevant for practical and theoretical
reasons. Practically, most people update daily, so there is a very small
window in which the discovery of a compromise will be useful. Also,
compromises should be rare enough that when they do happen, a news item can
be posted on the Arch homepage informing users on how to manually revoke the
keys [2]. Theoretically, there's no way to tell whether a compromise
happened when you think it did or sometime before.

[2] The Arch homepage is insecure (no SSL), so this is a further issue.
However, this is all getting to be too scenario-specific; fine-grained
analysis such as this should be done only after we have a basic
implementation of package signing working.