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/
