This was release with 2.5.7.

Thanks, that was the only issue building there.

Please re-open if you find other Cygwin related build problems.

You know that Cygwin is not supported but if that is the only place it should not arm to fix it.

(2) Update the documentation of default-cache-ttl zero value disabling caching.

I am going to do:
(1) Recover old behavior with max-cache-ttl = 0
(2) Update the documentation of default-cache-ttl zero value disabling caching.

I can't see any documentation that a value of 0 disables the cache. The user might have used some undefined behaviour. For example in the old code we did a housecleaning when we were idle but the new code uses a timer and another thread for flushing the cache. We could open a feature request to entire disable the cache but I bet that we will get a lot of new bug reports because users will then need to enter their passphrase too often for one operation.

It's not my intention. I didn't know the feature of disabling caching by max-cache-ttl to 0.
Well, it's a regression if a user intends so.

Lucas Mülling commented yesterday on gnupg-devel:

Here we go:

Alright, my above putenv option won't work because it modifies the session environment and thus needs to be run for each gpg-agent session (connection). Adding a putenv_startrup option would help here but this way each connection could chnage the environment - also not good. In the end a way to modify the used environment variables, as you suggested, is a better way.

Yes, the workaround is to use a pinentry wrapper script that sets the value back to the correct one and then invokes the real pinentry.

Got a simple fix for this which does two things:

1. Correctly act upon an error from the backup file writing
2. Print a warning note.

In T2169#196673, @werner wrote:

Shall we handle this with additional retry prompts, w/o a timeout? I think this makes sense because creating keys with a backup file and a passphrase is a manual task anyway.

There is a regression due to the regression fix in rGb30c15bf7c5336c4abb1f9dcd974cd77ba6c61a7 (from Dec 24 2015) or some related commits:

Closed, since this was documentation for the workaround, four years ago.

Just a reminder: with Gnuk 1.2.15 and an ed25519 key PubkeyAuthentication unbound is required for hosts using the new feature.

Fixed in 2.5.0 and 2.4.6.

Fixed in 2.4.6.

This seems to have been resolved in 2.4.6 by T7151 or T7160. I don't really remember the details, but at least I don't see anything blocking system shutdown now.

Fixed in master: rGe7891225788a: gpg: Robust error handling for SCD READKEY.

Some would say it is a bug if keys are not shown - even if the algo is not known ;-)

scdaemon in this case was a broken experiment of mine (trying to see if I can get SoftHSM to work as the OpenPGP card). So this was not a normal, released scdaemon code.

Please send an excerpt from the scdaemon debug output to evaluate why you get somewhat strange looking data. Is this an experimental card? 0xa5 is a common test pattern.

It is reproducible bug even with master branch.

I have a look at the log file of gpg-agent.log. I can see that six PKDECRYPT requests are handled simultaneously. I think that it's out of secure memory to decrypt the private key which results pinentry request.

Found another thinko; When there is no clients with DEVINFO --watch, the pipe to be notified is not consumed at all (no read). It eventually results blocked by write(2), when the pipe is filled.

I see. the systemd race of having two gpg-agent processes. The second gpg-agent should eventually go away but than it is already too late.

I mean: two gpg-agent requests simultaneously running DEVINFO --watch.
Single scdaemon, two threads handling DEVINFO --watch simultaneously, by pselect + read.
Two threads waken up, but it was only one thread which can read(2), another was blocked (before the fix).

You mean it is possible that the initialization function is called by several threads - or that two scdaemon's are running before they realize that one of them is in the way?

Fixed in rGfc30f7059650: scd: Fix DEVINFO to allow multiple clients.

I realized that I put a bug on POSIX; When multiple clients do DEVINFO --watch, it is possible for scdaemon to hang (waiting pselect and read, read by one, read by another is blocked).

In T7283#190941, @gniibe wrote:

I can replicate the problem.

The cause of this is that when it's comes with loopback mode, gpg-agent inquires back to the frontend and the buffer overwritten, which results parsing the line wrong.
I'm going to fix.

In T7283#190901, @werner wrote:

y38k problems with some frontends are known for some 32 bit platforms.

Please write a proper bug report and don't expect us to read a reddit thread.

Fixed in rG01fa318be0f8: scd: Fix how scdaemon pipe server finishes.

Asking a change of gpgme would need more time... So, I decided to change gpg-agent side.
gpg-agent part was done in: rGb3f1f2cd192b: agent: Handle SCD DEVINFO --watch command in a special way.

scdaemon part was done in: rG36d8cffc6cd2: scd: Finish DEVINFO --watch command on input close.

Maybe we can support this directly in gpgme's assuan API.

Did some experiment and I concluded (for now) that new command for gpg-agent would not be needed.
Instead, it might be better doing following in GPGME.

I'd also be interested in expanding tilde expressions for dotfiles portability, since I don't use the same username in all my machines

What is the current status of this issue?

I had wrong interpretation about symmetric cipher algorithm identifier in the draft. It specifies symmetric cipher for the following Symmetrically Encrypted Data Packet (I was wrongly interpret as if it were specifying algo for AES keywrap).

I merged the change by Werner to get the value from frontend.

In the current code, just for testing against the test vector in m https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc-02, there are specific value in the key combiner KDF.
Namely, the value 105 for fixedInfo is defined in the draft (and it will be changed).

I created a pubkey (actually a subkey) for your above test keys:

I use this for testing:

On March 11 and 18, the private key file DE1AB1D22899CEC7DBB1A7863F34E6E92BFB7756.key was wrong.
I updated on March 25. Now, the endian is GnuPG (d is big endian).

Thanks, that patch works for me.

I extracted data from https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc-02 and compose x25519 key and MLKEM768 key. Here they are.
x25519 :

As a first experiment, let us use CIPHERTEXT in the format of (enc-val(ecdh(s%m)(e%m)(k%m))) (s: encrypted-session-key, e: ecc ephemeral key, k: kyber ephemeral key).

In 2.4 we have rG1383aa475 which does

Pushed the change in: rGf50c543326c2: agent: Allow simple KEYINFO command when restricted.

No, thank you both for the speedy responses :)

Thanks a lot for your quick testing.
The commit rGff42ed0d69bb: gpg: Enhance agent_probe_secret_key to return bigger value. of GnuPG 2.2 introduced this bug.