Before adding FIPS support flag and tests, we need to modify implementation:

• Adding PCT check for EdDSA
• Adding support of gcry_pk_hash_sign/verify API for EdDSA

Thanks. I think that it was the oldest one: FSF used to be there in Cambridge, then moved to Tremont St. in Boston, and now it's in Franklin St.

FYI, while going through the licenses again I noticed one of the pinentry files have even older address that so if you would do sed, this would not be matched:

In T6336#166815, @werner wrote:

Actually, the entire systemd based launching is deprecated and thus the logged warning is on purpose.

The problem with the systemd launched gpg-agent is that it creates a race: gpg launches gpg-agent as needed and to avoid concurrent launching by other gpg or gpgsm processes, it takes a file system lock during the launch process. systemd does not know about this and we end up with sometimes end up with two gpg-agent processes. Eventually one of those processes detects that it does not own the socket and terminates itself. No real harm here but you may see smart card lockups or a flushed password cache.

I consider the entire idea of receiving a passphrase and data on the same channel to be a bad for security and robust coding. The whole thing is a historical oddity which we kept for the sake of mutt(1)'s legacy way of invoking pgp. Thus I won't consider 3) the best option.

To summarize, here is the situation:

• Ideally, it would be good to modify GnuPG and Emacs EasyPG to implement status handling and input handling in better way.

Ah, I see https://dev.gnupg.org/rG2f872fa68c6576724b9dabee9fb0844266f55d0d applies cleanly. I guess can go with that, although would prefer it if on the 2.4 branch.

Is there a commit we could backport downstream to 2.4.x? We've had quite a few reports of this.

I'm going to add selftest of EdDSA with test vectors from RFC 8032.

With the fix of T6523, make check goes all well (on Wine emulation and on Windows, for i686 and for x86_64).

Fixed in master.

I modified ffi.c, to have renamed process-spawn-io function doing I/O by C.

Calling assuan_release before kbx_client_data_release is the best (and we join the thread).

works

Works in kleopatra; tested with gpg4win-4.2.0-beta339.

tests/openpgp/import.scm hangs with 4096*4.

Test with Wine (i686) emulation, I encountered another hang at: Checking armored_key_8192

It looks like having the datastream_thread may be not worth.
One possibility is to implement synchronous read from pipe in kbx_client_data_wait, instead of datastream_thread.

When testing please note that the last changes (i.e. "Ignore expired subkeys when looking for newest subkey" and ""Sort by fingerprint as last resort for deterministic sort order") have not been merged to the gpg4win/3.1.27 branch.

They re-used the same file name for the update from March and no history section. Anyway that looks promising and may solve the problem of having different algorithms allowed for restricted communication in the EU and the US.

Correct, but the last revision of FIPS 140-3 lists the EdDSA already. The same for the IG for FIPS 140-3:

My understanding is that FIPS 186-x lists more algorithms than approved for FIPS 140-y; the approved algorithms for 140-y are in the latest revisions of SP800-140. I have not checked the latter document, though.

See also commit rG6fcc263c18 from 2020 where I switched to D-lines.

The problem of hang of tests/openpgp/multisig.scm is solved by rGef4f22b9d98b: gpg: Graceful exit for signature checking with --batch.
But the problem itself is not yet solved.

It is reproducible by testing tests/openpgp/multisig.scm with keyboxd enabled (it hangs), with the modification of following.

And thanks gniibe! I have tested 2.4.1 several times in this month (including existing and new keys), the warning was never shown again.

Hi zhangguangzhi, I think that it's version-specific problem.
I traced the chain and this warning message was added in release 2.3.3 T5565.
The problem should be able to reproduce between 2.3.3 and 2.4.0.

Hi，i try to reproduce the problem, my platform is linux and gnupg2-2.2.32-3, but i can't find “gpg: warning: lower 3 bits of the secret key are not cleared". Excuse me, is this a platform-specific or version-specific problem, or is it my operation wrong.

Due to back porting another change the fix for 2.2 is now also needed in 2.4.

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

The fix actually does the same as my suggested workaround.

There is an easy workaround: Append an exclamation mark to the adsk key. This way gpg will only search for this subkey.
An example with my test keys:

For the record, we've removed the SRV record for keys.gentoo.org for now, to work around the problem. Without the SRV record, everything works as expected.

I pushed the change which keeps old status report behavior to master.
Let me test the change.

looks simpler to me.

Should be fixed now; see commit above.

FWIW: WriteFile and write are more different than in using a HANDLE vs. a libc file descriptor. Despite that a HANDLE might be a 64 bit pointer, it is guaranteed that the value fits into a 32 bit variable. But they still index different objects. The return code and error values are also different.

Much simpler: write is only used in the callbacks and over there gpgme_io_writen[n] shall be used anyway.

Hmm, for the latter this:

Orthogonally, here is possible change for GnuPG, if we need to support the workaround of compress-level 0 in ~/.gnupg/gpg.conf.

Kleopatra test case (similar to gpg):

OK, here is my changes which always use make-temp-file (to avoid confusion between data input and passphrase input).

I use epg.el with the change of removing the wait:

it's not hard to fix that header to actually provide a sensible write(), avoiding the issue listed on the mailing list, where there was no return to check:

Seems it gets a record but is not able to parse it (gnupg/dirmngr/dns-stuff.c:getsrv-standard) in your setup. Not sure why it loops - need to debug it.

Ok, it seems that my reproducer isn't correct after all. The user just confirmed that the SRV lookup succeeds on their system, so it seems GPG hits some loop repeating that for no apparent reason.

On the command line it works. It seem's to be a problem of Kleopatra.

Can you try on the command line, errors might be more specific there. This can be caused for example by a wrong system clock.

Fixed in 2.4

closing, as setting a password on a key without password works (at least in current gpg4win version). For improvement of the user guidance see T6436.

--openpgp means the current OpenPGP standard as implemented by GnuPG. This was important in the first few years of OpenPGP but not anymore today. The option --rfc4880 might be what you want. Please keep also in mind that the preference list declares what a concrete implementation supports and not necessary what's in an RFC.

works

Thank you, your suggestion inspired me to experiment a bit further and I found the problem - I needed in fact to delete the line from my ssh config, no idea why:

Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"

Now I update startup tty only on terminal start and it seems to be working. Still a bit strange.

This is a standard C pattern to declare that one is not interested in the return value. In this case a return value won't help us because we can't log that anyway because we are in a signal handler.

On a terminal, please invoke:
$ gpg-connect-agent UPDATESTARTUPTTY /bye

You are right, it is a bad habit not to check this. Thanks for your patch.

it would break the verification of too many signatures.

backported to 2.2

works, no KIO error. Gpg4win-4.1.1-beta317

@werner We could make the wait conditional on (equal epg-gpg-program "gpg"), that is, only when user has GnuPG 1.x.

Well okay, then I have no workaround. However, I won't consider this a bug because BEGIN_ENCRYPTION marks the start of the actual encryption process but not when it starts to read input data.

The change rG60963d98cfd8: gpg: Detect already compressed data also when using a pipe. for T6332 introduce IOBUF_IOCTL_PEEK.

@werner I tested by switch back to GnuPG 2.4.1 (I downgraded to 2.4.0 before to temporary work around issue), adding compress-level 0 to gpg.conf file. It's not working. The problem still exist.