[pacman-dev] [PATCH 2/2] pacman-key: make sure we actually use the Web of Trust, which GnuPG doesn't.

[Allan McRae]

On 6/8/19 2:53 am, Eli Schwartz wrote:
> By default, the latest versions of GnuPG disable the Web of Trust and
> refuse to import signatures from public keyservers. This is to prevent
> denial of service attacks, because refusing to import signatures only if
> the key size is too big, is apparently too silly to consider.
> 
> Either way, pacman needs the WoT. If pacman imports a key at all, it
> means everything failed and we are in fallback mode, trying to overcome
> a shortcoming in the availability of keys in the keyring package.
> (This commonly means the user needs to acquire a new key during the same
> transaction that updates archlinux-keyring.)
> In order for that new key to be usable, it *must* also import signatures
> from the Master Keys.
> 
> I don't give credence to this supposed DoS, since the worst case
> scenario is nothing happening and needing to CTRL+C in order to exit the
> program. In the case of pacman, this is better than being unable to
> install anything at all (which is gnupg doing a much more harmful DoS to
> pacman), and in the already unusual case where something like
> --refresh-keys is being used directly instead of depending on the
> keyring package itself, gnupg supports WKD out of the box and will
> prefer that for people whose keys are marketed as being non-DOSable.
> 
> Signed-off-by: Eli Schwartz <eschwartz at archlinux.org>
> ---
> 
> I've been sitting on this for a bit, but this does seem to be the best
> way to implement a reversion to the old method.

I think this fine.

> Feel free to bikeshed
> about version checks in pacman-key!

Well...  see below...

> This is independent of the WKD patchset, and works for people without
> @archlinux.org uids, or more generally for pacman downstreams that don't
> have a WKD infrastructure.
> 
> In the long run, I expect the keyservers to implement less insane DoS
> mitigations, for example, an evolution of hagrid that supports mutually
> signed keys. I don't know if I should hold my breath waiting for gnupg
> to get proper error checking, though!
> Once proper mitigations exist, we'd need to disable the builtin default
> self-sigs-only,import-clean anyway, assuming gnupg itself didn't roll
> back these settings. 
> 
>  scripts/pacman-key.sh.in | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in
> index c3b02850..d6ba0e3b 100644
> --- a/scripts/pacman-key.sh.in
> +++ b/scripts/pacman-key.sh.in
> @@ -210,6 +210,11 @@ initialize() {
>  	add_gpg_conf_option "$conffile" 'lock-never'
>  	add_gpg_conf_option "$conffile" 'keyserver-options' 'timeout=10'
>  
> +	local gpg_ver=$(gpg --version | awk '{print $3; exit}')

I very much dislike relying on output format from some other piece of
software.  But looking at the gpg code, this is quite stable, so allowable.

> +	if (( $(vercmp "$gpg_ver" 2.2.17) >= 0 )); then
> +		add_gpg_conf_option "$conffile" 'keyserver-options' 'no-self-sigs-only,no-import-clean'

Doesn't import-clean actually do what we want?   Strips signatures from
keys not in the keyring?  Assuming users are not setting up the initial
keyring by importing keys manually...

> +	fi
> +
>  	# gpg-agent.conf
>  	agent_conffile="${PACMAN_KEYRING_DIR}/gpg-agent.conf"
>  	[[ -f $agent_conffile ]] || touch "$agent_conffile"
>