AUR packages can't pass PGP check.

[k4z4n0v4]

Packages that require PGP checks error out even if you have the keys in your keyring. I'm guessing the issue is that it check's the root's keyring somehow and fails to find anything. Building the same packages through makepkg works just fine.

$ sudo aura -Akax readline-athame-git

aura >>= readline-athame-git PKGBUILD changes:
aura >>= Determining dependencies...
aura >>= AUR Packages:
readline-athame-git
aura >>= Continue? [Y/n]
aura >>= Building readline-athame-git...
==> Making package: readline-athame-git 8.0.0-1 (Tue 26 May 2020 09:08:42 AM +04)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Updating athame git repo...
Fetching origin
-> Updating vimbed git repo...
Fetching origin
-> Found readline-8.0.tar.gz
-> Found readline-8.0.tar.gz.sig
-> Found inputrc
==> Validating source files with md5sums...
athame ... Skipped
vimbed ... Skipped
readline-8.0.tar.gz ... Passed
readline-8.0.tar.gz.sig ... Skipped
inputrc ... Passed
==> Verifying source file signatures with gpg...
readline-8.0.tar.gz ... FAILED (unknown public key BB5869F064EA74AB)
==> ERROR: One or more PGP signatures could not be verified!
aura >>= There was a makepkg failure.
aura >>= Would you like to continue anyway? [Y/n]

$ gpg --list-keys

...
pub dsa1024 2004-08-02 [SC]
7C0135FB088AAF6C66C650B9BB5869F064EA74AB
uid [ unknown] Chet Ramey chet@cwru.edu
sub elg1024 2004-08-02 [E]

[fosskers]

Thanks for reporting, I'll look into this.

[fosskers]

Unfortunately I was not able to reproduce the issue. Which version of aura are you using?

[k4z4n0v4]

On the release version 3.0.0, using aura-bin from AUR.

EDIT: Tried cloning the master branch, and building/installing with stack. The results are the same.

[k4z4n0v4]

Here's what I found. I have my gpg home directory changed to ~/.local/share/gnupg through the GNUPGHOME env variable. Bringing it back to home resolved the issue. Still would like it to have worked as is, can't seem to get what causes the incompatibility. Have tried running sudo with -E didn't work either.

[fosskers]

Aura calls down to makepkg like this:

runStyle :: User -> [String] -> (FilePath, [String])
runStyle (User usr) opts = ("sudo", ["-u", T.unpack usr, makepkgCmd] <> opts)

So the call would look like sudo -u joe /usr/bin/makepkg. Note that the sudo here isn't elevating privileges, it's dropping down into the joe user to please makepkg. Perhaps in doing so, the environment of joe isn't adopted? Perhaps the root environment is used?

[fosskers]

I tested it. The env availabe when you use sudo -u <foo> is the same env as the root user. Only the PATH and TERM values are shared.

[k4z4n0v4]

Yes. -E flag exists for sudo that should preserve environment, but it doesn't in this case. Haven't tried adding the -E to runStyle though. That could work but I can't test now.

[k4z4n0v4]

Here's what I came up with. I added -E to both make and runStyle in MakePkg.hs.I found out that the initial command i call with sudo (the blue highlighted process in htop) inherits the environment but the child process it spawns after, inherits none of my user's environment, hence when the thing comes to the -E with makepkg it has nothing to inherit. But passing -E to the initial call makes the rest of them inherit the environment, and it all works. Could be used as a workaround for now.

[k4z4n0v4]

Adding -E to make in MakePkg.hs seemed to be excessive, so I left it only in runStyle. With this config, running aura with sudo -E instead of just sudo makes the /usr/bin/makepkg process inherit all the environment and use the correct gpg directory. I'd propose actually saving GNUPGHOME ( and some other env variables that might be an issue) in Types.hs as i think it's used for that, and try to use them to set up the environment during runStyle. Would make running sudo with -E unneeded.

[fosskers]

Asking the user to use -E actually seems like a decent solution to me. It would be much less work for them than adding extra settings in say aura.conf, which also has the risk of drifting/desyncing from the actual env that the user has.

How about I add -E to runStyle as you've done, since that shouldn't cause any harm in the usual case, and then ask people to use sudo -E at the top level when they need such pass-through?

[k4z4n0v4]

Guess it might work. I'll try to see if I can fix it painlessly, meanwhile the hotfix should work.

[chmln]

Hey @fosskers just wanted to say thank you for your great work on aura 🚀

I also have a similar issue with environment variables not getting passed through when building npm packages. Using -E with sudo would be a totally reasonable and explicit solution.

[fosskers]

Great guys, I'll add this tomorrow (Monday).

[fosskers]

That should do it. I'll make a release today too.

[fosskers]

Unfortunately I had to revoke the -E due to it causing a lot of unforeseen issues for users. I've released this as 3.1.2. We'll have to revisit the issue of environment variables entirely.

[k4z4n0v4]

I had thought stuff like this would arise, using -E should be a rare-case action. I think fetching env variables into aura would be the best possible solution.

[fosskers]

Perhaps setting them in aura.conf is the best approach after all. Then when sudo -u <user> makepkg is called, those env vars can be passed down into it as well.