Move the loading of the ssl_conf module to libcrypto (1.1.0) #5879
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The GOST engine needs to be loaded before we initialise libssl. Otherwise the GOST ciphersuites are not enabled. However the SSL conf module must be loaded before we initialise libcrypto. Otherwise we will fail to read the SSL config from a config file properly. Another problem is that an application may make use of both libcrypto and libssl. If it performs libcrypto stuff first and OPENSSL_init_crypto() is called and loads a config file it will fail if that config file has any libssl stuff in it. This commit separates out the loading of the SSL conf module from the interpretation of its contents. The loading piece doesn't know anything about SSL so this can be moved to libcrypto. The interpretation of what it means remains in libssl. This means we can load the SSL conf data before libssl is there and interpret it when it later becomes available. Fixes openssl#5809
levitte
approved these changes
Apr 5, 2018
levitte
pushed a commit
that referenced
this pull request
Apr 5, 2018
The GOST engine needs to be loaded before we initialise libssl. Otherwise the GOST ciphersuites are not enabled. However the SSL conf module must be loaded before we initialise libcrypto. Otherwise we will fail to read the SSL config from a config file properly. Another problem is that an application may make use of both libcrypto and libssl. If it performs libcrypto stuff first and OPENSSL_init_crypto() is called and loads a config file it will fail if that config file has any libssl stuff in it. This commit separates out the loading of the SSL conf module from the interpretation of its contents. The loading piece doesn't know anything about SSL so this can be moved to libcrypto. The interpretation of what it means remains in libssl. This means we can load the SSL conf data before libssl is there and interpret it when it later becomes available. Fixes #5809 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #5879)
|
Pushed. Thanks. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the 1.1.0 version of #5818. The key difference is that we do not automatically load the config file during libssl initialisation. Instead we just ensure the builtin conf modules are loaded.
This change should be internal only and not visible to an application with the exception that some error codes will change.
The GOST engine needs to be loaded before we initialise libssl. Otherwise
the GOST ciphersuites are not enabled. However the SSL conf module must
be loaded before we initialise libcrypto. Otherwise we will fail to read
the SSL config from a config file properly.
Another problem is that an application may make use of both libcrypto and
libssl. If it performs libcrypto stuff first and OPENSSL_init_crypto()
is called and loads a config file it will fail if that config file has
any libssl stuff in it.
This commit separates out the loading of the SSL conf module from the
interpretation of its contents. The loading piece doesn't know anything
about SSL so this can be moved to libcrypto. The interpretation of what it
means remains in libssl. This means we can load the SSL conf data before
libssl is there and interpret it when it later becomes available.
Fixes #5809