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()

Thanks for the report. I'm only giving it low priority because while it is ugly it is no loss of functionality.

Without --expert my proposal for full-gen-key would be:

That is due to the mitigation for CVE-2019-14855. I need to see how to find a more specific mitigation.

Thanks for the report. I fixed this for the next 2.2 release and put a not in the source file to not translate the keyword.

Thanks.

Maybe it is the same issue described in https://dev.gnupg.org/T4717 ?

Changed to Issue Tracker with 1d89f93b037d0f7cd084dbc7873f73134a8e1f1a.
@olf thanks for the hint.

No. I mean to have an option for the caller to provide apparent UID in context to the --verify option, and have that influence the result. This is important for automated software that can't rely on user rechecking the result.

So you mean we should take the signer's UID (which can be part of the signature) into account when displaying the user id? Right now we display the primary UID followed by _all_ other user IDs so that the verifier has an overview of the associated user ids.

I don't think that pointing to the bug entry form is a good idea: It will make it easier to enter a bug without first checking whether this bug has already been entered. I agree with the other comments.

Please revert the change (DE & EN) "Bug Tracker" to "Tracker" back to "Bug Tracker" or (a bit less specific) "Issue Tracker" :

• This statement does not make much sense when omitting what is actually tracked.
• People are looking for a link to a "bug tracker" / "issue tracker" when intending to report a bug.