2016-06-14 13:11 GMT+02:00 Guus Sliepen <g...@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 <g...@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
