RFR JDK-8186098: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed due to libnss3 version cannot be parsed

sha.jiang at oracle.com sha.jiang at oracle.com
Thu Jan 25 05:52:57 UTC 2018


Hi Max, Xuelei,
Please review this updated patch: 
http://cr.openjdk.java.net/~jjiang/8186098/webrev.01/
Both of your suggestions are addressed.

Best regards,
John Jiang

On 24/01/2018 12:20, Weijun Wang wrote:
>
>> On Jan 24, 2018, at 11:28 AM, sha.jiang at oracle.com wrote:
>>
>> Hi Max,
>>
>> On 23/01/2018 17:49, Weijun Wang wrote:
>>> Can you show us why the new code works?
>> The test assumes that nss3 lib contains a string likes:
>> $Header: NSS version.number, e.g. "$Header: NSS 3.16.2"
>> or
>> Version: NSS version.number, e.g. "Version: NSS 3.34.1"
>>
>> But the current test expects that the version.number is followed by a space immediately. For example, "$Header: NSS 3.16.2 Basic". So, it tries to locate the next space index for parsing the version.
>> Unfortunately, that assumption is not true on some NSS builds. For example, "Version: NSS 3.34.1
�".
> I see.
>
> BTW, the byte-to-string conversion looks a little strange as the data is pure binary. Maybe you can use StandardCharsets.US_ASCII to be safe.
>
> --Max
>
>> This fix just cares the chars, such as "." or "0-9", after "$Header: NSS " or "Version: NSS ". If a char, which is not in the specific char set ("." or "0-9"), is met, that means the version has been extracted.
>>
>>>   What does "s" looks like?
>> The followings are some snippets of nss3 lib from different NSS builds.
>> 1. NSS 3.16.2 on macosx
>> Content-Length: %u
>




More information about the security-dev mailing list