If .fips will mean FIPS 140-3, why not the following patch?

diff --git a/cipher/sha1.c b/cipher/sha1.c
index 3bb24c7e..cb50ef66 100644
--- a/cipher/sha1.c
+++ b/cipher/sha1.c
@@ -759,7 +759,7 @@ static gcry_md_oid_spec_t oid_spec_sha1[] =
 
 gcry_md_spec_t _gcry_digest_spec_sha1 =
   {
-    GCRY_MD_SHA1, {0, 1},
+    GCRY_MD_SHA1, {0, 0},
     "SHA1", asn, DIM (asn), oid_spec_sha1, 20,
     sha1_init, _gcry_md_block_write, sha1_final, sha1_read, NULL,
     _gcry_sha1_hash_buffers,

Ah, I realized that hashing itself is allowed in FIPS 140-3, when it's not for signature scheme.

The current code is inconsistent about its behavior: how non-approved digest algos are supported or not when FIPS enabled.

Specifically,
(1) Should gcry_md_hash_buffer work for non-approved digest algo?

• CURRENT: implementation dependent (when ->hash_buffer is implemented it works, otherwise abort.

(2) Should gcry_md_hash_buffers (note s) raise an error for non-approved digest algo?

• CURRENT: implementation dependent (when ->hash_buffer is implemented it doesn't raise an error, but computes

For a programmer like me, it is easier if the behavior will be:

(1) gcry_md_hash_buffer work well with SHA-1 but not with other non-approved digest algo.
(2) gcry_md_hash_buffers work well with SHA-1 but not with other non-approved digest algo.
(3) gcry_md_open work well with SHA-1 but not with other non-approved digest algo.
(3-1) Even so, internally, it rejects use of SHA-1, when gcry_pk_hash_sign or gcry_pk_hash_verify is called.

This allows a programmer to use SHA-1 hashing through hashing API but not for signature generation API, when FIPS enabled.

And the difference between gcry_md_hash_buffer and gcry_md_hash_buffers is not for FIPS enabled approved/non-approved things, but how an error is raised (abort or by error code).

(3-1) is implemented: rCa23cf78102f3: cipher: Reject SHA-1 for hash+sign/verify when FIPS enabled.

Thank you for having a look into that. The change looks fine, but I need to get some clarification about what "Legacy use" means for "Digital signature verification" in the Table 8 of https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf

Perhaps, as a library (considering the benefit of users), it would be better to allow signature verification with SHA-1, to defer the decision to application.

But I don't know if it is OK for a certified library.

At this moment, we agreed on keeping the current behavior and not allowing the SHA1 for verification either. But we might need to revisit that in the future if this will cause issues. Or we might go the way of switching the service to non-fips if needed, rather than creating some more middle ground.

Check for FIPS has been added. (1) and (2) were solved.