aurto
aurto copied to clipboard
alexheretic
Cannot build signed packages with alternative GNUPGHOME
The update-aurto service is not able to find PGP keys for building signed AUR packages:
% gpg --recv-keys DBE7D3DD8C81D58D0A13D0E76BC26A17B9B7018A
gpg: key 6BC26A17B9B7018A: 12 duplicate signatures removed
gpg: key 6BC26A17B9B7018A: 33 signatures not checked due to missing keys
gpg: key 6BC26A17B9B7018A: 12 signatures reordered
gpg: key 6BC26A17B9B7018A: "Alad Wenter <[email protected]>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
Oct 28 16:27:01 leo update-aurto[90105]: ==> WARNING: PACKAGER should have the format 'Example Name <[email protected]>'
Oct 28 16:27:01 leo update-aurto[90105]: ==> Making package: aurutils 2.3.2-1 (Mon Oct 28 16:27:01 2019)
Oct 28 16:27:01 leo update-aurto[90105]: ==> Retrieving sources...
Oct 28 16:27:01 leo update-aurto[90105]: -> Found aurutils-2.3.2.tar.gz
Oct 28 16:27:01 leo update-aurto[90105]: -> Found aurutils-2.3.2.tar.gz.asc
Oct 28 16:27:01 leo update-aurto[90105]: ==> Validating source files with sha256sums...
Oct 28 16:27:01 leo update-aurto[90105]: aurutils-2.3.2.tar.gz ... Passed
Oct 28 16:27:01 leo update-aurto[90105]: aurutils-2.3.2.tar.gz.asc ... Skipped
Oct 28 16:27:01 leo update-aurto[90105]: ==> Verifying source file signatures with gpg...
Oct 28 16:27:01 leo update-aurto[90105]: aurutils-2.3.2.tar.gz ... FAILED (unknown public key 6BC26A17B9B7018A)
Oct 28 16:27:01 leo update-aurto[90105]: ==> ERROR: One or more PGP signatures could not be verified!
Oct 28 16:27:01 leo update-aurto[90105]: ==> ERROR: Could not download sources.
Oct 28 16:27:01 leo update-aurto[90105]: `aur sync --no-view --no-confirm --database=aurto --makepkg-conf=/etc/aurto/makepkg-chroot.conf --chroot --upgrades` failed with exit code 255 ✗
Oct 28 16:27:01 leo sudo[90119]: pam_unix(sudo:session): session closed for user patrick
Oct 28 16:27:01 leo systemd[1]: update-aurto.service: Main process exited, code=exited, status=255/EXCEPTION
Oct 28 16:27:01 leo systemd[1]: update-aurto.service: Failed with result 'exit-code'.
I'm 99% certain this is because I use an alternate GNUPGPHOME.
I should be able to make this available to the service, by:
% sudo systemctl cat update-aurto.service
# /usr/lib/systemd/system/update-aurto.service
[Unit]
Description=Updates 'aurto' repo
After=network-online.target
Wants=network-online.target
[Service]
ExecStart=/usr/lib/aurto/update-aurto
# /etc/systemd/system/update-aurto.service.d/10-gnupg.conf
[Service]
Environment=GNUPGHOME=/home/patrick/.config/gnupg
But this does not work.
I believe it comes down to how you invoke sudo, e.g.:
echo "Running: aur sync --no-view --no-confirm --database=aurto --makepkg-conf=/etc/aurto/makepkg-chroot.conf $chroot_arg --upgrades" >&2
sudo -u "$user" \
Without --preserve-env/-E, sudo will not pass that GNUPGHOME on to the invoked command, so it won't be able to find my keys.
I'm not sure the best way to fix this, since my initial attempt at just adding -E lead to other issues with other environment variables.
Does running aur sync ... directly from your user session work ok with gpg?
It does. And I would expect it to because GNUPGPHOME is set in my shell environment and nothing is clearing it (like sudo does when invoked via update-aurto).
Ok, this does sound like something that should have a decent workaround. A root timer running commands as a user a bunch maybe isn't very common. So I'm not sure if there are standard ways to do this.
Perhaps if we had a /etc/aurto/user-rc file that was marked as config? This would allow setting env vars. Initially blank, run before each user command.
Otherwise I'm open to suggestions.
So I'm not sure if there are standard ways to do this.
I think there's a way to have it not be a root timer; the whole thing could just run as a user, IIRC. Something like:
% sudo systemctl enable [email protected]
Then the unit file uses User=%i... or something, and /usr/lib/aurto/update-aur should just assume it's non-root and not use sudo at all.
That direction sounds more The Right Way to me, but :man_shrugging: .
Otherwise I'm open to suggestions.
I would consider a super narrow fix:
echo "Running: aur sync --no-view --no-confirm --database=aurto --makepkg- conf=/etc/aurto/makepkg-chroot.conf $chroot_arg --upgrades" >&2
sudo -u "$user" \
+ env GNUPGPHOME="$GNUPGPHOME" \
"$lib_dir"/summerize-build \
aur sync --no-view --no-confirm --database=aurto \
--makepkg-conf=/etc/aurto/makepkg-chroot.conf $chroot_arg --upgrades
I think it's reasonable to expect the end user to know (or figure out, maybe through docs or some FAQ around here) that they need to deal with the systemd-level concern, so I don't mind that a fix here still requires a unit drop-in to ensure the correct GNUPGPHOME is seen outside the sudo to begin with.
At that point, what you've done is an explicit sudo --preserve-env of just those variables that you know need to be preserved for aur-sync/makepkg to function, which seems very conceptually reasonable to me.
It's attractive to make the list of env to preserve configurable, but I'd hesitate there. It's possible GNUPGPHOME is the only thing ever needed, and it's not harmful to send it empty when it's not, so might as well avoid the complexity, IMO.
I guess I'm more interested in configurable env vars in general rather than just this one.
One workaround for your case, could you import aur keys additionally into the default gpg home?
I would like to have aurto running more as the user, I think some config can move into ~. But there is some root stuff it has to do too currently.
I guess I'm more interested in configurable env vars in general rather than just this one.
Yeah, I hear you. I was just saying that (FWIW, IMHO) seems like YAGNI to me.
One workaround for your case, could you import aur keys additionally into the default gpg home?
I will probably end up there, yeah. The whole point of setting GNUPGPHOME was to help with "dotfiles clutter" though, so it'd be sad for this workaround to create exactly that... For now, I'm just noticing the error in my logs when a signed update happens to come down, and I update it manually outside the service. We'll see how long I'm willing to go that way :)
I would like to have aurto running more as the user, I think some config can move into ~. But there is some root stuff it has to do too currently.
Yeah, I would definitely pursue this option if I were you; the current approach feels fraught with unknown edge-cases just waiting to crop up.
Would it be weird to have installation of aurto require adding password-less sudo for the commands it needs to run as root from a non-interactive environment?
It could be done pretty smoothly, IMO, with a sudoers.d drop-in file using a group.. wait, I actually have a 50_aurto_passwordless sitting in there right now... it seems what I'm suggesting already mostly exists?
Yes it would be interesting to see how far we can get with update-aurto as a user timer, and with the config all in the home directory. On the face of it, I'd say it looks promising. This should get rid of the installing user being saved at /usr/lib/aurto/user which was always a bit weird. Maybe the aurto repo would work in the home dir too.
I'm not totally comfortable with the 50_aurto_passwordless, in general. But the pacsync aurto seems quite safe. The other two I had to do to allow aurutils to work without root password. Maybe I can lock them down a little.
You should take some care with pacsync aurto due to usual concerns with partial upgrades. This holds, especially with chroot builds, which always build against the latest available packages.
You should take some care with pacsync aurto due to usual concerns with partial upgrades. This holds, especially with chroot builds, which always build against the latest available packages.
aurto output always suggests to install packages with pacman -Syu foo because of this. I don't think there's a reasonable way of supporting outdated repos with makepkgchroot building. And tbh I'm not really interested in that use case, so I'd advise users that need that to avoid aurto and for everyone else to use -Syu.