3 ms·

As someone who recently went through probably one of the larger bits of work porting from openssl 1.0 to 1.1; I can say I mostly appreciate the new API (main pr

As someone who recently went through probably one of the larger bits of work porting from openssl 1.0 to 1.1; I can say I mostly appreciate the new API (main problem is a few missing setters/getters, see e.g. https://github.com/openssl/openssl/issues/1620 https://github.com/openssl/openssl/issues/1620, https://github.com/openssl/openssl/issues/1885 https://github.com/openssl/openssl/issues/1885). Outside of bindings to OpenSSL for each language, the migration path is pretty simple. This was a cleanup that had to happen sooner or later: projects using OpenSSL were never going to have an option to not change.

tedunangst 10y ago
The migration itself is fairly simple, but once you make it you're shut out of linking against 1.0, which is where the majority of users still are. It's an unnecessary python3 type scenario. People are going to drag out the transition for as long as 1.0 remains viable. So only like three more years.
- daurnimator 10y ago
  You add small compatibility macros. Which most openssl code already had. We still have to support openssl back to 0.9.8, so this isn't out of the ordinary. See https://github.com/wahern/luaossl/blob/master/src/openssl.c#L1243 https://github.com/wahern/luaossl/blob/master/src/openssl.c#... for all the compatible wrappers we have
caf 10y ago
It's not about projects using OpenSSL not changing - everyone accepts that projects will need to change occasionally to keep up with a changing upstream API. The migration path in question isn't "change project to support OpenSSL 1.1" - it's "change project so that it can be built against both OpenSSL 1.0 and OpenSSL 1.1 in the medium term". And yes, of course that can be done by introducing a bunch of glue macros or #ifdeffery in each project, the argument here is just that if every project has to reinvent that compatibility layer then inevitably many of them will be incorrect.

tedunangst 10y ago

The migration itself is fairly simple, but once you make it you're shut out of linking against 1.0, which is where the majority of users still are. It's an unnecessary python3 type scenario. People are going to drag out the transition for as long as 1.0 remains viable. So only like three more years.

daurnimator 10y ago
You add small compatibility macros. Which most openssl code already had. We still have to support openssl back to 0.9.8, so this isn't out of the ordinary. See https://github.com/wahern/luaossl/blob/master/src/openssl.c#L1243 https://github.com/wahern/luaossl/blob/master/src/openssl.c#... for all the compatible wrappers we have

caf 10y ago

It's not about projects using OpenSSL not changing - everyone accepts that projects will need to change occasionally to keep up with a changing upstream API. The migration path in question isn't "change project to support OpenSSL 1.1" - it's "change project so that it can be built against both OpenSSL 1.0 and OpenSSL 1.1 in the medium term". And yes, of course that can be done by introducing a bunch of glue macros or #ifdeffery in each project, the argument here is just that if every project has to reinvent that compatibility layer then inevitably many of them will be incorrect.