[arch-general] Time for new release?

[Dennis Herbrich]

On Sun, Jun 17, 2012 at 10:00:27PM +0200, Geoffroy PLANQUART wrote:
> > 
> > However: Distributing a pacman keychain master key to more than one machine is
> > rarely a sensible solution. If you actually want the very specific additional
> > security checks offered by only allowing signed packages, you must ensure a
> > properly secured master key with a diligently confirmed web of trust. If the
> > private master key, which is being generated with --init, leaks, it is trivial
> > for a hypothetical attacker to directly sign manipulated packages with this
> > key, which basically invalidates the security benefit signed packages are
> > supposed to offer.
> 
> Good point, I though about this one too, but what about automatic `pacman-key
> --init' at install time? This would solve the problem no?

Sort of. That will leave the issue of waiting for enough entropy to be
generated, which can be countered on a VM by running a command generating disk
I/O in parallel until the key generation is finished. Otherwise you'll get
complaints of "hanging" installers.

In addition, you'll need to take care of the initial key import and, more
importantly, initial trusting of the Archlinux Master Keys, which is only 95%
automated by the --populate call. It's your call whether you'll want to educate
your users and supply a source they can compare the displayed fingerprints to
manually, or "force" automatic trusting by piping 'yes' into the process.
Either way presents specific security issues which may or may not be of
relevance to you.

You may also choose to publicize your own repository containing a combination
of core, extra, community and the AUR as you need it, and re-sign all packages
with a wholly independent set of keys, or even only a single key, of your
choice, so that people using the repo have to trust keys which are easier for
them to verify.

All these considerations aside: You are going to need manual intervention by an
educated user during the installation to have a decent chance at the key
management not being built upon false premises from the get go. You can make it
easier, but probably shouldn't automate it away entirely, as this gives an
entirely unwarranted sense of security to the user. There's a reason why
--populate specifically asks the user to manually verify the fingerprints of
the master keys.

It all boils down to your specific security concerns you want to be addressed
by package/database signing in the first place. For example, if the VMs are in
an isolated, proxied network with the only package source definitely being
under your control, you can probably do away with the whole signing issue
altogether without facing a significantly higher risk of package manipulation
by a third party.

In your case, maybe you can include the fingerprints of the master keys in some
(printed) installation document for the users to use for verifying the master
keys during the --populate call. That way, the users may actually do the chore
diligently instead of hammering the enter key, and you can be reasonably sure
that the fingerprints they compare the output with are actually the right ones.
Unless somebody manages to manipulate your docs or the installation itself, of
course. :)

Good luck either way!
  Dennis