[pacman-dev] [PATCH v2] pacman-key: --refresh-keys queries WKD before keyserver

[Eli Schwartz]

On 2/24/21 7:57 AM, Allan McRae wrote:
> On 22/2/21 9:09 am, Morten Linderud wrote:
>> From: Morten Linderud <morten at linderud.pw>
>>
>> With the recent outages of the keyservers there is a possibility of
>> `--refresh-keys` failing to fetch new keys. A lot of current key
>> distribution is done over WKD these days, and `pacman-key` has the
>> ability to use it for `--recv-key`.
>>
>> There was a hope `gpg` would end up supporting WKD for the refresh
>> functionality, but this seems to be limited to expired keys fetched
>> through WKD. Since this functionality isn't yet available it makes sense
>> to stuff it into `pacman-key`.
>>
>> The current implementation looks over all available keyids in the
>> keyring, attempts to fetch over WKD and then fall backs to keyservers if
>> no email has a valid WKD available. The downside of this approach is
>> that it takes a bit longer to refresh the keys, but it should be more
>> robust as the distribution should be providing their own WKDs.
>>
>> Co-authored-by: Jonas Witschel <diabonas at archlinux.org>
>> Signed-off-by: Morten Linderud <morten at linderud.pw>
>> ---
>>
>> * Done grep -vx
>>
>> * Removed the redundant error since it's caught by `check_keyids_exist`
>>
>> * Improved the error message with the keyid
>>
>>
>>  scripts/pacman-key.sh.in | 33 +++++++++++++++++++++++++++++----
>>  1 file changed, 29 insertions(+), 4 deletions(-)
>>
>> diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in
>> index c65669f5..e89d7af9 100644
>> --- a/scripts/pacman-key.sh.in
>> +++ b/scripts/pacman-key.sh.in
>> @@ -540,11 +540,36 @@ receive_keys() {
>>  }
>>  
>>  refresh_keys() {
>> +	local ret=0 ids masterkey emails
>> +
>>  	check_keyids_exist "$@"
>> -	if ! "${GPG_PACMAN[@]}" --refresh-keys "$@" ; then
>> -		error "$(gettext "A specified local key could not be updated from a keyserver.")"
>> -		exit 1
>> -	fi
>> +
>> +	# don't try to refresh the user's local masterkey
>> +	masterkey="$("${GPG_PACMAN[@]}" --list-keys --with-colons pacman at localhost |
>> +		awk -F: '$1 == "pub" { print $5 }')"
>> +
>> +	mapfile -t ids < \
>> +		<("${GPG_PACMAN[@]}" --list-keys --with-colons "$@" |
>> +			awk -F: '$1 == "pub" { print $5 }' | grep -vx "$masterkey")
>> +
>> +	for id in "${ids[@]}"; do
>> +		mapfile -t emails < \
>> +			<("${GPG_PACMAN[@]}" --list-keys --list-options show-only-fpr-mbox "$id" |
>> +				awk '{print $2 }')
>> +
>> +		# first try looking up the key in a WKD (only works by email address)
>> +		for email in "${emails[@]}"; do
>> +			"${GPG_PACMAN[@]}" --locate-external-keys "$email" && break
>> +		done
>> +
>> +		# if no key was found, fall back to using the keyservers (with the key fingerprint instead)
>> +		if (( $? )) &&  ! "${GPG_PACMAN[@]}" --refresh-keys "$id"; then
>> +			error "$(gettext "The following key could not be updated from WKD or keyserver: %s")" "$id"
> 
> This error message is verbose.  "The following key..."  is not needed.
> It would be strange if we listed the key id not associated with the
> message!  And the user does not care that both WKD and keyserver failed,
> just that there is a failure.
> 
> How about:
> 
> error "$(gettext "Could not update key: %s") "$id"

https://bugs.archlinux.org/task/69865

:p

>> +			ret=1
>> +		fi
>> +	done
>> +
>> +	exit $ret
>>  }
>>  
>>  verify_sig() {
>>


-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20210302/9a222800/attachment.sig>