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 >> SSL_OP_ALL? > > > 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
