WKD proper behavior on fetch error

[André Colomb]

Hi Ángel,

thanks for your contribution with a clear focus.

On 14/01/2021 01.47, Ángel wrote:
> Probably the most important part of the rule: "all implementations of
> WKD should behave in the same way". I don't mind if it was gnupg that
> was changed to behave like sequoia, but given identical conditions,
> ideally all clients (and the draft reading) should produce the same
> result (find key X, an error, etc.).

I agree with that.  And the next draft version SHOULD be very clear
about this to avoid future discussions :-)

> I would recommend to remove the or_else case and fail with an error if
> the advanced method is (supposedly) set up but fails. At least, I think
> there should be a diagnostic e.g. "WKD advanced method configured but
> broken. Connection to openpgpkey.foo.com (1.2.3.4) failed: Bad
> certificate. Trying direct method" although I would prefer a hard
> error.

Definitely, the decision which method to try should be very simple, as
the WKD draft intended.  Only one decision point instead of many paths
leading back to a change of method.

> (Of course, if the user explicitly requested the client/library to only
> use the direct method, ignore certificate errors, etc. it'd be fine to
> do so)

That's an excellent suggestion, giving Sequoia an option to force trying
one method or the other.  I don't know if adding as many command line
switches as gpg has is your cup of tea, but e.g. an environment variable
could be used to really make it a "debugging" type of option.  The great
benefit is that Sequoia can then act as a WKD checker, which should
always examine the intended, but possibly misconfigured, method or even
both.

> PPS: Another benefit would be that we could have avoided this long
> thread. :-)

I couldn't resist trying to help Stefan understand where the error lies,
so apologies for my share of the message flood :-)

Kind regards
André

-- 
Greetings...
From: André Colomb <andre at colomb.de>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210114/5363296d/attachment-0001.sig>