[PATCH 0/4] Differentiate use of non-compliant flags in the SLI

Lucas Mulling lucas.mulling at suse.com
Thu Mar 6 19:37:14 CET 2025


On Wed Mar 5, 2025 at 10:20 PM -03, NIIBE Yutaka wrote:
> The idea here is that:
>
>   * For existing FIPS conscious applications with libgcrypt, it assumes
>     old API of static indicator; That is, use of
>     GCRYCTL_FIPS_SERVICE_INDICATOR_CIPHER,
>     GCRYCTL_FIPS_SERVICE_INDICATOR_MAC,
>     GCRYCTL_FIPS_SERVICE_INDICATOR_MD,
>     GCRYCTL_FIPS_SERVICE_INDICATOR_KDF,
>     GCRYCTL_FIPS_SERVICE_INDICATOR_FUNCTION, and
>     GCRYCTL_FIPS_SERVICE_INDICATOR_PK_FLAGS.  It has the behaviors of
>     rejecting non-compliant use in some places in supported functions,
>     but not for other places.  It is OK with old API, non-supported
>     functions don't reject (like MD5 can be used).
>
>   * For new FIPS conscious applications, there are new API to check the
>     indicator.  We are now introducing new API for 1.12, and
>     forward-compatible implementation in 1.11.
>
>   * Existing tests in tests/ are basically with old API (except
>     t-fips-service-ind).  Update will be done in master for 1.12 after
>     1.11 branch will be created.

Agreed, this makes sense, thanks for the fixes!



More information about the Gcrypt-devel mailing list