[openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release

Jason Vas Dias jason.vas.dias at gmail.com
Mon Mar 20 22:41:12 UTC 2017


Hi - much thanks for many years of great OpenSSL releases,
but this 1.1.0 branch, IMHO, should not be put above the 1.0.2k
release on the website as the 'latest / best OpenSSL release' - this just
wastes everybody's time .  No using software can use this release,
such as the latest releases of OpenSSH,  ISC BIND (named) / ISC DHCP,  ntpd
(... the list can go on and on - does the latest httpd  compile with it? )
 without major restructuring .
I did waste a few hours today getting ISC BIND 9.11.0-P3 & DHCP 4.3.5
& ntpd 4.3.93 to use 1.1.0e , (I can generate & send the patches for
them to anyone who wants them), and wpa_supplicant v2.7 ,   and got
the latest version of OpenSSH (v7.4.P1) to at least compile with it,
but that version of OpenSSH is broken in so many ways because of
openssl 1.1.0  - it can't even read or write its ED25519
/etc/ssh_host_ed25519.key file. It looks like too much work to support
the new 1.1.0 API  across all current OpenSSL using applications - and
what do these API "improvements" really get us?
At least ISC BIND & dhclient & wpa_supplican do now work with it  -
these are the programs I depend on for my internet connection -  but I
haven't really rested their OpenSSL using features much . And then I
saw the list of vulnerabilities which apply only to the 1.1.0 branch
and I realized "Oh, this is a development branch"  .
Now tonight / tomorrow I'll be recompiling OpenSSH, BIND, DHCP &
wpa_supplicant to use 1.0.2k & undoing all the patches I made (which
mainly
involved including the '*_lo?cl.h' & '*_int.h'  headers where the API
they were using moved, which are now not installed in
/usr/include/openssl ). Why you are now
hiding the API used by 90% of OpenSSL's core users I do not understand.
Couldn't you please inform users of this on the main openssl.org web-page ?
I appreciate the 1.1.0 software does pass its test suite, and
may introduce some API "improvements", if the old OpenSSL API did
not  have such a vast legacy of users to support - I question how any
API "improvement" can outweigh the cost of restructuring all current
using code to use it, especially with such a complex and typically
mission critical
library such as OpenSSL.
Sorry, I just had to let you have my two cents worth here.
Thanks & Regards,
Jason.


More information about the openssl-dev mailing list