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

[Kerrick Staley]

All,

On Mon, May 30, 2011 at 6:50 AM, Rémy Oudompheng
<remyoudompheng at gmail.com> wrote:
> > 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.

We'll assume that only trustworthy individuals can currently access
the central repository server, because it's probably true [1].
Therefore, we can accept a key given by anyone who can access this
server, without any need for further verification; this can expedite
the key verification process. I am unfamiliar with CACert, but it
doesn't seem useful because it only verifies the supplied email
address, and email is assumed to be an insecure channel (plus, the
name needs to be verified).

> > 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.

They have to be signed somehow. If a db has packages with hashes but
not signatures, and pacman accepts these packages as long as the db is
signed, then whoever signs the db effectively is signing for all the
unsigned packages.

However, the method you suggest is equally acceptable, so we will add
SHA256 hashes to the repos, and pacman will accept packages with valid
hashes from a signed db, until all packages are signed, at which point
pacman's behavior will be changed to not accept such packages.

> > 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-keyshas
> > package.
>
> This doesn't seem necessary if the pacman-keys package is itself signed.

You're right. The idea was that since pacman-keys will be initially
installed without a signature check, taking this measure will make it
more difficult for any currently compromised mirrors to tamper with
the updates that add package signing. However, it will not make the
system theoretically more secure, and in retrospect the practical
benefits seem slim as well.

> > 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.

I meant "keys", not "signatures"; sorry.

On Mon, May 30, 2011 at 10:27 AM, Dave Reisner <d at falconindy.com> wrote:
>> 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.

As I said, we can fix this after shipping the initial signing-related
updates. Ship early/ship often, simplicity is far more important than
completeness, and all that jazz. I'd argue further, but in the
interest of saving your time and mine, let's let Dan decide.

>> 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.

We won't ship pacman-key out at all until it is working well. In the
meantime, end-users can get its functionality if needed by manually
invoking gpg.

>>...
> Not a concern to be addressed on pacman-dev.
...
>
> 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.

Security is a system, not a line of code, and other distributions will
need to implement a secure system if they want to use pacman as their
package manager. Hence, broader discussion about the implementation of
signing should take place on this list; anything specific to Arch can
be generalized to other distributions. You're correct in that we don't
have to wait on the infrastructure to ship an updated pacman, but I'm
personally only interested in achieving a working implementation of
package signing on Arch Linux, and so I will frame my discussion
appropriately. Perhaps I could have clarified that "Blocking" and
"Non-Blocking" are relative to this goal.

> 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.

Where "we" is non-inclusive of myself and other developers new to this
issue. I'm trying to save others the work of extracting this
information for themselves and also to lay out a plan for future work.

Sincerest love,
Kerrick Staley

[1] Also, any development we do operates under the assumption that an
attacker will not be able to tamper with any packages before we get
the signing feature shipped out and working. If an attacker can access
the central repository and has a key they would like added to all Arch
systems, they can just edit the .INSTALL of the most recently updated
package so that it installs the key; tricking the pacman-keys
maintainer is unnecessary. This is an unlikely situation, but I felt
it would be best to supplement the "it's probably true" justification
with a logical one. See "Reflections on Computing Trust" by Ken
Thompson for a discussion of a related issue.