WKD and DANE/OPENPGPKEY offer rather distinct properties. I'd be hard-pressed to say that one is "better" than the other without understanding the threat model and concerns of the evaluator:

I also observe that the text in the GUI prompts is remarkably unclear on its own. setting aside the grammar, punctuation, and wording, the prompts don't expose the usage flags set for the secret keys, which is possibly the only detail that a user with a single OpenPGP certificate would care about: "am i deleting my signing-capable subkey or my decryption-capable subkey?"

Please update the documentation for the function in that case.

Please see my explanation on gnupg-devel about why the trailing NUL is a source of pain and difficulty for would-be adopters.

I've just uploaded pinentry 1.1.0-3 to debian unstable with this fix in it.

@aheinecke thanks for the heads-up. i'll pull this in.

@aheinecke

Due to socket forwarding we can have different versions of gpg-agent and gpg / gpgsm because they are on different machines and afaik we try to support it.

fwiw, if the old gcrypt actually returned a radically different API, it should have a larger SONAME across that change, and NEED_LIBGCRYPT_VERSION should reflect a source version that forces it past that SONAME. I don't know what version of libgcrypt behaved differently -- is there a reference for that?

I don't think there's a problem to have a long explanatory message in the main repository, as i think it makes it easier to understand, and space is not an issue.

I've just broken out my changes into two commits, one that makes gpg and gpgsm more robust. That should be applicable without any risk.

I've just posted rGb84feb0c82eb to the dkg-fix-T4652 branch, which solves the failure problems by making agent_pkdecrypt and gpgsm_agent_pkdecrypt more robust.

fwiw, this patch appears to cause gpgsm to fail its test suite:

I've just pushed rG1ae16838660a to the dkg-fix-T4652 branch (i just adjusted it the commit message to include the GnuPG-bug-id)

This report doesn't contain enough information to be able to tell you why the command is failing within your program, but not failing outside of it.

@werner wrote:

Other tasks in master are right now more important.

I've just pushed rE732855a483709345a5c0f49504f45cb8da3f883a to dkg-fix-T4643 in the gpg-error git repository. I don't know why it is not yet visible here.

CC_FOR_BUILD is defined in configure.ac as build system C compiler, not build system C compiler and flags.

I'm aware of you releasing an RC for comments, and i apologize for not catching this particular case earlier. As you know from T4607, i was even advocating for it. i didn't understand the full implications of the "import-then-clean" approach at the time, and was thinking it would only apply to the incoming material, not the stored material.

i've merged a variant of rGbe99eec2b105eb5f8e3759147ae351dcc40560ad into the GnuPG packaging in debian unstable as of version 2.2.17-3 to avoid the risks of data loss and signature verification failures. I'll revert it if i see the concern addressed upstream.

@gniibe, thank you for backporting this to STABLE-BRANCH-2-2!

I don't know why dkg-fix-T4641 is not showing up here on the assuan git repo.

I've just pushed rA45f01593d4ce794ae3562359aee2ff80c97e368e to the dkg-fix-T4641 branch that resolves this.

Thanks for the feedback. I'll go ahead and close any tickets that come in via debian that expect to be able to cross compile without having at least once had a native compiler on the platform to generate the appropriate lock-obj-pub-*.h.

@stm it kind of is a last-resort already, given that it's only in the event where the signature creation dates are equal, but sure, i wouldn't mind adjusting the proposal to say that (sigs) means "sort by date, then issuer, then binary content" -- but what do we think "sort by issuer" means?

does the removal of the gpg22 tag mean that it will not be possible to rely on colon-delimited output for the gpg 2.2 series?

Just a note that we're now shipping this patch in debian unstable. It would be great if it was merged upstream.

that pseudocode is strange to me -- it looks like you have (two) duplicate calls to clean_key (imported_keyblock) (though maybe i just don't know what .... means in this pseudocode).

I think dropping import-clean from the default keyserver options is the right way to go. It is not clear what additional benefit import-clean provides given that we are already using self-sigs-only. And the idea of non-additive behavior to the local keyring when pulling from a keyserver is a deeply surprising change for multiple users i've talked to.

The fact that import-clean modifies already-held certifications makes me think it is inappropriate to have as the default for keyserver access (see T4628 for more details).

Due to T4628, i no longer think that import-clean is a good idea by default.

I am proposing to backport rG33c17a8008c3ba3bb740069f9f97c7467f156b54 and rGa7a043e82555a9da984c6fb01bfec4990d904690 to STABLE-BRANCH-2-2 as they represent a significant performance improvement in several specific use cases and appear to have no downsides.

If you're on a platform that has awk available (any GNU/Linux and macOS should provide it), you can scan for the largest OpenPGP certificate in your keyring with an awk script i posted over at https://dev.gnupg.org/T3972#127356

@gniibe, the documentation (at least on the stable branch) says that --fast-import is just a synonym for --import. is that incorrect?

with @gniibe's patches applied, i profiled the --import, since that is where the largest CPU cost remains. I tried two different times:

i also checked the CPU time for git tag -v, whether @gniibe's patches were applied or not.

fwiw, i tried gpg --import on the ascii-armored version of my C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 OpenPGP certificate (22895014 octets, 54614 certifications), followed by gpg --list-keys and gpg --export | wc. I was comparing 2.2.17-1 (from the debian package in unstable) with the exact same source, just with @gniibe's two patches rG33c17a8008c3 and rGa7a043e82555 applied as well. I did this with GNUPGHOME set to an otherwise empty directory, where i had done touch pubring.gpg to avoid the keybox format. (the two runs did not share a GNUPGHOME).

I agree, many currently-shipped DNS client library implementations do not provide DNSSEC validity checks.

(i think that rG33c17a8008c3ba3bb740069f9f97c7467f156b54 is also relevant, though it was not tagged with this ticket)

@gniibe -- thank you very much for tracking down these O(N^2) operations and cleaning them up. I will profile the effect of those changes and report my findings.

aiui, a keyserver scheme of https:// implies that the specific URL is to be queried directly, not using any of the HKPS URL path patterns.

yes, python2.7 and python3.7

rM7d0a979c07d2 disabled the test for this. @werner says:

This is especially relevant if you are not going to implement the fallback to import-clean that was proposed in T4591.

I see that you have lowered the WKD limit to 64KiB with 6396f8d115f21ae15571b683e9ac9d1d7e3f44f4 -- i think this is a mistake, as reasonable certificates can be several times that size (e.g. zack's cleaned certificate, mentioned above). I'd prefer a limit of 256KiB.

why is this fix not relevant for the 2.2 stable branch? I've had no feedback on this proposed patch.