tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Surprising implementation of SSL.hasOp
Date Fri, 05 Oct 2012 00:19:24 GMT
Rainer,

On 10/4/12 5:27 PM, Rainer Jung wrote:
> On 04.10.2012 23:14, Christopher Schultz wrote:
>> For instance, we could use a technique similar to the above to set a
>> static bitset:
>>
>> static int supported_ssl_opts = 0;
>>
>> initialize() {
>>     ...
>> #ifdef SSL_OP_MICROSOFT_SESS_ID_BUG
>>     supported_ssl_opts |= SSL_MICROSOFT_SESS_ID_BUG;
>> #endif
>>     ...
>> }
>>
>> Then, hasOp becomes:
>>
>> hasOp(op) {
>>    return op == (supported_ssl_options & op);
>> }
> 
> That looks good.

I've thought about it more, and we don't have to wait around for
initialize to be called. We can actually have the compiler make us a
constant:

static const int supported_ssl_opts = 0

#ifdef SSL_OP_ALLOW_UNSAFE_INSECURE_RENEGOTIATION
   | SSL_OP_ALLOW_UNSAFE_INSECURE_RENEGOTIATION
#endif
   [...]
#ifdef SSL_OP_MICROSOFT_SESS_ID_BUG
   | SSL_OP_MICROSOFT_SESS_ID_BUG
#endif
   | 0;

Then the 'variable' is read-only, enforced by the compiler.

>> If we still want to (and I think we probably should) test for unknown
>> options in hasOp (to indicate to the user that OpenSSL actually has no
>> idea what you are talking about -- usually a version-to-low situation),
>> I'm not sure how to do that.
> 
> Wouldn't unknown options result in the same as non-supported ones? That
> should be OK.

Yeah, I think I was coming to that realization as I was writing my
earlier message: support either exists or it doesn't, and it's up to the
Java code to decide if it's so important that an exception must be thrown.

Patch forthcoming.

-chris


Mime
View raw message