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

https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf

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

For Ed448, tests/t-ed448.inp is duplicate.

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

For the latter, I created an experimental patch:

EdDSA has two modes (normal and hashed). Normal mode doesn't hash messages, so, we need to specify input data. To do so, I added CONTEXT_TYPE_INPUT_DATA. Another approach would be having "non-hash" algo for gcry_md_open.

Another approach would be having "non-hash" algo for gcry_md_open.

I think this option would be too easy to misuse in other contexts so I would prefer having the specific CONTEXT_TYPE_INPUT_DATA for EdDSA. The proposed patch looks reasonable to me and no obvious issues noticed on fast review.

I changed the lg-input-data.diff patch not to break the ABI, reusing the published symbol of gcry_pk_random_override_new.
With this approach, if/when needed, backporting may be easier.
Drawback is debugging internal of libgcrypt will be a bit confusing.

I found that for EdDSA other than pure Ed25519, it can supply context.
I changed the semantics and API for adding context and input data, as we need to support both simultaneously.

Can we close this?

I think so. We did not submit a modules for recertification with these changes, but we do not plan this in close future so you can consider it completed.