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.

BTW, since I start my X session with startx, these 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.

Sorry, we can't replicate this with the current pinentry version.

I always select both files and click to verify, I thought that was the way
it was supposed to be done, that I should provide the file and the
signature to the program.

Just downloaded the file and signature and there is only one signature. Just verifying the signature also does not result in duplicated results.

"PLAINTEXT 75 ..." means UTF-8 encoding (u) which is not not binary (b) or MIME ('m') and thus on Unix the line endings are converted from CR,LF to LF. On Windows you should see a different length. See plaintext.c#handle_plaintext()