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 <eschwa...@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" >