I confirmed that the patch above works with newer Gnuk (>= 1.2.16).

Passing fds etc adds complex extra code to gpg-agent. This was not the original design goal, although we violated this anyway by have some OpenPGP specific code there. This needs more thinking. Due to our internal use of OCB we can't make it FIPS compliant without large changes.

I have not yet tested OpenSSH 9 and thus the patch to master is here just as a test. Please better use gnupg 2.3 (stable) instead of 2.2 (LTS) because it is unlikely that we will backport all this new ssh stuff.

Patches applied and pushed. For the common/t-ssh-utils, I applied my fix for the use case with key on command line when FIPS mode is enabled (MD5 error is OK, in this case).

For anyone stumbling across this issue I created a docker image containing gpg with the patch above applied: https://github.com/smlx/gnupg-piv-agent

The patch I proposed was partial one, not fully solved the problem of socket resource leak on Windows.

Confirmed to work, thanks!

Thank you. Applied.

Implemented.

it still shows the no certificate or invalid encoded error message:

I gave it a try. It works now, but it still shows the no certificate or invalid encoded error message:

Thank you. Confirmed.

Thank you for the reproducible test case. Confirmed.

Thank you.

I guess I don't understand what you mean by "native building". This build was with MinGW, which is as "native" as MinGW64 is.
The reason for the problem is (AFAIU) that MinGW64 went after Microsoft's change in stat due to the 32-bit vs 64-bit time and off_t values issue.s That change breaks backward compatibility in more than one way: programs compiled on some versions of Windows will not run on other versions. mingw.org's MinGW kept the original semantics and symbols, which is why _stat32 exists in the mingw.org's headers, but is not exposed by default.

Turned into a feature request because native building on Windows is not supported.

Now, the problem is not about the case of pid == getpid () any more.

That would be bad for unattended use cases. Recording the time the lock file was created might be a solution. Then cleanup only after 15 minutes or so.

Note that there is a race condition still (after a fix of one race condition which may be somewhat likely and reproducible, and another fix of race condition when there is a stale lockfile).

Fixed another race in commit: rG2f1afc129662: common: Fix another race condition, and address the other one.

{F3381469}I uploaded the whole homedir containing the keys after they were migrated by the new gnupg2.3.4. It should have all of the keys in there. Don't worry, these keys are just for testing and not used anywhere.

Before the fix above, https://bugs.debian.org/972525 can be explained by the following scenario:

Fixed in master. Should be backported when found stable.

I pushed a change for t-dotlock.c for testing.

I can't replicate this symptom (gpg1 generated key, no problem after migration).
Could you share the *.key file under private-keys-v1.d?

Reagarding the OpenPGP specs: there is a new draft with LOTS of changes to already agreed upon formats and conducted interop tests. Almost everything we implemented in GnuPG and RNP has had rough consensus in the WG. Minor things like AEAD chunk size were the contested pieces. However, now they want to change everything with the possible outcome of discretization the long established trust in the stability and durability of the PGP data and key format.

Sorry. While v5 things in the specification is still in flux, from the viewpoint of the implementation, this patch is 100% valid and it makes sense.

Thank you for the report.

What about at least accepting env variables OR tilde expansions? That will make it easier to integrate with dotfiles that intentionally use a home-dir based executable without having to pass the full path, so it could work cross platforms.

No problem. Both patches look good.

Does these patches look ok? @gniibe @werner

Thanks. All my tests work now.

Cool. I did some quick tests with 2.2 on my pretty old X220 and it really makes sense to apply the patch there as well.:

It was the bug of generating AEAD packet, which does:

Sorry for pushing immature fix. I located the cause, but I didn't have enough concentration for fix.

Just more background what I'm doing with these tests. I started testing with set of different sized test files (generated from urandom) to detect any bugs in my changes, which try to reduce amount of memory copies in iobuf_read/iobuf_write. Size ranges for these test-files are 0...17408, 32256...66560 and 130560...132096 bytes. These files are encrypted with different settings (public key/symmetric/cfb/ocb/different algos) and then decrypted and decrypted file compared to original.

I tested the fix. It appears to break OCB encrypting files shorter than 65515 bytes:

$ gpg --batch --symmetric --passphrase=bug --output=enc_065514.gpg --rfc4880bis --force-aead --cipher-algo AES128 --compress-algo none plain_065514
$ ls -laF *065514*
-rw-rw-r-- 1 jussi jussi   100 Feb  22 18:51 enc_065514.gpg
-rw-rw-r-- 1 jussi jussi 65514 Feb  22 18:42 plain_065514
$ sha256sum plain_065514
5711955703f4d96f510ad5a660c3ccd0d01f0b2dd2561ba6586159ad941cbcde  plain_065514
$ gpg --batch --decrypt --passphrase=bug --output=- enc_065514.gpg | sha256sum
gpg: AES.OCB encrypted session key
gpg: encrypted with 1 passphrase
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  -

In T5837#155062, @werner wrote:

Setting the management key has been implemented only for Yubikeys. So for Gemalto this won't work.

It would be awesome if you could implement this \o/

Let's try this for 2.3

Saw this again and the commit was not in the Stable 2.2 branch. I have cherry picked it. This should resolve this issue.

Backported to 2.2, too.

No, these are simply the technically available algorithms. I'll see what I can do.

Thanks for diving into the history of that code.

Here is the backport to 2.2:

In the original code, register_trusted_keyid is used in keygen.c, so that it updates user_utk_list, thus, will be into utk_list.
This should be done, by adding the keyid to utk_list directly.