[arch-general] Time for new release?
Hi everybody, I'm currently on a school project and I run a dozen of virtual machines, all running Arch. I noticed that every time I set up a new VM, I have to manually run the `pacman-key --init' and `pacman-key --populate archlinux'. Wouldn't it be time to set up a new installation release? Thus new users wouldn't have to bother about pacman recent changes, and moreover the basic install would be kept simple, ready to use. Geoffroy
Geoffroy PLANQUART <geoffroy@planquart.fr> wrote: Hi everybody, I'm currently on a school project and I run a dozen of virtual machines, all running Arch. I noticed that every time I set up a new VM, I have to manually run the `pacman-key --init' and `pacman-key --populate archlinux'. Wouldn't it be time to set up a new installation release? Thus new users wouldn't have to bother about pacman recent changes, and moreover the basic install would be kept simple, ready to use. Geoffroy You should really write to the arch releng list rather than here.
On Sun, Jun 17, 2012 at 09:25:25PM +0200, Geoffroy PLANQUART wrote:
I noticed that every time I set up a new VM, I have to manually run the `pacman-key --init' and `pacman-key --populate archlinux'.
Wouldn't it be time to set up a new installation release? Thus new users wouldn't have to bother about pacman recent changes, and moreover the basic install would be kept simple, ready to use.
I'm maintaining a development VM at work based on Arch, and encountered the same issue; Everyone installing one of these VMs for the first time has to do the key generation dance, which is made worse by the fact that a VM doesn't tend to generate lots of entropy in the first place. 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. If you do not need signed packages, anyway, just switch off the signature logic in your pacman.conf with SigLevel = Never and don't bother with key management at all. It all depends on your setup and requirements. Of course a fresher installation medium surely would be nice to have, especially for VM setup, although there are quicker ways than a bootable CD to get an up to date VM running with Arch, do not expect key management to ever run out of the box. It's not supposed to, as it's highly individual. Best regards, Dennis
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?
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/17/12 14:07, Dennis Herbrich wrote:
On Sun, Jun 17, 2012 at 10:00:27PM +0200, Geoffroy PLANQUART wrote:
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.
If you ran the pacman-key --init near the beginning of the installation, would the disk activity produced by installing the packages not create the needed entropy? (Obviously, I'm assuming that this can be run from the installation medium before pacman, et al, are actually installed.) - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP3lDLAAoJELT202JKF+xpGOYP/2CzZZ5aA5oiKup6p5v2oScg BV47SK59/2LAwsA8TXwbHYosesis883hANauFyfviHoyLqTncx3XekM678pN0hqz YMPyz4510Kmlp31xBkFRk4ztOASXjUSq28jTR+YJkDDJeM4oUcpl+FTmXNNoIr1z 0ZHH82ALX2XVzt0EjAbEXhbK/7jIvBjHUBPjBVCWKhhGbmfJybapmfvNBTkSsXV4 z4o3Ystbk+Osto47bJLgQV11nInglB0Gr/ob58UvVWljBpF5d8H50RASYY8gr01M hzg5XcI4pS9YjBymas8Qe4O4npslGsvhy7p5TrXXjzc782jgzUyoc3fvW6OOcFqk yfvgDRD5b5hIMptgyQw2Oj9Rybmo/5eG94oQaOLpvelFTPVGavB+gMPYiwmK95+b 6JqH81/10VRcSH8KYeyCd5+lNrH/SM7vFKTSiPxq2yCdZ70TZpnUBNIJJaB/HufF Va0fLYun03vAEl4G1qobD5A72vaOKqUi2yh8WtIpH0MclVmR0fol31a1FlZDeJX5 Gh5z10cSZvfqpWZbcXG+jQi4VnNIysnx1OjUEhcQWt1JW/uz3DNRvjGmArCLU7EE 90XRIINnvNV4kPWY8BNNEs5nCTCYq1/6vb3V5dfv4w04OOFGDR+xxCqNMyRbmtyj atxHbVN+C2z92ZzQnDFB =g+fS -----END PGP SIGNATURE-----
On 06/17/2012 10:25 PM, Geoffroy PLANQUART wrote:
Hi everybody,
I'm currently on a school project and I run a dozen of virtual machines, all running Arch.
I noticed that every time I set up a new VM, I have to manually run the `pacman-key --init' and `pacman-key --populate archlinux'.
Wouldn't it be time to set up a new installation release? Thus new users wouldn't have to bother about pacman recent changes, and moreover the basic install would be kept simple, ready to use.
Geoffroy
Hello, It is time to release a new iso but right now, AIF installer is not in a good shape. Soonish we will have a call for help published and yo will know the current situation. -- Ionuț
Am 17.06.2012 22:27, schrieb Ionut Biru:
On 06/17/2012 10:25 PM, Geoffroy PLANQUART wrote:
Hi everybody,
I'm currently on a school project and I run a dozen of virtual machines, all running Arch.
I noticed that every time I set up a new VM, I have to manually run the `pacman-key --init' and `pacman-key --populate archlinux'.
Wouldn't it be time to set up a new installation release? Thus new users wouldn't have to bother about pacman recent changes, and moreover the basic install would be kept simple, ready to use.
Geoffroy
Hello,
It is time to release a new iso but right now, AIF installer is not in a good shape.
Soonish we will have a call for help published and yo will know the current situation.
Try this if you need fresh packages: https://wiki.archlinux.org/index.php/Archboot -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
participants (6)
-
David Benfell
-
Dennis Herbrich
-
Geoffroy PLANQUART
-
Ionut Biru
-
Sven-Hendrik Haase
-
Tobias Powalowski