This is a bug tracker and not a general help line. You are better off asking on the gnupg-uisers mailing list.

Could you try to put no-allow-external-cache in your gpg-agent.conf?
If it changes the behavior, it is your desktop environment which caches your input, I suppose.

I thought I close this after the release of 2.2.18.
Anway, it's done, so, closing.

We use "error ..." and "failed to ..." interchangable. The German translation even uses the same term for both.
Thus I think it would be better to keep the old diagnostic but show it only in --verbose mode.

This should be normal priority as we continue to receive bug reports about UIServer and the usage in GpgEX of the UIServer protocol keeps us from removing it in Kleopatra.

I did not want to move the fingerprint verification process more prominent with an entry field or something like that.

With the new version we get an even more extensive rework of the certify dialog. We now also have support for search tags.

It's probably a wrong encoding in the italian translation. Will be fixed with updating our build system to buster and NSIS-3

I removed it. Looks dead to me.

Is this resolved?

I tuned down the error message. I don't think there is a problem here anymore.

To clarify this for someone other then me:

After T4747 and T4748 are fixed this needs to be added to the installer, but sending Windowmessages is at least easy for NSIS. From the MSI installer this will be more difficult.

See also D475.

Last week:

Last week:

• Bug fixing
• Allow specification of ldaps.

Last week:

• gpgme: Make dist to generate Python doc (RST and TEXinfo) from ORG
• gpgme: qt test failure fix for GnuPG 2.3
• Learn RISC-V for MCU
  • Initial work for Chopstx
  • I realized that the development environment is not mature yet
    • dfu-util requires local patch for GD32VF
      • standard dfu-util (in Debian) is unstable (only stable for 1KB)
    • OpenOCD seems not to work yet

This week:

• Bug fixes for GnuPG
• Back to X448 for GnuPG
• If time remains, work for Chopstx for RISC-V

BTW, since I start my X session with startx, this are the relevant parts I have in my .xinitrc:

So my gpg-agent.conf file looks like this now:

auto key retrieve using just the key id is dangerous because it can lead to a DoS. It is too easy to flood keyservers with several keys have the same keyid. Let's don't give an incentive to the script kiddies trying to pull down the OpenPGP keyservers.

Please add

Adding werner to reviewers since this references his commit.

El vie., 8 nov. 2019 8:19, johnmar (John Martinez) <noreply@dev.gnupg.org>
escribió:

Allow me to clarify. For bounty purposes, as long as the intrinsic implementation matches or beats OpenSSL performance, it is acceptable. There have been cases where the use of certain intrinsics may yield better performing, but sub optimal results.

Sorry, I don't know which source code comment you are referring to. You mention the comment at https://dev.gnupg.org/T4628#128529 as well, but neither this commit nor be99eec2b105eb5f8e3759147ae351dcc40560ad contain such comment.

Please note that C-based intrinsic implementation is the way to go now as that is the path chosen for PowerPC implementations in libgcrypt.

As I already stated: Please read the source comments on why we do this

C-based intrinsic implementations are discouraged.

I'm confused by this commit: Third-party sigs were the ones used for flooding, and those are dropped with self-sigs-only. Is the additional clean operation still necessary for the mitigation? Wouldn't it be easier to just not set the import-clean flag in the first place for the default keyserver options?

In T4726#130609, @werner wrote:

-r  STRING

does a remote key lookup only if STRING is a valid addr-spec. No extraction of the addr-spec from STRING is done and thus angle brackets inhibit the use of a remote lookup.

does a remote key lookup only if STRING is a valid addr-spec. No extraction of the addr-spec from STRING is done and thus angle brackets inhibit the use of a remote lookup. This was implemented in this way to be as much as possible backward compatible.

DETAILS says:

*** PLAINTEXT_LENGTH <length>
    This indicates the length of the plaintext that is about to be
    written.  Note that if the plaintext packet has partial length
    encoding it is not possible to know the length ahead of time.  In
    that case, this status tag does not appear.