Re: Meaning of no-xxx option
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 >>
Re: Meaning of no-xxx option
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/
Re: Meaning of no-xxx option
Dear Kurt, The situation in 1.1.1 was a bit fuzzier than you say. E.g., openssl built with no-gost in fact permits loading an engine for use in X.509/CMS, but GOST TLS support becomes unavailable. On Sun, Oct 18, 2020 at 10:33 AM 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 > > -- SY, Dmitry Belyavsky
Meaning of no-xxx option
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
