<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 31, 2016 at 3:40 PM, Dan McDonald <span dir="ltr"><<a href="mailto:danmcd@omniti.com" target="_blank">danmcd@omniti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As I'm updating and checking packages for r151018's release, I notice that OpenSSL is rapidly approaching a 1.1.0 release.  I visited their Release Strategy page:<br>
<br>
        <a href="http://openssl.org/policies/releasestrat.html" rel="noreferrer" target="_blank">http://openssl.org/policies/releasestrat.html</a><br>
<br>
And noticed that 1.0.2 is LTS until 2019.  OTOH, 1.1.x will likely become LTS for some x,</blockquote><div><br></div><div>For x > 0 and as yet unannounced. Although the policy tells us roughly when<br></div><div>the next LTS is announced, end 2018 would seem reasonable.<br><br></div><div>What this tells me is to stick to 1.0.2 as the supported branch until the next LTS<br></div><div>is decided. I'm presuming everything is going to be properly versioned so that<br></div><div>one can ship two versions of the shared library in parallel for a transitional period.<br><br>(Hm. Sounds rather like the libpng story in terms of evolving the API by making<br>structures opaque. Although libpng changes the library name as well as the<br>version number of the .so. But my experience there was that the transition<br></div><div>was pretty ugly.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and there's also LibreSSL...<br></blockquote><div><br></div><div>Not to mention PolarSSL and WolfSSL and ...<br><br></div><div>None of which are binary compatible with the current openssl (by which I mean<br></div><div>you can use them as shared-library replacements). Although recent events have<br></div><div>shown that openssl releases aren't quite as binary compatible as one would like.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm starting this thread to hear what the community has to say about where OmniOS should go w.r.t. its OpenSSL release.  I have internal customers too, of course, but I'll engage them separately.  We need to have an OpenSSL because illumos requires one.  We *could* do the SmartOS thing and keep our own SUNW/OMNI*...() api set, though.<br></blockquote><div><br></div><div>They have to play those games because they ship 2 different openssl instances,<br>though. (One with the platform, one via pkgsrc or whatever.) If you hide the internal<br>copy, you still have to manage (or someone does, at any rate) compatibility and<br>releases of the public copy. The problem doesn't go away, you just sweep it under<br></div><div>someone else's carpet.<br><br></div><div>Users will have binaries linked against the existing openssl libraries, and those<br></div><div>need to continue to run.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I can't guarantee what I'll ultimately decide, but knowing what people think can't hurt.<br></blockquote></div><br></div><div class="gmail_extra">Thanks for asking!<br><br></div><div class="gmail_extra">-- <br><div class="gmail_signature">-Peter Tribble<br><a href="http://www.petertribble.co.uk/" target="_blank">http://www.petertribble.co.uk/</a> - <a href="http://ptribble.blogspot.com/" target="_blank">http://ptribble.blogspot.com/</a></div>
</div></div>