[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OpenSSL 1.1.0



2016-06-14 13:11 GMT+02:00 Guus Sliepen <guus@debian.org>:
On Sat, Jun 11, 2016 at 02:30:37PM +0200, Kurt Roeckx wrote:

> The release of OpenSSL 1.1.0 is getting nearer.  Some packages
> will no longer build with the new version without changes.  Most
> of those changes should be trivial, like you can't allocate some
> structures on the stack anymore and need to use the correct _new()
> and _free() function.
>
> It can also mean that you can't directly access some members of
> those structures anymore and need to use a function instead.

While I think these changes are very good, upgrading is not trivial.
Especially not if, as an upstream project, you want to stay compatible
with older versions of OpenSSL as well; at least with 1.0.1/1.0.2,
because many distributions use that in their stable releases.

> Guus Sliepen <guus@debian.org>
>    tinc

Luckily, with tinc I can get away with doing some autoconf checks to see
if BN_GENCB_new()/_free() and RSA_set0_key() exist, and if not provide
my own versions. And I'll have to check compatibility with LibreSSL as
well. It's just so you know that it's not as trivial as you make it
sound.


The openssl release strategy page [1] states:
Version 1.1.0 will be supported until 2018-04-30.
Version 1.0.2 will be supported until 2019-12-31 (LTS).

Considering the dates, upstream authors using openssl 1.0.2 might not
migrate to the new api until 1.0.2 end of life.
Is it reasonnable, for security and human resources sake, to carry hundreds
of patches for a transition that will happen much more safely and naturally later ?

Also in my opinion as well, the required work is not so trivial - qt, nodejs, and also
software not in debian like lua's jwt package all require quite some time with
probably low-quality results far from what upstream authors would do.

Cheers,
Jérémy


[1]
https://www.openssl.org/policies/releasestrat.html  


Reply to: