Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#30463 - The thing with the signed packages...

Attached to Project: Pacman
Opened by Oliver L. (Grimeton) - Wednesday, 27 June 2012, 18:04 GMT
Last edited by Allan McRae (Allan) - Saturday, 04 August 2012, 09:37 GMT
Task Type Support Request
Category Backend/Core
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version 4.0.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Hi,

I'm writing here because I experience the chicken/egg problem ( http://en.wikipedia.org/wiki/Chicken_or_the_egg ) everytime I install a new ArchLinux machine via the latest net-install iso available on the mirrors (archlinux-2011.08.19-netinstall-x86_64.iso)

After the main installation has finished and the machine booted for the first time one needs to update the package lists.

# pacman -Sy

And then we need to install a package and hit the "Public keyring not found" problem.

The only way to get around this is to change the SigLevel from "PackageRequired" to "Never". When this is done, one syncs the package databases again and then installs the necessary packages...

So the first thing one installs - if the machine is virtualized - is "haveged" to have enough entropy available before one dies of infirmity. After the daemon is installed and started, the next step requires installing archlinux-keyring (without signing!!!) and populating the keyring.

No one is able to check if the archlinux-keyring package is from the right source but it's installed and the keys are then trusted to check if the packages are all ok and come from the right person/distribution.

If someone changes the archlinux-keyring file and propagates it on one or two servers you get hundreds or thousands of machines trusting those keys. I don't think we need to go into more detail here.

Solution?

Just install the archlinux-keyring package during the base install together with haveged (if it's a vm) and then init the keychain during install, or just allow the user to later init/populate the keychain but have everything necessary installed.

Yes I know, someone could change the ISO file, and the md5sum and stuff, but when you have the ability to just init the keychain without any changes on the configuration, you can check the public servers after the init and the changed keys will show up as wrong.

Another solution could be to download the trusted keys from a webserver online during install (ok, lot of environment needed and what about offline installations?) ...

But you should close the gap between installing and keychain init.

Btw.: If you distribute the keychain inside the iso, you can check if something is wrong during boot (was the iso changed, then the keys and the checksum are wrong from the iso/package/both).

To detect if a machine is running virtualized one can use dmidecode to read the bios information.

VMWare looks like this:

Manufacturer: VMware, Inc.
Product Name: VMware Virtual Platform
Version: None
Serial Number: VMware-LOOOONG ID HERE

VirtualBox:

Manufacturer: innotek GmbH
Product Name: VirtualBox
Family: Virtual Machine

I'm sure someone is able to provide the necessary information to figure out KVM,XEN and Hyper-V

If I can help with anything, feel free to contact me.

KR,

Grimeton


This task depends upon

Closed by  Allan McRae (Allan)
Saturday, 04 August 2012, 09:37 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Not a pacman bug, but is fixed in latest Arch Linux isos.

Loading...