OpenSSL legacy API cleanups #4608
Conversation
OpenSSL version 1.1 has broken its API in quite a few ways. To avoid having to use ifdef's everywhere, we have implemented the BIO functions added in version 1.1 ourselves in case we are using the legacy API. We were implementing them in the header file, though, which doesn't make a lot of sense, since these functions are only ever being used the the openssl stream implementation. Move these functions to the implementation file and mark them static.
By now, we have several locations where we are checking the version of OpenSSL to determine whether we can use the new "modern" API or need to use the pre-1.1 legacy API. As we have multiple implementations of OpenSSL with the rather recent libressl implementation, these checks need to honor versions of both implementations, which is rather tedious. Instead, we can just check once for the correct versions and define `OPENSSL_LEGACY_API` in case we cannot use the modern API.
In order to further avoid using ifdef's in our code flow, provide the function `OPENSSL_init_ssl` in case we are using the legacy OpenSSL API.
14481fa to
dd9de88
Compare
|
/cc @Sp1l Would be cool if you could have a stab at this PR to check I'm not breaking libressl again. I've verified with libressl 2.6.3, but didn't check with 2.7 this time. |
|
Which brings me to something different: it would be cool to have different CI jobs for OpenSSL 1.0, OpenSSL 1.1 and libressl 2.6 or 2.7. |
Maybe, but our CI is already slow. I would also like to see us have an improved test matrix, but we need to think seriously about both the continuing degradation in speed for pull requests. I suggest we start thinking about splitting out the platform matrix into the highest priority platforms that will give us a high confidence in the PR (probably a single Linux, Windows and macOS installation) and then do nightlies for the entire set of systems that we want to test. |
|
Yeah. I feel like GitLab CI would be a lot faster than Travis -- all builds I had were run completely in parallel, so additional jobs didn't really impact us. It does have a shortcoming, though: there are no "real" 32 bit containers available, as nearly all Docker images are 64 bit only. One thought that occurred to me was to thus use both CI systems:
Edit: GitLab should also include a recent Ubuntu, like 17.10, as Travis does not support anything different than Ubuntu 14.04 |
|
I like the cleanup ! I have one related dangling commit, which might be integrated in this (already on top of this branch 😉). |
This is the "OpenSSL available" global init function after all
|
Thanks @tiennou, amended your commit to this PR |
Some follow-ups for #4607.