Re: 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.ji...@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.ji...@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
>> 
> 

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

[sha . jiang]

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.ji...@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

RFR 8177398: Exclude dot files ending with .conf from krb5.conf's includedir

[Weijun Wang]

Please take a review at

   http://cr.openjdk.java.net/~weijun/8177398/webrev.00/

Dotfiles will not be included in "includedir" of krb5.conf.

Thanks
Max

Re: contribute to the OpenJDK security group

[Andrew Haley]

On 24/01/18 10:39, Tomas Gustavsson wrote:
> Imho the P11 layer always needs attention. To work properly we're
> relying on some patches, where parts was recently merged into OpenJDK.
> We just started testing the Amazon CloudHSM, and that requires changes
> to SunPKCS11 as well to work. Not always bad in SunPKCS11 as some P11
> libraries out there do strange non-conforming stuff, but there's room
> for more flexibility nevertheless.

Martin Balao has been heavily reworking this layer because it leaks
native memory.  I'll let him fill you in on the details.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: contribute to the OpenJDK security group

[Tomas Gustavsson]

Sorry for jumping in :-)

Imho the P11 layer always needs attention. To work properly we're
relying on some patches, where parts was recently merged into OpenJDK.
We just started testing the Amazon CloudHSM, and that requires changes
to SunPKCS11 as well to work. Not always bad in SunPKCS11 as some P11
libraries out there do strange non-conforming stuff, but there's room
for more flexibility nevertheless.

Cheers,
Tomas

On 2018-01-17 20:09, Leo Grove wrote:
> Thanks Sean, I've filled out the OCA and sent it in. I'll take a gander
> around after reading up on the link you posted and see where we might be
> able to jump in and assist.
> 
> Leo
> 
> 
> On 1/17/2018 7:53 AM, Sean Mullan wrote:
>> Hi Leo,
>>
>> Thanks for the offer to help and contribute! I would suggest you start
>> by reading the OpenJDK contribution page (if you have not done so
>> already):
>>
>> http://openjdk.java.net/contribute/
>>
>> which has some tips and other helpful advice. You will also need to
>> sign an OCA (Oracle Contributor Agreement) before we can accept any
>> contributions.
>>
>> Thanks,
>> Sean
>>
>> On 1/16/18 9:03 PM, Leo Grove wrote:
>>> Hello Everyone,
>>>
>>> I'd like to introduce myself. I'm Leo Grove, founder of SSL.com and
>>> also Java Certified Programmer ('98). Although I'm not so much into
>>> coding these days, I'm always looking for ways to contribute to
>>> internet security and the public WebPKI. We do have some very sharp
>>> java developers that specialize in PKI and certs, so if there is
>>> something you need a hand with (or a pair of eyeballs on), please let
>>> me know, thanks.
>>
>>
>