> 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. Bodo
