FS#27612 - pacman doesn't import subkey automatically, pacman-key does.

Attached to Project: Pacman
Opened by Peter Lewis (petelewis) - Sunday, 18 December 2011, 00:57 GMT
Last edited by Dan McGee (toofishes) - Monday, 09 January 2012, 04:02 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Dan McGee (toofishes)
Architecture All
Severity Low
Priority Normal
Reported Version 4.0.1
Due in Version 4.0.2
Due Date Undecided
Percent Complete 100%
Votes 7
Private No

Details

Summary and Info:

pacman can automatically import keys it doesn't know from a keyserver. However, this doesn't work when the key is a subkey. pacman-key appears to be able to deal with this perfectly well however.

Steps to Reproduce:

From a fresh pacman 4.0.1 install, after running pacman-key --init:

% sudo pacman -S devtools
resolving dependencies...
looking for inter-conflicts...

Targets (3): namcap-3.2.1-1 pyalpm-0.5.3-1 devtools-20111111-1

Total Download Size: 0.11 MiB
Total Installed Size: 1.18 MiB

Proceed with installation? [Y/n]
:: Retrieving packages from testing...
pyalpm-0.5.3-1-x86_64 37.6 KiB 157K/s 00:00 [#################################################] 100%
namcap-3.2.1-1-any 60.8 KiB 217K/s 00:00 [#################################################] 100%
:: Retrieving packages from extra...
devtools-20111111-1-any 16.1 KiB 144K/s 00:00 [#################################################] 100%
(3/3) checking package integrity [#################################################] 100%
error: pyalpm: key "206CBC892D1493D2" is unknown
:: Import PGP key 2D1493D2, "Rémy Oudompheng <remy@archlinux.org>", created 2011-02-16? [Y/n]
error: devtools: key "7F2D434B9741E8AC" is unknown
:: Import PGP key 9741E8AC, "Pierre Schmitz <pierre@archlinux.de>", created 2011-04-10? [Y/n]
(3/3) checking package integrity [#################################################] 100%
(3/3) loading package files [#################################################] 100%
(3/3) checking for file conflicts [#################################################] 100%
(3/3) checking available disk space [#################################################] 100%
(1/3) installing pyalpm [#################################################] 100%
(2/3) installing namcap [#################################################] 100%
(3/3) installing devtools [#################################################] 100%

But then:

% sudo pacman -S rekonq
resolving dependencies...
looking for inter-conflicts...

Targets (1): rekonq-0.8.1-1

Total Download Size: 2.53 MiB
Total Installed Size: 5.72 MiB

Proceed with installation? [Y/n]
:: Retrieving packages from community...
rekonq-0.8.1-1-x86_64 2.5 MiB 932K/s 00:03 [#################################################] 100%
(1/1) checking package integrity [#################################################] 100%
error: rekonq: key "22AD5874F39D989F" is unknown
error: key "22AD5874F39D989F" could not be looked up remotely
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

However:

% sudo pacman-key -r 22AD5874F39D989F
gpg: requesting key F39D989F from hkp server keys.gnupg.net
gpg: key E19DAA50: public key "Peter Richard Lewis <pete@muddygoat.org>" imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: Total number processed: 1
gpg: imported: 1
==> Updating trust database...
gpg: no need for a trustdb check

And then:

% sudo pacman -S rekonq
resolving dependencies...
looking for inter-conflicts...

Targets (1): rekonq-0.8.1-1

Total Installed Size: 5.72 MiB

Proceed with installation? [Y/n]
(1/1) checking package integrity [#################################################] 100%
(1/1) loading package files [#################################################] 100%
(1/1) checking for file conflicts [#################################################] 100%
(1/1) checking available disk space [#################################################] 100%
(1/1) installing rekonq [#################################################] 100%


The only difference I can see is that my key (I am the rekonq packager) is a subkey. This appears to be making pacman not call pacman-key -r correctly.

Thanks.
This task depends upon

Closed by  Dan McGee (toofishes)
Monday, 09 January 2012, 04:02 GMT
Reason for closing:  Fixed
Additional comments about closing:  Commit def9e45affaf5 on maint
Comment by Sébastien Luttringer (seblu) - Sunday, 18 December 2011, 01:14 GMT
i've the same issue.

i quickly looking inside libalpm signin code and it don't call pacman-key but use gpgme.
Comment by Peter Lewis (petelewis) - Tuesday, 20 December 2011, 23:54 GMT
Seems it's not just my key that this happens with. I just got the same behaviour trying to install kpartsplugin from [community]. Timothy Redaelli's key wasn't pulled by pacman automatically, but pacman-key -r worked fine.
Comment by Dan McGee (toofishes) - Thursday, 05 January 2012, 22:29 GMT
Thanks PGP keyservers for being total pieces of crap. I used your key as an example Pete, if you don't mind, to let them know this "upstream":
http://lists.gnupg.org/pipermail/gnupg-users/2012-January/043495.html

I'm adding a quick workaround in pacman to try again with the 8 character version which makes it work with the broken keyservers for now.
Comment by Peter Lewis (petelewis) - Thursday, 05 January 2012, 23:21 GMT
Wow interesting. Thanks for following this up Dan, and no, no problem using my key as an example :-)

Loading...