AUR Issue, keyring » ERROR: PGP signatures could not be verified

ive · 2021-11-04 19:56:52

I'm trying to figure out if this is a problem with the package (https://aur.archlinux.org/packages/openresty), pacman's keyring or PGP user's keyring, or the developer's signing key - and where to go from here.

$ pikaur -S openresty
...
==> Verifying source file signatures with gpg...
	openresty-1.19.9.1.tar.gz ... FAILED (unknown public key B550E09EA0E98066)
==> ERROR: One or more PGP signatures could not be verified!
Finished with result: exit-code
Main processes terminated with: code=exited/status=1
Service runtime: 5.032s
CPU time consumed: 4.619s

Command 'systemd-run --service-type=oneshot --pipe --wait --pty -p DynamicUser=yes -p CacheDirectory=pikaur -E HOME=/tmp -p WorkingDirectory=/var/cache/pikaur/build/openresty makepkg --force' failed to execute.

The key has been added to the pacman's keyring and the users's keyring. I assume it refers to pacman's keyring. But could also refer to the user's keyring because of 'makepkg'.

$ pacman-key --finger B550E09EA0E98066
pub   rsa2048 2013-02-18 [SC]
	  2545 1EB0 8846 0026 195B  D62C B550 E09E A0E9 8066
uid           [  full  ] Yichun Zhang (agentzh) <agentzh@gmail.com>
sub   rsa2048 2013-02-18 [E]

$ gpg --list-keys
~/.gnupg/pubring.kbx
------------------------
pub   rsa2048 2013-02-18 [SC]
	  25451EB088460026195BD62CB550E09EA0E98066
uid           [ unknown] Yichun Zhang (agentzh) <agentzh@gmail.com>
sub   rsa2048 2013-02-18 [E]

Alad · 2021-11-04 20:01:40

The monstrosity your AUR helper runs forces makepkg to run as a different user, which likely does not have the GPG key imported.

ive · 2021-11-04 21:08:53

Thank you for your reply!

