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

[Xuelei Fan]

On 1/24/2018 11:14 PM, Weijun Wang wrote:
> The change looks fine.
> 
+1

Xuelei

> Thanks
> Max
> 
>> On Jan 25, 2018, at 1:52 PM, sha.jiang at oracle.com wrote:
>>
>> 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
>>>
>>
>