Clemens Lang

You're right that they won't be compliant – however, the fallout is a bit unexpected, e.g., ssh no longer works. I think breaking those functions leads to bad user experience,...

I finally found the time to update this. > Issue was raised about how this will work in the FIPS provider. The FIPS provider has its own libctx, does not...

@paulidale @slontis @mattcaswell @beldmit Bump, I'd appreciate a new review.

macOS doesn't have symbol versioning, so you should just skip the alias for macOS, iOS, and other Apple platforms: ``` diff --git a/crypto/evp/digest.c b/crypto/evp/digest.c index e091e33fcf..81a791ebac 100644 --- a/crypto/evp/digest.c +++...

> What about just using OPENSSL_SYS_LINUX? That sounds like the best solution, unless we are aware of other platforms that support symbol versioning? @sahanaprasad07 Can you make that change?

I'm not sure how to solve the failure with the old provider. The issue here is that the provider computes the salt length independently from the routines that write the...

> IMO the solution would be to use RSA_PSS_SALTLEN_DIGEST as the default or to invent another default value. That will not work, because for some combinations of key length and...

> That something could be a sentence in the security policy. We're being told this is no longer enough. We can't wiggle our way out of this in the security...

I've changed this to introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and switch the CMS routines to determine the salt length from the provider's implementation. This preserves compatibility with older providers, while...

> I think this will still break the Provider versions compat CI that is run on push as the libcrypto from 3.0.7 won't be able to cope with the changed...