3 ms·

There's so much software written against openssl 1.1.1, when you upgrade to version 3.x it's a horror show of deprecations (though things seem to mostly work)..

by brabel 3y ago

There's so much software written against openssl 1.1.1, when you upgrade to version 3.x it's a horror show of deprecations (though things seem to mostly work)... they removed some FIPS functions which broke some code I've tried to compile and I haven't been able to find a solution that works properly without actually changing the source code. Does anyone know about this and what's the appropriate thing to do in such cases where you have thousands of lines of code you have no interest in upgrading, but which no longer compiles on openssl 3?

ori_b 3y ago
Try libressl (https://github.com/libressl/portable https://github.com/libressl/portable)
StewardMcOy 3y ago
I went through this last year, the last time the OpenSSL project issued a warning about the EOL, and got about halfway done before giving up and just using #pragma GCC diagnostic ignored "-Wdeprecated-declarations" when calling deprecated OpenSSL functions. The deprecated functions do still work, and with OpenSSL 3 being a LTS release until 2026, I'm hoping they'll continue to work until at least that date. Of course, this pushes the problem down the road, but here's why I think this is the best approach if you're unable to move to one of the forks. The OpenSSL 3 API is vastly different from the 1.0 or 1.1 APIs, and are currently poorly-documented. There's a migration guide, but but as lengthy as it is, I found it only minimally helpful in understanding how to transition from the 1.1 API to the 3.0 API. In short, a lot of structs and their associated functions have been deprecated in favor of using the more generic EVP_PKEY and its associated OSSL_PARAMS. OSSL_PARAMS is a struct that contains a sting key and a pointer value, and you get/set arrays of these params on keys. So instead of having C functions which clearly specify what their required parameters are, what they return, and the types of all these things, you get a few comments in the OpenSSL headers telling you which types go with which keys. The compiler won't warn you if you assign an integer value to a key that expects an octet string, for example. The rest of the documentation isn't much better. Some man pages are great, but most still leave it up to you to piece things together. Worse, there are quite a few use cases which are made more difficult and verbose by the new API. Browsing the github issues and the mailing list, there are quite a few scenarios that the OpenSSL team has said could be made easier in the future, but were somewhat of a blind spot during the initial design of the new API. Perhaps because of this, few major open source projects have moved to the new API, even with the EOL deadline so close. This, in turn, makes it difficult to find real-world uses of the new API to help learn how it should be used. However, the API is slowly getting better. In 3.1, OpenSSL added some functions to make building OSSL_PARAM arrays easier. By 2026, they may have improved the documentation, filled in the missing use cases in the API, and there may be more real-world examples to learn from. All of this would make moving to the new API much easier.
rlpb 3y ago
> it's a horror show of deprecations I'm not familiar with the 3.x API, but in the past merely using the OpenSSL API was a horror show. Surely deprecations are the only way out?

by brabel 3y ago

ori_b 3y ago

Try libressl (https://github.com/libressl/portable https://github.com/libressl/portable)

StewardMcOy 3y ago

I went through this last year, the last time the OpenSSL project issued a warning about the EOL, and got about halfway done before giving up and just using #pragma GCC diagnostic ignored "-Wdeprecated-declarations" when calling deprecated OpenSSL functions. The deprecated functions do still work, and with OpenSSL 3 being a LTS release until 2026, I'm hoping they'll continue to work until at least that date. Of course, this pushes the problem down the road, but here's why I think this is the best approach if you're unable to move to one of the forks. The OpenSSL 3 API is vastly different from the 1.0 or 1.1 APIs, and are currently poorly-documented. There's a migration guide, but but as lengthy as it is, I found it only minimally helpful in understanding how to transition from the 1.1 API to the 3.0 API. In short, a lot of structs and their associated functions have been deprecated in favor of using the more generic EVP_PKEY and its associated OSSL_PARAMS. OSSL_PARAMS is a struct that contains a sting key and a pointer value, and you get/set arrays of these params on keys. So instead of having C functions which clearly specify what their required parameters are, what they return, and the types of all these things, you get a few comments in the OpenSSL headers telling you which types go with which keys. The compiler won't warn you if you assign an integer value to a key that expects an octet string, for example. The rest of the documentation isn't much better. Some man pages are great, but most still leave it up to you to piece things together. Worse, there are quite a few use cases which are made more difficult and verbose by the new API. Browsing the github issues and the mailing list, there are quite a few scenarios that the OpenSSL team has said could be made easier in the future, but were somewhat of a blind spot during the initial design of the new API. Perhaps because of this, few major open source projects have moved to the new API, even with the EOL deadline so close. This, in turn, makes it difficult to find real-world uses of the new API to help learn how it should be used. However, the API is slowly getting better. In 3.1, OpenSSL added some functions to make building OSSL_PARAM arrays easier. By 2026, they may have improved the documentation, filled in the missing use cases in the API, and there may be more real-world examples to learn from. All of this would make moving to the new API much easier.

rlpb 3y ago

> it's a horror show of deprecations I'm not familiar with the 3.x API, but in the past merely using the OpenSSL API was a horror show. Surely deprecations are the only way out?