> >distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be
> more fitting than FIPS_MODE?
>
>
> Or perhaps OPENSSL_BUILDING_FIPS, since a couple of PR's already have and use
> OPENSSL_BUILDING_OPENSSL ...
OPENSSL_BUILDING_OPENSSL is really a remarkably long name. I
>distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be
more fitting than FIPS_MODE?
Or perhaps OPENSSL_BUILDING_FIPS, since a couple of PR's already have and use
OPENSSL_BUILDING_OPENSSL ...
There's no reason to use OSSL for internal macros.
I can only add +1 to what Matthias suggests. Although I know the
meaning of the FIPS_MODE define, for a newcomer it is obviously not
clear what the define really means.
Tomas
On Tue, 2020-01-21 at 13:31 +0100, Matthias St. Pierre wrote:
> On 21.01.20 10:36, Richard Levitte wrote:
> > I think
BTW: the following build time constant with the remarkably long name seems to
be intended for
a related purpose, but it is currently completely unused?
Configurations/00-base-templates.conf: lib_defines => [
'OPENSSL_BUILDING_OPENSSL' ],
On 21.01.20 10:36, Richard Levitte wrote:
I think that the misunderstanding lies in when FIPS_MODE is defined.
Reading this sentence it occurred to me that the misunderstanding comes from
the fact that the define is indeed misnamed. The term "FIPS mode" is a relict
from FIPS 2.0, where the
This doesn't affect applications. Our FIPS module holds its own
keys, but reuse the same structures as libcrypto to hold them
internally, and *there*, the EX_DATA field is irrelevant.
Applications will never get that far in. The EX_DATA added by the
application is still valid.
I think that the
Hello,
Recently I note that when build is in FIPS_MODE some functionality is
lost. For instance RSA_{g|s}et_ex_data is not available.
Reading the code I expect that in FIPS mode use of external keys is
forbidden.
Remark: ex_data is used to store reference information for external keys.
