GPG with systemd dynamic users

[Craeckie]

When using dynamic users (alwaysusedynamicusers) I have trouble adding gpg keys.

When building a package which uses gpg to verify integrity I get (unknown public key ...). Running gpg --recv-keys normally or with sudo doesn't help, because the dynamic user uses a different trust db.

How can I add keys to the trustdb of dynamic users? Do they have any trustdb?

The log:

==> Verifying source file signatures with gpg...
    aurutils-2.2.0.tar.gz ... FAILED (unknown public key 6BC26A17B9B7018A)
==> 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: 8.183s

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

[actionless]

try:

systemd-run --pipe --wait -p DynamicUser=yes -p CacheDirectory=pikaur -E HOME=/tmp -p WorkingDirectory=/var/cache/pikaur/build/aurutils gpg --recv-keys 6BC26A17B9B7018A

[Craeckie]

I tried, but it doesn't work, because /tmp is a new directory for each execution. You can easily reproduce that by running systemd-run --pipe --wait -p DynamicUser=yes -p CacheDirectory=pikaur -E HOME=/tmp -p WorkingDirectory=/var/cache/pikaur/build/aurutils sh -c 'touch /tmp/test' and systemd-run --pipe --wait -p DynamicUser=yes -p CacheDirectory=pikaur -E HOME=/tmp -p WorkingDirectory=/var/cache/pikaur/build/aurutils sh -c 'ls /tmp/test' The second command fails, because /tmp is a different directory, even when both dynamic users run simultaneously (by opening two shells).

So when /tmp/.gnupg is created in the context of one systemd-run it is not available when running the same command again.

[Craeckie]

One workaround could be to create the trustdb manually and then force its use in systemd-run:

Create the trustdb: mkdir -p /etc/gnupg/certs export GNUPGHOME=/etc/gnupg/certs gpg --recv-keys 6BC26A17B9B7018A

And set the environment variable in systemd-run: systemd-run --pipe --wait -p DynamicUser=yes -p CacheDirectory=pikaur -E HOME=/tmp -p WorkingDirectory=/var/cache/pikaur/build/aurutils -E GNUPGHOME=/etc/gnupg/certs gpg --finger 6BC26A17B9B7018A

[Craeckie]

I was able to add the env variable to the systemd-run in core.py:

diff --git a/pikaur/core.py b/pikaur/core.py
index 22f994a..fc026f7 100644
--- a/pikaur/core.py
+++ b/pikaur/core.py
@@ -141,6 +141,7 @@ def isolate_root_cmd(cmd: List[str], cwd=None) -> List[str]:
         '-p', 'DynamicUser=yes',
         '-p', 'CacheDirectory=pikaur',
         '-E', 'HOME=/tmp',
+        '-E', 'GNUPGHOME=/etc/gnupg/certs',
     ]
     if cwd is not None:
         base_root_isolator += ['-p', 'WorkingDirectory=' + cwd]

Would it be possible to add a config option for setting custom ENV variables?

[actionless]

Would it be possible to add a config option for setting custom ENV variables?

it sound like quite a specific option but since there's not other solution so far -- it could be possible. would you like to add it yourself?

[anonymous133]

Hi, just to let you know it happends on firefox-nightly, too.

Is there any solution available, yet? I'm not as a professional user as Craeckie but concluded that it has to do with the dynamic user that is used. Thats what got me here.

[actionless]

does the solution from the comment above works for you https://github.com/actionless/pikaur/issues/340#issuecomment-456719853 ?

[anonymous133]

Oh, I tried your suggestion in the second comment which worked.

But besides that I don't have /etc/gnupg folder to begin with. Not in my home folder nor in root.

[actionless]

that's weird since it didn't worked for another guy :D

[RubenKelevra]

Oh, I tried your suggestion in the second comment which worked.

But besides that I don't have /etc/gnupg folder to begin with. Not in my home folder nor in root.

Maybe you haven't used GPG at all?

