The manual states that --standard-resolver is mostly for debugging. The reason you get an "not enabled" is that we can't allow direct DNS queries in Tor mode which would happen with the system (standard) DNS resolver.

In T4726#130765, @werner wrote:

Given that the the angle brackets are elsewhere used to indicate a search by mail address, it would be okay to allow for them in this case too (that is dkg's second example).
[...]
To answer your question: With the exception of case two this is desired behaviour also in the future,

Done for 2.2 and master.

Given that the the angle brackets are elsewhere used to indicate a search by mail address, it would be okay to allow for them in this case too (that is dkg's second example). The risk of a regression in that case is pretty low.

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.

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

@werner, you seem to be saying that -r does not imply "key lookups on remote services". Is that correct?

In T4726#130341, @werner wrote:

This is a misunderstanding. The extraction of mail addresses is only doe for key lookups on remote services. Thus the -r case is as intended.

This is a misunderstanding. The extraction of mail addresses is only doe for key lookups on remote services. Thus the -r case is as intended.

Is this task maybe related to T1927?

Thank you @dkg for creating the bug report! I would like to glean the following information from the above mentioned discussion.

GnuPG ships a non-PKI certificate, specifically to authenticate hkps.pool.sks-keyservers.net. Now due to an implementation detail, this has been shown to potentially lead to authentication of other domains by this certificate, if a maintainer changes the default keyserver via the DIRMNGR_DEFAULT_KEYSERVER variable in configure.ac. Now arguably, this variable isn't exposed via ./configure, so it's not "officially" configurable - but evidently maintainers do want to change it. A trivial one-line patch was supplied to change the unintended and potentially security-problematic behavior into the (I believe) obviously intended one.

yep, the implementation thinks that the default signing key is expired due to metadata contained in the public keyring. The secret key is available to the implementation. So the error mesage No secret key can cause confusion and/or panic if the user thinks they've actually lost their secret key.

You mean the default key is expired?

fwiw, i can reproduce this on debian unstable with gpg version 2.2.17, without a redirected agent -- so the agent redirection isn't relevant here.

Thanks for the sample certs. I noticed the posts but had not the time to look into them.

For information, I can’t reproduce here, either with GnuPG 2.2.17 / Pinentry 1.1.0 or with a fresh build from the tip of the master branches. Both pinentry-tty and pinentry-curses prompt for the password as expected, independently of whether the file to decrypt is specified as an argument or sent through standard input.

oops: That was an accidential priority change

Implemented master and 2.2. Note that the comment in the master commit about possible reason for stucked keylisting in gpgsm is only related to master.

I implemented it nearly as suggested. However, the default AKL is used, which is "local,wkd" (local is not used with that command though).

Fixed for 2.2.18. To allow seeing these warnings this change will only have an effect if a listing of all keys is requested.

Done for 2.2.18

This was already fixed with version 2.2.5.

Will be in 2.2.18

I changed the suggestion to read:

Note that rGd3f5d8544fdb needs to be backported to 2.2 but we will wait until we have better tested it.

@dkg, I changed the title and adjusted the description to more accurately describe the situation.

@skeeto can you edit the summary/title of this ticket to better reflect what you think the underlying issue is?

I think that I located the cause of this bug:

Those changes make the script work for me, specifically passing the input as an argument and not through standard input. Digging more, it looks like the underlying issue is related to using pinentry-tty (my case) or pinentry-curses when passing the OpenPGP input via standard input. This causes pinentry to give up before prompting. For pinentry-tty it fails with "ERR 83886340 Invalid IPC response" and pinentty-curses fails with "ERR 83918950 Inappropriate ioctl for device".

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?"

Backported.

Yes: at least 255 times.

IIUC, there is only a single recipient, but it has 256 SKESK packets, while only a single SKESK is valid and others are all dummy, right?

Patch is pushed to master. Will be backported to 2.2.

Sorry, perhaps, I misunderstood how SKESK packets are generated in your application.
I was considering there were 256 recipients.

If the use of GnuPG (current implementation) is a condition, I think that you could improve the generation of SKESK packets, so that no other passphrase can let gpg misunderstand as it may decrypt encrypted packet.

Unfortunately, for my use case the corresponding SKESK packet number is not known when calling GnuPG.

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.

The code has comments why we do a first clean_key on the imported keyblock.