<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"> <span><br>Just commenting on this: I had very few problems moving from 1.0.2 to 1.1.0. We'd already cleaned up most of the issues OpenSSL fixed between 1.0.2 and 1.1.0, those fixups were well isolated so migrating was just a matter of ifdef'ing out accessors/allocators/deallocators we'd created to civilize the API and replace those with the equivalents native to 1.1.0. <br>Things like that you can't fix without breaking someone, and without fixing that you can't provide stable ABI's going forward, as Richard says someone will break at some point when you do that anyway.  I'll concede we realized ABI stability would be an issue well in advance of 1.1.0 but it was just good defensive programming practice achieved that, not inside information.<br><br>Mind you, some of the problems in 1.1.0x are awesome, older HP/UX PA-RISC compilers turn some of the macros deep in OpenSSL to local functions - embedded in every object file. Our footprint there went from 2M to 20M. Solaris had similar issues but not quite as bad in practice.<br><br>Peter<br></span><br><font color="#990099">-----"openssl-dev" <<a href="mailto:openssl-dev-bounces@openssl.org" target="_blank">openssl-dev-bounces@openssl.org</a>> wrote: -----</font><div class="iNotesHistory" style="padding-left:5px;"><div style="padding-right:0px;padding-left:5px;border-left:solid black 2px;">To: <a href="mailto:openssl-dev@openssl.org" target="_blank">openssl-dev@openssl.org</a><br>From: Richard Levitte <levitte@openssl.org><br>Sent by: "openssl-dev" <openssl-dev-bounces@openssl.org><br>Date: 03/21/2017 06:56PM<br>Subject: Re: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release<br><br><div><font size="2" face="Courier New,Courier,monospace">In message <<a href="mailto:CALyZvKy_Y0EwAuPzBWsYRQ2K+onZyfRaN1t8c7UPoX5_0jP8Yg@mail.gmail.com" target="_blank">CALyZvKy_Y0EwAuPzBWsYRQ2K+onZyfRaN1t8c7UPoX5_0jP8Yg@mail.gmail.com</a>> on Tue, 21 Mar 2017 00:13:57 +0000, Jason Vas Dias <<a href="mailto:jason.vas.dias@gmail.com" target="_blank">jason.vas.dias@gmail.com</a>> said:<br><br>jason.vas.dias> On 20/03/2017, Kurt Roeckx <<a href="mailto:kurt@roeckx.be" target="_blank">kurt@roeckx.be</a>> wrote:<br>jason.vas.dias> > The ed25519 support in openssh doesn't even come from openssl.<br>jason.vas.dias> ><br>jason.vas.dias> What happens is OpenSSH's cipher.c calls<br>jason.vas.dias>        if (EVP_CipherInit(cc->evp, type, NULL, (u_char *)iv,<br>jason.vas.dias>           (do_encrypt == CIPHER_ENCRYPT)) == 0) {<br>jason.vas.dias>                 ret = SSH_ERR_LIBCRYPTO_ERROR;<br>jason.vas.dias>                 goto out;<br>jason.vas.dias>         }<br>jason.vas.dias> which always does 'goto out' for any ED25519 file.<br><br>That would happen if ssh_host_ed25519_key is password protected and<br>the cipher used to encrypt the key isn't recognised in OpenSSL 1.1.0<br>(and considering the current master of openssh-portable doesn't build<br>cleanly against OpenSSL 1.1.0e and I therefore suppose you've hacked<br>around, I can't even begin to say where the fault came in).  It also<br>depends on your OpenSSL configuration, since you can disable most<br>algorithms it carries...<br><br>jason.vas.dias> >> which mainly<br>jason.vas.dias> >> involved including the '*_lo?cl.h' & '*_int.h'  headers<br>jason.vas.dias> ><br>jason.vas.dias> > Including the internal headers is not a good patch. This will<br>jason.vas.dias> > break.<br>jason.vas.dias> ><br>jason.vas.dias> <br>jason.vas.dias> It doesn't break at all - the code remains 100% unchanged  - just different<br>jason.vas.dias> headers need including - and seems to work fine including the API<br>jason.vas.dias> hiding headers.<br><br>The structures you find in there are made private for a reason, we<br>need the liberty to make changes in them in future developments<br>without disturbing the ABI (not just the API).  So some time in the<br>future, it will break.<br><br>jason.vas.dias> And my point is really not to criticize your effort, it is just a plea to make<br>jason.vas.dias> clear on the web-page that the 1.1.0 branch is a development branch and<br>jason.vas.dias> does not work yet with most OpenSSL using applications .<br><br>It isn't a development branch.  We see it as a stable release, i.e. no<br>further development apart from bug fixes.  "master" is the development<br>branch.<br><br>jason.vas.dias> OpenSSL in its 1.0.2 incarnation has been hardened by over (10,15,20)? years<br>jason.vas.dias> of testing , and its API is usable by all OpenSSL using applications,<br>jason.vas.dias> unlike 1.1.0 .<br><br>Jyst to put things in perspective, OpenSSL 1.0.0 was released<br>2010-Mar-29.  That was the start of the 1.0.x series.  OpenSSL 1.0.2<br>was released 2015-Jan-22.<br><br>OpenSSL 1.1.0 marks the start of the 1.1.x series, which isn't source<br>compatible with the 1.0.x series.  We have talked about this in<br>different ways even before the first Alpha release was made (over a<br>year ago).<br><br>Either way, the 1.0.2 branch is supported until the end of 2019.<br>One could say that's how long other application authors have to rework<br>their source, although that's not really true since anyone can keep<br>the 1.0.2 source around as long as they want (hey, even we do).<br><br>Maybe you expected all applications to have converted the moment we<br>declared our 1.1.0 release stable?  That will not happen...  as far as<br>we've observed, most are hardly even looking before we've made a<br>stable release (which I agree is unfortunate).<br><br>Cheers,<br>Richard<br><br>-- <br>Richard Levitte         <a href="mailto:levitte@openssl.org" target="_blank">levitte@openssl.org</a><br>OpenSSL Project         <a href="http://www.openssl.org/~levitte/">http://www.openssl.org/~levitte/</a><br>-- <br>openssl-dev mailing list<br>To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br><br></font></div></openssl-dev-bounces@openssl.org></levitte@openssl.org></div></div></font><BR>