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<[email protected]> 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
