I'm afraid your interpretation isn't quite correct.  The no-xxx
options remove the actual code for the thing being disabled, but it
doesn't turn off access to a compatible implementation.  For example,
you could conceptually have an ENGINE with an alternative DSA
implementation that's perfectly usable through the EVP interface
(keys will have to be loaded through that same engine, though),
regardless of any no-dsa configuration.

This is also reflect in the apps.  Yes, the key type specific commands
like 'openssl dsa' are disabled, but that's because in 1.1.1, they use
the lower level APIs and can simply not build at all if the calls they
depend on aren't there.  However, if you look at apps/*pkey*.c, you
will find very few uses of OPENSSL_NO_ macros.  1.1.1 only guards
engine calls with OPENSSL_NO_ENGINE...  master has some OPENSSL_NO_EC
guards, for reasons I'm currently unaware of, I assume some kind of
special case that should really be removed.

So I guess this comes down to what's currently being done, where
commands like 'openssl dsa' starts to use EVP functionality, and
thereby become *more* available than before.  If that's good or bad,
only time will tell...

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.

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
> 
-- 
Richard Levitte         levi...@openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

Reply via email to