Code review request for 7036252: sunpkcs11-solaris.cfg needs a review

Valerie (Yu-Ching) Peng valerie.peng at oracle.com
Fri Apr 29 20:59:25 UTC 2011


In general, T4 runs much faster, this goes not just for PKCS11 provider, 
but for pure java provider as well.
My run is focused on the settings of disabled mechanism section. Based 
on the run results, message digests excluded, performance numbers are 
similar between the default one and the special one which doesn't 
disable any mechanisms.

Valerie

On 04/29/11 01:38 PM, Frances Ho wrote:
>
> So what were the results from your run on the T4? performance wise.
>
>
> On 4/29/2011 11:14 AM, Valerie (Yu-Ching) Peng wrote:
>> Right, good point. I'll update the bugster w/ evaluation on
>> CKM_SSL3_KEY_AND_MAC_DERIVE and CKM_TLS_KEY_AND_MAC_DERIVE.
>> True, conceptually this should be done for every release. Although,
>> realistically, I don't think we'll need to adjust this again for jdk8
>> given that the remaining Solaris bugs have already been closed. But
>> still, I'll add a sub-CR for jdk8, so we can check and cross it off
>> later (not really worthy of a P2 for jdk 8 though).
>>
>> Thanks,
>> Valerie
>>
>> On 04/29/11 05:45 AM, Sean Mullan wrote:
>>> This looks fine. However, the bug report never mentions why it is ok
>>> to remove the CKM_SSL3_KEY_AND_MAC_DERIVE and
>>> CKM_TLS_KEY_AND_MAC_DERIVE mechanisms. I think it should be updated.
>>>
>>> Also, isn't this the kind of thing we should periodically review each
>>> release? If so, maybe we should create a sub-CR for JDK 8, keep that
>>> open, and re-evaluate later.
>>>
>>> --Sean
>>>
>>> On 4/28/11 8:59 PM, Valerie (Yu-Ching) Peng wrote:
>>>> Sean,
>>>>
>>>> Could you please review this PKCS11 configuration file change before
>>>> next Monday?
>>>>
>>>> http://cr.openjdk.java.net/~valeriep/7036252/webrev.00/
>>>>
>>>> I have run the regression tests against the new config file and
>>>> things look fine.
>>>> More information can be found in the bugster record.
>>>>
>>>> Thanks,
>>>> Valerie
>>




More information about the security-dev mailing list