actionless / pikaur

AUR helper with minimal dependencies. Review PKGBUILDs all in once, next build them all without user interaction.
GNU General Public License v3.0
867 stars 87 forks source link

GPG with systemd dynamic users #340

Open Craeckie opened 5 years ago

Craeckie commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

anonymous133 commented 5 years ago

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 commented 5 years ago

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

RubenKelevra commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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

thanks in advance :)

gnfzdz commented 2 years ago

@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:

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

actionless commented 2 years ago

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 commented 2 years ago

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.