[security-dev 01274]: Re: 6885204: JSSE should not require Kerberos to be present

Brad Wetmore Bradford.Wetmore at Sun.COM
Mon Oct 5 23:08:38 UTC 2009



Vincent Ryan wrote:
> There's a new webrev available at:
> 
> http://cr.openjdk.java.net/~vinnie/6885204/webrev.01/webrev/


CipherSuite.java
================
  77     // It is true because we might not have an ECC or Kerberos 
implementation.

After your change, this comment should be reverted back.  Kerberos isn't 
dynamic.

Otherwise looks good.

Brad






> 
> 
> Brad Wetmore wrote:
>> Vincent Ryan wrote:
>>> I'm proposing a change that enables JSSE to work when Kerberos is not
>>> present
>>> at runtime:
>>>
>>>   http://cr.openjdk.java.net/~vinnie/6885204/webrev.00/webrev/
>> DelegateHttpsURLConnection.java/HttpsClient.java
>> ================================================
>>
>> Can you put in a comment here that explains why you've added the
>> ciphersuite check?  I had to think about it for a second, which means it
>> won't be immediately clear to others.  ;)
> 
> Done.
> 
>> CipherSuite.java/JsseJce.java
>> =================================
>>
>> // It is true because we might not have an ECC or
>> // Kerberos implementation.
>>
>> Here's a small can of worms.  The dynamic code was added when ECC was
>> only available via the PKCS11 provider, and people could remove the ECC
>> tokens at will and thus effectively disable ECC.  With the addition of
>> your full-time ECC provider, this could have gone away.  But since some
>> of the open source folks wanted to make your ECC provider optional, I
>> guess we're have to continue this check.
>>
>> That said, what you're trying to solve here is different.  Either the
>> Kerberos implementation is there or it isn't.  It doesn't get
>> dynamically installed into the JRE during the middle of a run, right? If
>> it's not made available dynamically, a simple one-time check should be
>> sufficient.
> 
> Right. I've changed the code to perform the Kerberos check just once
> (in a static initializer).
> 
> 
>> Is the doPrivileged necessary here?
> 
> Yes, because the Class.forName references a class from a different package.
> 
> 
>> Brad
>>
>>



More information about the security-dev mailing list