I had run into this issue on archlinux installations in the past, when I couldn't run pacman-key on the archlinux iso. Starting a dirmngr helped in this case:

dirmngr < /dev/null

Note the section about --homedir in the man page:

--homedir dir
              Set  the  name of the home directory to dir.  This option is only effective when used on the command line.  The default is the directory named ‘.gnupg’ directly
              below the home directory of the user unless the environment variable GNUPGHOME has been set in which case its value will be used.  Many kinds of data are stored
              within this directory.

[anonymous133]

Oh, I tried your suggestion in the second comment which worked. But besides that I don't have /etc/gnupg folder to begin with. Not in my home folder nor in root.

Maybe you haven't used GPG at all?

I had run into this issue on archlinux installations in the past, when I couldn't run pacman-key on the archlinux iso. Starting a dirmngr helped in this case:

dirmngr < /dev/null

Note the section about --homedir in the man page:

--homedir dir
              Set  the  name of the home directory to dir.  This option is only effective when used on the command line.  The default is the directory named ‘.gnupg’ directly
              below the home directory of the user unless the environment variable GNUPGHOME has been set in which case its value will be used.  Many kinds of data are stored
              within this directory.

Thanks! I've found it in home/USER/.gnupg thanks to your man page excerpt. I do have the same issue with the spotify installation. When an update for it arrives I will post here how it went.

[RubenKelevra]

Thanks! I've found it in home/USER/.gnupg thanks to your man page excerpt. I do have the same issue with the spotify installation. When an update for it arrives I will post here how it went.

Note that you can always skip the GPG check, if you cannot install the package otherwise.

Usually the GPG-Check is done additionally to a regular checksum comparison, helping to build trust that the binary wasn't tampered with, before the maintainer added it to the AUR and is really from the author of the software.

The quality of the signature on the other hand largely depends on the author of the software. If publishing is automated, signing of the binary might be as well. So no trust can be gained by comparing the signature with the file, since everyone who could tamper with the file could also trigger an automated signature.

In case of Spotify I doubt someone really reviews the binary, the process of a release is probably highly automated.

[adlerweb]

For those searching along: The block in question is currently at https://github.com/actionless/pikaur/blob/8c50de18a0ea00d873269313d0a73e2dabddb4c4/pikaur/core.py#L183

I too did not have a /etc/gnupg folder. One can created a new keyring using mkdir /etc/gnupg && gpg --homedir /etc/gnupg --import.

However another idea: How about setting -E', 'GNUPGHOME=/etc/pacman.d/gnupg', und using pacmans native keyring also for AUR? This should exist on all systems. Another idea used by other wrappers is to clone the current users keyring into a safe location and use this for the build.

[actionless]

feel free updating FAQ section of pikaur readme if you think you found the working solution(s)

thanks in advance :)

[gnfzdz]

@actionless As far as I can tell there still doesn't seem to be a built in solution here?

Would you be open to a PR with the following changes:

• A new configuration option to pikaur.conf setting the gpg home for use with makepkg (section: [build] / option: GpgHome )
• Set the default value for this configuration option to something reasonable when run as root, either:
  • /etc/pacman.d/gnupg (the pacman gnupghome)
  • /etc/pikaur.d/gnupg (mirroring the pacman layout)
• A command line argument to allow overriding the directory per invocation (--makepkg-gpgdir ? I don't particularly like this name)

Let me know if the above sounds reasonable and I'll take a stab at it.

[actionless]

Set the default value for this configuration option to something reasonable when run as root, either: /etc/pacman.d/gnupg (the pacman gnupghome)

i wonder if this could be still useful for anyone or not

[gnfzdz]

I'm open to adding it. I initially left it out as I feel a bit conflicted though.

It's removing the default separation between the set of keys trusted for build vs install. That's probably not a big deal with just the system defaults, but my concern is if it encourages a user to start adding keys required to build arbitrary packages from the aur.