On 18/10/2020 11:19, Richard Levitte wrote:
> In summary, the time where no-xxx truly meant that the algorithm xxx
> is completely unavailable is long gone.  The addition of ENGINEs
> changed that...  not immediately, but as soon as the ENGINE API got
> functionality to help implement EVP_PKEY_METHODs and
> EVP_PKEY_ASN1_METHODs.

Right. This is my opinion too.

Historically no-dh (for example) meant that the low level implementation
of "dh" was not compiled. Unfortunately the lack of the low level APIs
was "viral" in the sense that it meant removal of all functions that
used those APIs (because we had too - otherwise it wouldn't build). Due
to the wholesale replacement of the low level APIs with high level ones
we no longer need to do this. The low level API implementations are no
longer there, but the functionality that was previously removed can
remain. The "viral" nature of the removal has gone.

To me this makes sense. We are moving to a model where the control of
what algorithms are available depends on what providers are loaded. If
you don't want support for DH, then don't load any providers that
support it. The "no-dh" option restricts itself to controlling how the
providers are built - but doesn't have impacts beyond that (except I
suppose in the tests).

Matt



> 
> Cheers,
> Richard
> 
> On Sun, 18 Oct 2020 09:33:11 +0200,
> Kurt Roeckx wrote:
>>
>> Hi,
>>
>> It seems that we might start to interprete the no-xxx options
>> differently. In 1.1.1 it would completly disable the feature in
>> libcrypto, the apps and libssl. It seems that now the
>> interpretation changed to just disable the support for it in the
>> provider. You might load a different provider that does support
>> it, and so the apps and libssl can use it then.
>>
>> My interpretation was always that we want to completly disable the
>> feature, for instance because we don't want to use it at all or we
>> want to reduce the size of the binries.
>>
>>
>> Kurt
>>

Reply via email to