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