On 06/11/2014 20:40, Christopher Schultz wrote:
> Mark,
> 
> On 11/6/14 11:25 AM, ma...@apache.org wrote:
>> Author: markt
>> Date: Thu Nov  6 16:25:53 2014
>> New Revision: 1637153
>>
>> URL: http://svn.apache.org/r1637153
>> Log:
>> Update proposal
>>
>> Modified:
>>     tomcat/tc6.0.x/trunk/STATUS.txt
>>
>> Modified: tomcat/tc6.0.x/trunk/STATUS.txt
>> URL: 
>> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1637153&r1=1637152&r2=1637153&view=diff
>> ==============================================================================
>> --- tomcat/tc6.0.x/trunk/STATUS.txt (original)
>> +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Nov  6 16:25:53 2014
>> @@ -52,18 +52,11 @@ PATCHES PROPOSED TO BACKPORT:
>>    Enable Tomcat to start when using a IBM JRE in strict SP800-131a mode
>>    This back-ports the fix as well as some additional changes to more closely
>>    align the Tomcat 6 code with the code in Tomcat 7.
>> -  http://people.apache.org/~markt/patches/2014-11-06-bug56780-tc6-v1.patch
>> +  http://people.apache.org/~markt/patches/2014-11-06-bug56780-tc6-v2.patch
>>    +1: markt
>> -  +0: kkolinko:
>> -       1) A problem:
>> -         Looking up attributes.get("protocol") in JSSESocketFactory
>> -         constructor won't work. It is a constructor. None attributes have
>> -         been set yet.
>> -       2) A trivial glitch:
>> -         In LocalStrings.properties a "jsse.excludeDefaultProtocol"
>> -         message is already present with the same text.
>>    -1:
>>  
>> +
>>  PATCHES/ISSUES THAT ARE STALLED:
>>  
>>  * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=44312
> 
> I'm not sure if a question is better placed here on the mailing list or
> in STATUS.txt... I think more people will see it, here.
> 
> Re: http://people.apache.org/~markt/patches/2014-11-06-bug56780-tc6-v2.patch
> 
> In JSSESocketFactory, you moved the auto-detection of the default
> protocols for an SSLServerSocket from a static initializer into the
> constructor for JSSESocketFactory. Since the defaults are for the whole
> JVM, why re-check the defaults for each instance of JSSESocketFactory?

Because I wanted to handle the case where those defaults depend on the
value provided for sslProtocol used to create the SSLContext. The
relationship between sslProtocol and sslEnabledProtocols is one that
isn't completely clear to me but it is certainly possible the JRE
vendors could vary the defaults for sslEnabledProtocols based on the
sslProtocol provided. This is sort of what is happening in bug 56780.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to