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.

I see the reason.

FWIW: These days a thread on Linux is not that costly but nevertheless takes up resources. On other Unices (and WindowsCE) threads have quite some overhead and that was the reason I implemented it the way it was.

works, VS-Desktop-3.1.90.287-Beta

So the actual killing is now done with c5617e9f2426549cba54cb52f9faf9325f8e2929 we are using custom actions instead of CloseApplication to have more fine grained control when the steps are run. CloseApplication would only run in the main install sequence so basically only the Deferred part, but during an interactive upgrade like what one of our Entry users would do it would not avoid the first failure to kill a running gpg-agent this already would break the RestartManager support.

FWIW, the Fileversion is actually the Git revision in decimal

b) Is explained by the following documentation from: https://wixtoolset.org/docs/v3/howtos/updates/major_upgrade/

a) So with my current test upgrading from one beta to another it actually looks in the manifest and if you look there the beta230 of gnupg:

So with verbose logging /l*v inst.log (note the v) I finally saw the issue. My killing code works just fine.

Ok closeapplication will not work because:

Note to self.

So some research led me to believe that using taskkill from MSI is not uncommon. But most stackoverflow solutions did not work for me. I have one solution that works, though but that opens a terminal window for each process we try to kill. I don't want to use wscript to avoid that, since an installer that executes visual basic is IMO even more evil then an installer that executes taskkill. Both are not really the MSI way, but while we could fix our processes without a WindowMessage loop to die nicely this will not work for an upgrade to vsd32.

So I tested upgrading from 3.1.26.0 to the current beta and it also did not work.

Push the code by rG95186ae92f92: agent: Use a thread to monitor socket takeover.

FWIW: I have not done any tests but the comment below is about the case I suspected to be the cuase for your problem:

If it were the case, I think that graceful shutdown of the system would need to terminate the client of scdaemon at first.

The root cause might be that the "DEVINFO --watch" command causes ...

I also experienced hang on shutdown with GPG 2.4.1 and bisecting reveals that the first bad commit is rG2ccbcfec121f.

isn't T3456 the same issue?

FYI: Quite some more days than a few passed by. I still did not found the time for this, sorry.

I never made a threat model. But definitely *any* cracker, should be out of my system, either from governmental agencies or from a kiddo in Russia.
I know that I have someone that is remote accessing my machine, since I got some tells. And that this cracker have used my Emacs text editor.

Smartcard PINs are different from passphrase for on-disk keys. Once a PIN is entered the smartcard is unlocked as long as it is powered up. In theory we could power down and power up the card to lock it. The question here is what is your threat model? If you have malware on your system it could simply brick your token or, more common, peek at your PIN.

Thanks. please give a few days.

created ~/.gnupg/gpg-agent.conf containing:

debug ipc,cache
debug-pinentry
log-file socket://

Okay, I see. The commands above are a real reproducer and not standalone examples. Then yes, you should get a pinentry only for the first gpg -d (as long as the keys are still in the cache). I am lacking macOS/homebrew stuff to replicate this. What you can do is to put

I may be reading your comment wrong, but the problem here is not multiple pinentry prompts, or multiple gpg-agents present.

Although gpg-agent launching is protected by a file system lock, there is indeed a small race related to the pinentry. The invocation of the pinentries is serialized but if a second pinentry is requested while the first pinentry has not yet returned and put the passphrase into the cache, the second pinentry will be called anyway. Fixing this not easy and should rarely be a problem. The mitigation is to do a dummy decryption to seed the cache or use a custom pinentry.

Thanks all. It is a bug in Win32 OpenSSH. https://github.com/PowerShell/Win32-OpenSSH/issues/1953 it is already fixed. I think the issue will be resolved after the update is shipped. I could use ssh -T git@github.com as a workaround.

Well, not our bug... it's a kind of support question and answer:
This might help: https://stackoverflow.com/questions/3844393/what-to-do-about-pty-allocation-request-failed-on-channel-0

This does not look like a problem in GnuPG/gpg4win because gnupg implements the ssh-agent protocol and not the ssh server or client functionality. ssh tells sshd whether it shall allocate a PTY (Pseudo TTY). I don't use ssh with github but it is likely that you may only run commands (which don't require a PTY). Usually you would invoke a "git" command cia ssh.

Authentication succeed if I pressed enter after:PTY allocation request failed on channel 0

I try WinGPG 4.1.0, and I receive an error:
ssh git@github.com
PTY allocation request failed on channel 0