>  Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared
>> libraries are updated to include the patch existing applications wont set
>> it:
>> they'd all need to be recompiled.
> That's a valid point.

This is true, unfortunately.

>  Possibly alternative is to reuse one of the existing *ancient* flags. Does
>> anyone really care about compatibility with a bug in SSLeay 0.80 for
>> example?
> Wouldn't it be better to reverse the meaning of the flag and not set it in

Hm, without any SSL_OP_... settings, the expectation generally is that we
kind of sort of follow the specs and don't do any weird stuff like this for
interoperability's sake. If we switch semantics around for certain options,
the resulting inconsistencies would make all that even more confusing.

In theory we could create an explicit "SSL_OP_ALL"-equivalent bit
(SSL_OP_ALL_ALL?) that enables all current SSL_OP_ALL features and doesn't
allow further masking, but that seems hard to deploy given that some
current applications may expressly want SSL_OP_ALL *without* certain flags.
Of course the legacy flag an application disables could be the one that
we're about to recycle ... SSL_OP_ALL ideally would always have included
some unused bits for future use, but that again is hard to pull off
retroactively -- it's probably a good idea for a later release (with an
incompatible .so version so that we can safely change SSL_OP_ALL).

If we can find an appropriate ancient flag that no one should care about
(which sounds plausible), recycling that one sounds like a good idea. If we
can't, using reverted semantics might be the best option we have.


Reply via email to