On 14 June 2013 16:10, Bodo Moeller <bmoel...@acm.org> wrote:
>>> 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.

We could just add an SSL_OP_ALL_FROM_FUTURE flag that did this, and
leave SSL_OP_ALL as it is?

If you really want to get funky, you could make it so any bit set with
SSL_OP_ALL_FROM_FUTURE disables the corresponding feature. This would
mean you could never re-use bits, tho...
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to