Philip Guenther wrote:
On Wed, 13 Aug 2008, Howard Chu wrote:
This should use a single option flag and a numeric or bitfield argument for selecting protocols instead. Since we're talking about minimum settings, it should likely just be an increasing range of numbers.
I note that the on-the-wire protocol version is just a 16 bit integer; we could define protocol names that correspond directly to these values.
OpenSSL's API for this is a bitfield with symbolic names, so there would still need to be a maintained mapping from whatever schema OpenLDAP provided to that bit set.
Yes, but there's no forward compatibility impact from this. I.e., if we have to map numbers to bitfields, we can just have a default case: if the number is higher than any we recognize, just disable all the bits we know about and assume the TLS library is smart enough to do something useful with whatever is left.
I guess an alternative would be to directly expose the SSL_CTX_set_options() API: TLS_OPTIONS would take a number and pass it directly to that call. Of course, the admin would have to read the .h file and do some math to figure out what to set, and there's no guarantee that OpenSSL won't change those values across a version change...
I think at this point we need to get away from using implementation-specific values. Back when OpenSSL was the only game in town I wouldn't have worried too much about it, but now it's becoming more of an issue.