On 05/12/14 12:50, Gaetan Bisson wrote:
[2014-12-01 16:31:28 -1000] Gaetan Bisson:
Right. It seems porting the pacman keyring from pre-2.1 to 2.1 mishandles the no-password case: signing anything with the resulting master key fails. We should be able to fix that by manually fiddling with the keyring, but I haven't found how yet.
As you point out, recreating a fresh keyring with gnupg-2.1 is the easiest solution, though it will inconvenience users that have already imported and signed keys locally. I suggest we post a news item advising all users to do that.
How about the following news announcement:
The upgrade to gnupg-2.1 tampered with the pacman keyring in a way that rendered the local master key unable to sign other keys. This is only an issue if you ever intend to customize your pacman keyring. We nevertheless recommend all users regenerate a fresh keyring using:
sudo pacman -Syu sudo rm -fr /etc/pacman.d/gnupg sudo pacman-key --init sudo pacman-key --populate archlinux
[End of the announcement.]
Additionally, to avoid future issues with pacman-key communication passphrases to gnupg, I suggest updating our pacman package with: - "pinentry-mode loopback" in /etc/pacman.d/gnupg/gpg.conf - "allow-loopback-pinentry" in /etc/pacman.d/gnupg/gpg-agent.conf
See: https://bbs.archlinux.org/viewtopic.php?pid=1480570#p1480570
As far as I can tell, those options are just supposed to allow gpg to work without a pinentry. But we should never require a password to be entered, so it does not matter whether the pinentry is available or not. So I am missing the reason to add this. Also, not that /etc/pacman.d/gnupg/gpg.conf is not owned by the pacman package, but is created by gpg when generating the root key. Allan