On 01/06/11 15:56, Kerrick Staley wrote:
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.
Seem that somebody might have already thought about a transition period where only some packages are signed by allowing VerfiySug to take values Optional and Always...
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.
Why would it be installed without a signature check? I'm assuming that any user can download the "pacman-keyring" package (because that is the more likely name than pacman-keys....) and its signature and do some manual verification. In fact, I do not see the point of installing such a package at all without a signature check as that is a fail from the start.
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.
Hmm... we can ship pacman early and often without full functionality but not pacman-key. Good thing for consistent policies... I'd say all the patches needed for pacman-key to be production ready are already on the mailing list. And it is actually quite functional as it currently is in git. I have been using it to manage my pacman keyring for months. Allan