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
