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

[Kerrick Staley]

s/non-inclusive/exclusive/
I shouldn't write things at 4:30 AM.

On Wed, Jun 1, 2011 at 12:56 AM, Kerrick Staley <mail at kerrickstaley.com> wrote:
> 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.
>