To avoid GnuPG to use the $HOME by default (according to https://wiki.archlinux.org/title/GnuPG) I set the GNUPGHOME environment variable to a fixed directory. Here to a test user 'winnie' having the key added to the keyring.

Unfortunately verifying still fails.

$ gpg --homedir=/home/winnie/.gnupg --finger 25451EB088460026195BD62CB550E09EA0E98066
gpg: WARNING: unsafe ownership on homedir '/home/winnie/.gnupg'
pub   rsa2048 2013-02-18 [SC]
      2545 1EB0 8846 0026 195B  D62C B550 E09E A0E9 8066
uid           [ unknown] Yichun Zhang (agentzh) <agentzh@gmail.com>
sub   rsa2048 2013-02-18 [E]

$ export GNUPGHOME=/home/winnie/.gnupg
$ gpg --finger 25451EB088460026195BD62CB550E09EA0E98066
gpg: WARNING: unsafe ownership on homedir '/home/winnie/.gnupg'
pub   rsa2048 2013-02-18 [SC]
      2545 1EB0 8846 0026 195B  D62C B550 E09E A0E9 8066
uid           [ unknown] Yichun Zhang (agentzh) <agentzh@gmail.com>
sub   rsa2048 2013-02-18 [E]

$ pikaur -S openresty
..
==> Verifying source file signatures with gpg...
    openresty-1.19.9.1.tar.gz ... FAILED (unknown public key B550E09EA0E98066)
==> ERROR: One or more PGP signatures could not be verified!
..

loqs · 2021-11-04 21:10:16

What is the outcome when you use makepkg instead of pikaur?

Alad · 2021-11-05 00:14:41

ive wrote:

Thank you for your reply!
To avoid GnuPG to use the $HOME by default (according to https://wiki.archlinux.org/title/GnuPG) I set the GNUPGHOME environment variable to a fixed directory. Here to a test user 'winnie' having the key added to the keyring.

That variable is not passed on to the systemd dynamic user. So just use makepkg as hinted at above.

ive · 2021-11-05 20:50:02

Thank you for your replies and knowledge notes !

Ah, ok. That's tricky ... although difficult to understand that accessing a keyring cannot be accessed via a path variable.
The AUR helper I am using, pikaur (https://wiki.archlinux.org/title/AUR_helpers) (was a recommendation), takes a secure approach by using systemd dynamic users (http://0pointer.net/blog/dynamic-users- … stemd.html) BUT with regard to package verification (user's keyring) GnuPG can't make use of GNUPGHOME environment variable since "variable is not passed on to the systemd dynamic user". Mhhh.

loqs · 2021-11-05 21:01:41

Have you looked at DeveloperWiki:Building_in_a_clean_chroot? Which builds in a user namespace without a dynamic user but does support signature verification including a custom gpg dir specified by GNUPGHOME.

Last edited by loqs (2021-11-05 21:02:27)

Alad · 2021-11-06 22:00:52

the AUR helper I am using, pikaur (https://wiki.archlinux.org/title/AUR_helpers) (was a recommendation), takes a secure approach by using systemd dynamic users

There's nothing secure about pikaur. All it does is obscure both the package building (through obscure command lines) and installation process (by suppressing the pacman output, and passing arbitrary input to it).

Pacman wrappers making no distinction between AUR and official repository packages doesn't help either.

Have you looked at DeveloperWiki:Building_in_a_clean_chroot? Which builds in a user namespace

There's nothing secure about that either. It runs makepkg --verifysource on the host to retrieve sources beforehand. That's fine for trusted repository PKGBUILDs, not random stuff from AUR. Side-note: devtools neither uses -U nor --private-users for its systemd-nspawn commands.

Just read the PKGBUILDs. Even when done correctly, building packages in an isolated environment can only shield against basic mistakes. The eventual built package will be installed on the host, and have root access (e.g. through commands in the .install file).

Last edited by Alad (2021-11-06 22:09:26)

loqs · 2021-11-06 22:17:44

Alad wrote:

loqs wrote:
Have you looked at DeveloperWiki:Building_in_a_clean_chroot? Which builds in a user namespace
There's nothing secure about that either. It runs makepkg --verifysource on the host to retrieve sources beforehand. That's fine for trusted repository PKGBUILDs, not random stuff from AUR. Side-note: devtools neither uses -U nor --private-users for its systemd-nspawn commands.

Thank you for the correction about devtools not using user-namespaces. I should have stated it should not be considered a secure build environment. I was suggesting it only for the reason I stated.

Alad wrote:

Just read the PKGBUILDs. Even when done correctly, building packages in an isolated environment can only shield against basic mistakes. The eventual built package will be installed on the host, and have root access (e.g. through commands in the .install file).

Completely agree. As the signatures and checksums are contained in the PKGBUILD you can not trust those without trusting the PKGBUILD.

Last edited by loqs (2021-11-06 22:18:01)

Arch Linux

#1 2021-11-04 19:56:52

AUR Issue, keyring » ERROR: PGP signatures could not be verified

#2 2021-11-04 20:01:40

Re: AUR Issue, keyring » ERROR: PGP signatures could not be verified

#3 2021-11-04 21:08:53

Re: AUR Issue, keyring » ERROR: PGP signatures could not be verified

#4 2021-11-04 21:10:16

Re: AUR Issue, keyring » ERROR: PGP signatures could not be verified

#5 2021-11-05 00:14:41

Re: AUR Issue, keyring » ERROR: PGP signatures could not be verified

#6 2021-11-05 20:50:02

Re: AUR Issue, keyring » ERROR: PGP signatures could not be verified

#7 2021-11-05 21:01:41

Re: AUR Issue, keyring » ERROR: PGP signatures could not be verified

#8 2021-11-06 22:00:52

Re: AUR Issue, keyring » ERROR: PGP signatures could not be verified

#9 2021-11-06 22:17:44

Re: AUR Issue, keyring » ERROR: PGP signatures could not be verified

Board footer