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

[Weijun Wang]

The change looks fine.

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
>> 
>