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.
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.
FS#55135 - makepkg don't trust subkey even though master key is trusted
Attached to Project:
Pacman
Opened by Horo (Horo) - Monday, 14 August 2017, 08:10 GMT
Last edited by Doug Newgard (Scimmia) - Tuesday, 15 August 2017, 15:13 GMT
Opened by Horo (Horo) - Monday, 14 August 2017, 08:10 GMT
Last edited by Doug Newgard (Scimmia) - Tuesday, 15 August 2017, 15:13 GMT
|
DetailsDescription:
makepkg report " Verifying source file signatures with gpg... FAILED (the public key ... is not trusted) " when file is signed with a sub key. Steps to reproduce: * Sign a file with a sub key and add it to source() * run makepkg to verify it. For example : https://github.com/archlinuxcn/repo/tree/12f0c62548e29b2cfb526c99352897425ac1d9a2/firefox-nightly-zh-cn Additional notes: Sign the subkey locally seems can bypass this problem now, or I've done something mistake? :-) |
This task depends upon
Closed by Doug Newgard (Scimmia)
Tuesday, 15 August 2017, 15:13 GMT
Reason for closing: Not a bug
Additional comments about closing: Typo
Tuesday, 15 August 2017, 15:13 GMT
Reason for closing: Not a bug
Additional comments about closing: Typo
Though I do note that you hardcode x86_64 in one part of the filename, and then use ${CARCH} in another part which is incredibly weird.
And if validpgpkeys exists and has at least one fingerprint in it, makepkg straight up ignores the TRUST_* value and relies solely on whether it found a matching VALIDSIG fingerprint: https://git.archlinux.org/pacman.git/tree/scripts/makepkg.sh.in?h=v5.0.2#n688
So locally signing a pubkey can only ever work if validpgpkeys contains nothing, valid or otherwise.
This is explicitly documented in PKGBUILD(5) as:
validpgpkeys (array)
An array of PGP fingerprints. If this array is non-empty, makepkg will only accept signatures from the keys listed here and will ignore the trust values from the keyring. If the source file was signed with a subkey, makepkg will still use the primary key for comparison.
Only full fingerprints are accepted. They must be uppercase and must not contain whitespace characters.
So the behavior your are seeing is explicitly supposed to work, and does in fact work when I try your PKGBUILD. Are you positive you are actually using the PKGBUILD you linked? makepkg should only even emit that error when `(( ${#validpgpkeys[@]} == 0 && !trusted ))` so it should be impossible to ever see that message using the PKGBUILD you linked.
firefox-57.0a1.zh-CN.linux-x86_64.tar.bz2 ... FAILED (the public key 14F26682D0916CDD81E37B6D61B7B526D98F0353 is not trusted)
==> ERROR: One or more PGP signatures could not be verified!
Sorry I'm pasted wrong PKGBUILD... It fails on my dev-tools environment through gpg --verify is successed:
gpg: Signature made Tue 15 Aug 2017 07:54:22 PM CST
gpg: using RSA key BBBEBDBB24C6F355
gpg: Good signature from "Mozilla Software Releases <release@mozilla.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 14F2 6682 D091 6CDD 81E3 7B6D 61B7 B526 D98F 0353
Subkey fingerprint: DCEA C5D9 6135 B91C 4EA6 72AB BBBE BDBB 24C6 F355
There are, however, vaildgpgkeys, which do nothing. Fix your typo, and then fix your incorrect reference to gpg instead of pgp, and and it will work.