[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