`<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 2, 2016 at 12:08 AM, Bob Friesenhahn <span dir="ltr"><<a href="mailto:bfriesen@simple.dallas.tx.us" target="_blank">bfriesen@simple.dallas.tx.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 1 Mar 2016, Dan McDonald wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Bloody's fate remains up in the air. I'm contemplating removing SSLv2 support from bloody, and when it ships, r151018. This will require, however, some godawful bootstrapping, akin to the gcc version change I did for r151015/6. Anyone who's a fan of bloody should followup on this thread to tell me what you think.<br>
</blockquote>
<br></span>
If you remove SSLv2 APIs without bumping the major interface of the library, then you will curse all already-built user applications with the same fate which befell Python. If you bump the major interface of the library, then the old library still needs to be available to support existing apps.<br>
<br>
We are already on the latest OpenSSL release on the newest branch so until upstream makes a breaking release (e.g. the planned 1.1.0), then it is not so convenient for OmniOS to do so. If you wait for 1.1.0, then it may be much easier.<br></blockquote><div><br></div><div>IIRC, 1.1.0 has this change already. That's fine, as it's a new release and is allowed<br></div><div>to make incompatible changes.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Perhaps it is possible to tweak the library (or config file) so that SSLv2 won't acutally be used.<span class="HOEnZb"><font color="#888888"></font></span><br></blockquote></div><br></div><div class="gmail_extra">Actually, no. What would be ideal is that openssl provided stub functions that return<br></div><div class="gmail_extra">an error, so symbol resolution works fine (but anything actually calling SSLv2 will fail).<br></div><div class="gmail_extra">As it is, they're yanking the functions and breaking binary compatibility by default.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Things are made worse by the fact that consumers of the openssl library (things like wget,<br>libcurl) tend to blindly enable SSLv2 support if it's present in the openssl implementation<br>they're built against. Often without a way of disabling it otherwise. So you either have to<br></div><div class="gmail_extra">work out how to manually disable SSLv2 for those consumers, or build them on a system<br></div><div class="gmail_extra">that has openssl installed but with SSLv2 disabled. Then, of course, you have to make<br></div><div class="gmail_extra">sure that updated consumers get pushed out and updated by users *before* you push<br></div><div class="gmail_extra">out a "fixed" openssl. And if end users have built applications, then they're up the creek<br>without a paddle. It's just a mess.<br clear="all"></div><div class="gmail_extra"><br>-- <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>
`