[OmniOS-discuss] PHEW! OpenSSL 1.0.2g and 1.0.1s NOW OUT, albeit with SSLv2_* enabled

[Peter Tribble]

On Wed, Mar 2, 2016 at 12:08 AM, Bob Friesenhahn <
bfriesen at simple.dallas.tx.us> wrote:

> On Tue, 1 Mar 2016, Dan McDonald wrote:
>
>>
>> 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.
>>
>
> 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.
>
> 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.
>

IIRC, 1.1.0 has this change already. That's fine, as it's a new release and
is allowed
to make incompatible changes.


> Perhaps it is possible to tweak the library (or config file) so that SSLv2
> won't acutally be used.
>

Actually, no. What would be ideal is that openssl provided stub functions
that return
an error, so symbol resolution works fine (but anything actually calling
SSLv2 will fail).
As it is, they're yanking the functions and breaking binary compatibility
by default.

Things are made worse by the fact that consumers of the openssl library
(things like wget,
libcurl) tend to blindly enable SSLv2 support if it's present in the
openssl implementation
they're built against. Often without a way of disabling it otherwise. So
you either have to
work out how to manually disable SSLv2 for those consumers, or build them
on a system
that has openssl installed but with SSLv2 disabled. Then, of course, you
have to make
sure that updated consumers get pushed out and updated by users *before*
you push
out a "fixed" openssl. And if end users have built applications, then
they're up the creek
without a paddle. It's just a mess.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20160302/e6d80852/attachment.html>