Allan, That is correct. GnuPG's default setup is to enable the scdaemon support, which in the case of Pacman-keys, we don't really /ever/ want by default as it will cause more problems than not, since pacman is designed to use its own master key for everything, including locally signing. Without disabling the scdaemon, gnupg will try to use scdaemon, see that there's a SmartCard, and try to use it to verify and locally sign things with it, which will of course fail, since the pacman gnupg keyring has no knowledge of the smartcard. Some may call this a pacman bug, others a gnupg bug, but the fact of the matter is, the way pacman is specifically trying to use gnupg, this simple solution solves the actual issue by simply disabling smartcard use. Eric Renfro On 2018-03-14 2:02 am, Allan McRae wrote:

On 27/02/18 23:27, Eric Renfro via pacman-dev wrote:

...

This fixes an issue where smartcards, such a Yubikey, would cause the keyring to fail locally signing, thus also failing to verify signed packages.

I have been trying to figure out the issue here...

Is the issue that when a smartcard is plugged in, the pacman tries to use that to locally sign the keys and not the master key in the pacman keyring?

...

Signed-off-by: Eric Renfro --- scripts/pacman-key.sh.in | 6 ++++++ 1 file changed, 6 insertions(+)

diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in index 5bf6c7a1..72b64aa4 100644 --- a/scripts/pacman-key.sh.in +++ b/scripts/pacman-key.sh.in @@ -210,6 +210,12 @@ initialize() { add_gpg_conf_option "$conffile" 'lock-never' add_gpg_conf_option "$conffile" 'keyserver-options' 'timeout=10'

+ # gpg-agent.conf + agent_conffile="${PACMAN_KEYRING_DIR}/gpg-agent.conf" + [[ -f $agent_conffile ]] || touch "$agent_conffile" + chmod 644 "$agent_conffile" + add_gpg_conf_option "$agent_conffile" 'disable-scdaemon' + # set up a private signing key (if none available) if [[ $(secret_keys_available) -lt 1 ]]; then generate_master_key