Re: RFR: 8291897: TerminatingThreadLocal(s) not registered from virtual thread(s) [v2]

2022-08-08 Thread Alan Bateman 
On Fri, 5 Aug 2022 09:54:36 GMT, Peter Levart  wrote:

>> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) 
>> when used internally in JDK for per-carrier-thread caches of native 
>> ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such 
>> TerminatingThreadLocal(s) are not registered with the carrier thread for the 
>> cleanup.
>> The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal 
>> which rewires its API methods to use current thread's carrier thread as the 
>> source of ThreadLocalMap instead of current thread itself (if it is a 
>> VirtualThread for example). TerminatingThreadLocal is now a subclass of 
>> CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase 
>> for it. The uses of JavaLangAccess in various places to access a 
>> carrier-thread value of given ThreadLocal has been replaced by public API 
>> calls and the use of CarrierThreadLocal instead of plain ThreadLocal. 
>> JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, 
>> but only for that. Would someone be tempted to use JavaLangAccess methods 
>> directly, they now require CarrierThreadLocal argument to guard against 
>> missuses.
>> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have 
>> values bound to a particular carrier thread is now implemented conveniently  
>> with a CarrierThreadLocal.
>> The test is expanded with a case that demonstrates a situation where a 
>> carrier thread is terminated. Since it must wait for 30 seconds for that to 
>> happen, only one of the test cases is performed in this mode. The correct 
>> logic of TerminatingThreadLocal is still verified with all test-cases using 
>> platform threads that can be terminated more rapidly.
>
> Peter Levart has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Removed unused JLA, SharedSecrets, added @enablePreview test annotation

Marked as reviewed by alanb (Reviewer).

-

PR: https://git.openjdk.org/jdk/pull/9743

Re: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v3]

2022-08-08 Thread Jayashree Huttanagoudar 
On Thu, 4 Aug 2022 01:40:36 GMT, Weijun Wang  wrote:

> BTW, have you reverted your change on `LoginContext.java`. I remembered we 
> agreed that this bug is all about debug info instead of updating the 
> exception thrown.

Actually here: 
https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug , 
the ask is that its better to print the stack trace of an exception so I didn't 
revert it back. And sorry I didn't mention that in the conversation. 
Already the `debug.println` is there for `OPTIONAL` section here: 
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L880
 where `debug!=null`.

-

PR: https://git.openjdk.org/jdk/pull/9159

RFR: 8155246: Throw error if default java.security file is missing

2022-08-08 Thread Sean Coffey 
In the broken case where the conf/security/java.security configuration file 
doesn't exist, the JDK should throw an Error. 

CSR in progress.

-

Commit messages:
 - Update bug summary in test
 - 8155246

Changes: https://git.openjdk.org/jdk/pull/9747/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9747&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8155246
  Stats: 119 lines in 3 files changed: 101 ins; 17 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9747.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9747/head:pull/9747

PR: https://git.openjdk.org/jdk/pull/9747

Integrated: 8291897: TerminatingThreadLocal(s) not registered from virtual thread(s)

2022-08-08 Thread Peter Levart 
On Thu, 4 Aug 2022 10:57:53 GMT, Peter Levart  wrote:

> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) 
> when used internally in JDK for per-carrier-thread caches of native 
> ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such 
> TerminatingThreadLocal(s) are not registered with the carrier thread for the 
> cleanup.
> The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal 
> which rewires its API methods to use current thread's carrier thread as the 
> source of ThreadLocalMap instead of current thread itself (if it is a 
> VirtualThread for example). TerminatingThreadLocal is now a subclass of 
> CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for 
> it. The uses of JavaLangAccess in various places to access a carrier-thread 
> value of given ThreadLocal has been replaced by public API calls and the use 
> of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still 
> used to dispatch the CarrierThreadLocal API methods, but only for that. Would 
> someone be tempted to use JavaLangAccess methods directly, they now require 
> CarrierThreadLocal argument to guard against missuses.
> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have 
> values bound to a particular carrier thread is now implemented conveniently  
> with a CarrierThreadLocal.
> The test is expanded with a case that demonstrates a situation where a 
> carrier thread is terminated. Since it must wait for 30 seconds for that to 
> happen, only one of the test cases is performed in this mode. The correct 
> logic of TerminatingThreadLocal is still verified with all test-cases using 
> platform threads that can be terminated more rapidly.

This pull request has now been integrated.

Changeset: 861cc671
Author:Peter Levart 
URL:   
https://git.openjdk.org/jdk/commit/861cc671e2e4904d94f50710be99a511e2f9bb68
Stats: 262 lines in 9 files changed: 196 ins; 12 del; 54 mod

8291897: TerminatingThreadLocal(s) not registered from virtual thread(s)

Reviewed-by: alanb

-

PR: https://git.openjdk.org/jdk/pull/9743

Re: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v4]

2022-08-08 Thread Jayashree Huttanagoudar 
> Could you please review the changes?
> This patch is to address : 
> https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug

Jayashree Huttanagoudar has updated the pull request incrementally with one 
additional commit since the last revision:

  Address review comments

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/9159/files
  - new: https://git.openjdk.org/jdk/pull/9159/files/3bce8d96..e3ab4348

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=02-03

  Stats: 109 lines in 3 files changed: 0 ins; 109 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9159.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159

PR: https://git.openjdk.org/jdk/pull/9159

Integrated: JDK-8290975 Minor cleanup could be done in javax.security

2022-08-08 Thread Mark Powers 
On Wed, 27 Jul 2022 20:24:19 GMT, Mark Powers  wrote:

> https://bugs.openjdk.org/browse/JDK-8290975

This pull request has now been integrated.

Changeset: 08274e6f
Author:Mark Powers 
Committer: Bradford Wetmore 
URL:   
https://git.openjdk.org/jdk/commit/08274e6fea982e71ccc5964f4919c65501b048e1
Stats: 114 lines in 16 files changed: 10 ins; 24 del; 80 mod

8290975: Minor cleanup could be done in javax.security

Reviewed-by: wetmore, mullan

-

PR: https://git.openjdk.org/jdk/pull/9664

Re: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v5]

2022-08-08 Thread Jayashree Huttanagoudar 
> Could you please review the changes?
> This patch is to address : 
> https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug

Jayashree Huttanagoudar has updated the pull request incrementally with one 
additional commit since the last revision:

  Added test case using {Unix,NT}LoginModule

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/9159/files
  - new: https://git.openjdk.org/jdk/pull/9159/files/e3ab4348..a7997f05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=03-04

  Stats: 82 lines in 1 file changed: 82 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9159.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159

PR: https://git.openjdk.org/jdk/pull/9159

Re: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v3]

2022-08-08 Thread Jayashree Huttanagoudar 
On Mon, 8 Aug 2022 08:42:11 GMT, Jayashree Huttanagoudar  
wrote:

> > BTW, have you reverted your change on `LoginContext.java`. I remembered we 
> > agreed that this bug is all about debug info instead of updating the 
> > exception thrown.
> 
> Actually here: 
> https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug , 
> the ask is that its better to print the stack trace of an exception so I 
> didn't revert it back. And sorry I didn't mention that in the conversation. 
> Already the `debug.println` is there for `OPTIONAL` section here: 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L880
>  where `debug!=null`.

I have reverted my changes to LoginContext.java. I verified that, the change I 
added wasn't making any difference with the test case I wrote using 
{Unix,NT}LoginModule.
Further, I am not sure which could be the right place to add logging 
information to help developer understand the failure reason of an optional JAAS 
LoginModule.

-

PR: https://git.openjdk.org/jdk/pull/9159

Re: RFR: 8155246: Throw error if default java.security file is missing

2022-08-08 Thread Anthony Scarpino 
On Thu, 4 Aug 2022 15:22:23 GMT, Sean Coffey  wrote:

> In the broken case where the conf/security/java.security configuration file 
> doesn't exist, the JDK should throw an Error. 
> 
> CSR in progress.

What's the need for this change?  Perhaps I'm missing the bigger problem here. 
Certainly not having a java.security file is sub-optimal and I suspect very 
very rare, but throwing exceptions that breaks existing apps seems like a big 
hammer and would now need a property added to override

Doing this change for jdk-dev only I could see, but as the CSR points toward 
backporting, that seems more risky

-

PR: https://git.openjdk.org/jdk/pull/9747

Re: RFR: 8155246: Throw error if default java.security file is missing

2022-08-08 Thread Sean Coffey 
On Thu, 4 Aug 2022 15:22:23 GMT, Sean Coffey  wrote:

> In the broken case where the conf/security/java.security configuration file 
> doesn't exist, the JDK should throw an Error. 
> 
> CSR in progress.

Hi Tony,

there are a few points for the change IMO:

* The fall back to the "static" security policy file is broken since JDK 
9/Modules. Some providers don't register correctly. See JDK-8291888
* The fall back mode used a minimal security config setting and is not actively 
maintained. I'd argue that it's dangerous - all the JDK protection aids added 
via the java.security file aren't available if the default one is missing. One 
is still free to override the property file, as before. We just ensure that 
$JDK/conf/security/java.security exists. It's a bad JDK install if such a file 
doesn't exist. This might only make JDK 20 - perhaps we review feedback from 
that release and decide if we want to proceed with backports then.

regards,
Sean.

-

PR: https://git.openjdk.org/jdk/pull/9747

Re: PKCS8 with PBES2 protection supported by EncryptedPrivateKeyInfo?

2022-08-08 Thread Anthony Scarpino 

Hi,

I did this not long ago. You are close, but you do not need to do the 
Cipher.init() separately, it is done as part of 
EncryptedPrivateKeyInfo.getKeySpec().  It also reads the encoding for 
the count and iv.


The below will decrypt the DER-encoded 'data' into a 
PKCS8EncryptedKeySpec for you to use.


EncryptedPrivateKeyInfo epki = new EncryptedPrivateKeyInfo(data);
PBEKeySpec pks = new PBEKeySpec(password);
SecretKeyFactory skf = SecretKeyFactory.getInstance(epki.getAlgName());
SecretKey sk = skf.generateSecret(pks);
PKCS8EncodedKeySpec keySpec = epki.getKeySpec(sk);

Tony

On 8/7/22 12:18 PM, Bernd wrote:

Hello,

there is a longstanding issue in the PostgreSQL JDBC driver which reads 
secret keys in PKCS#8 format, but does not support the newer PKCS#5 2.0 
(PBES2) modes (-v1 works). The (naive) code is here:


pgjdbc/LazyKeyManager.java at 80d4ed34c99d51dd8b06df00baad0265fd620fec · 
pgjdbc/pgjdbc · GitHub 



I was playing around with EncryptedPrivateKeyInfo in order to see whats 
needed to get it working with PBES2 encryption, but it did not work with 
quite a few tries.


I wonder is the Code behind PBES2Parameters in JCE supposed to work 
and interoperable with openssl PKCS#8? If I understand the api correctly 
the following code should work, but it results in a padding error:


     public static void main(String[] args) throws Throwable
     {
         byte[] b = readFileFully("test-key.p8"); // DER Format
         EncryptedPrivateKeyInfo ePKInfo = new EncryptedPrivateKeyInfo(b);
         System.out.println("en " + ePKInfo + " alg=" + 
ePKInfo.getAlgName()
                                        + " p=" + 
ePKInfo.getAlgParameters().toString());

         AlgorithmParameters algParams = ePKInfo.getAlgParameters();
         //PBEParameterSpec pbep = 
algParams.getParameterSpec(PBEParameterSpec.class);

         //System.out.println("pbep " + pbep);
         //AlgorithmParameterSpec cp = pbep.getParameterSpec();
         //System.out.println("cp = " + cp ); // IvParameters

         PBEKeySpec pbeKeySpec = new PBEKeySpec("test".toCharArray());
         //PBEKeySpec pbeKeySpec = new PBEKeySpec("test".toCharArray(),
         //  
  pbep.getSalt(), pbep.getIterationCount(), 256);
         SecretKeyFactory skFac = 
SecretKeyFactory.getInstance(algParams.toString());

         Key pbeKey = skFac.generateSecret(pbeKeySpec);

         Cipher cipher = Cipher.getInstance(algParams.toString());
         cipher.init(Cipher.DECRYPT_MODE, pbeKey, algParams);

         // Decrypt the encrypted private key
         // when passing pbeKey here instead of cipher the algParams are 
lost
         KeySpec pkcs8KeySpec = ePKInfo.getKeySpec(cipher); // L61 --> 
throws


         // not reached
         KeyFactory kf = KeyFactory.getInstance("RSA");
         PrivateKey key = kf.generatePrivate(pkcs8KeySpec);
         System.out.println("k=" + key);
}

The test object created with openssl:
 > openssl req -x509 -newkey rsa:2048 -keyout test-key.pem -out 
test-cert.pem -sha256 -days 365 -nodes
 > openssl pkcs8 -topk8 -in test-key.pem -out test-key.p8 -outform der  
# password "test"

 > openssl asn1parse -in test-key.p8 -inform DER
     0:d=0  hl=4 l=1325 cons: SEQUENCE
     4:d=1  hl=2 l=  87 cons: SEQUENCE
     6:d=2  hl=2 l=   9 prim: OBJECT            :PBES2
    17:d=2  hl=2 l=  74 cons: SEQUENCE
    19:d=3  hl=2 l=  41 cons: SEQUENCE
    21:d=4  hl=2 l=   9 prim: OBJECT            :PBKDF2
    32:d=4  hl=2 l=  28 cons: SEQUENCE
    34:d=5  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:BDCF0B11DB8BAFAB
    44:d=5  hl=2 l=   2 prim: INTEGER           :0800
    48:d=5  hl=2 l=  12 cons: SEQUENCE
    50:d=6  hl=2 l=   8 prim: OBJECT            :hmacWithSHA256
    60:d=6  hl=2 l=   0 prim: NULL
    62:d=3  hl=2 l=  29 cons: SEQUENCE
    64:d=4  hl=2 l=   9 prim: OBJECT            :aes-256-cbc
    75:d=4  hl=2 l=  16 prim: OCTET STRING      [HEX 
DUMP]:E355E1C72C9F486DDBE2E1F58EE7B61E
    93:d=1  hl=4 l=1232 prim: OCTET STRING      [HEX 
DUMP]:E4D9C29E4789840093EE371AB6EACB3111920E636CCB924651125D97CBD5312156214AD173CF4159AEEDBB497900815FE3B24184846CA252A421784CAD121B59C93EE3427BEA7CF0E404FAD0F226A2D13B86BD4898455B0750FBA6C4FB5F0B66980BD586CFFCBB5FA2170A67917FD55F7AF0E03D03078E5191965F74C099E357F28B6DA969E3CF3D713ABBC35C20A513E8068822A1C9B67BAFB650FB4B8EB7755A9F1760CD0B82AEBFBCCA01F575C377CD5AA2732D42F10A43EEF46048650E492F9FE1FD56596DDAC70461BF3E60CEA97F7EA99741254D1C1452CF1081DD799EACC74C8C0E806104230AE91E560C8F458B7BB358F031726355E99D31938CF39EC40B76D963FC3D45A59C7BE14CC769E7E4DA8C9FC08F4BD1A4C4CC07141BA0D5A31F0319E32D48A12A2BA4ABA4979A68447AFA57B8A9F82D465B1E765169B1C339C88F9EC9934B0B1B58C5793991FB9990F44C9C7A816ABE97015ECFB408CBF906BABAF9C7F5D0F32673AA1D9D72A0C3738FC9C1909FB24A029A3928C583B2DE4CCF3247F7C89D97E8DEEF3E08796

Re: PKCS8 with PBES2 protection supported by EncryptedPrivateKeyInfo?

2022-08-08 Thread Anthony Scarpino 
Oops.. I think I suggested something that only works in my development 
repo with PBES2.


I ran you code and it worked on jdk-dev.  Other than setting -v2 on the 
'openssl pkcs8' cmdline,


en javax.crypto.EncryptedPrivateKeyInfo@46d56d67 
alg=PBEWithHmacSHA1AndAES_256 p=PBEWithHmacSHA1AndAES_256

k=SunRsaSign RSA private CRT key, 2048 bits
  params: null
  modulus: ...

Tony

On 8/8/22 5:12 PM, Anthony Scarpino wrote:

Hi,

I did this not long ago. You are close, but you do not need to do the 
Cipher.init() separately, it is done as part of 
EncryptedPrivateKeyInfo.getKeySpec().  It also reads the encoding for 
the count and iv.


The below will decrypt the DER-encoded 'data' into a 
PKCS8EncryptedKeySpec for you to use.


EncryptedPrivateKeyInfo epki = new EncryptedPrivateKeyInfo(data);
PBEKeySpec pks = new PBEKeySpec(password);
SecretKeyFactory skf = SecretKeyFactory.getInstance(epki.getAlgName());
SecretKey sk = skf.generateSecret(pks);
PKCS8EncodedKeySpec keySpec = epki.getKeySpec(sk);

Tony

On 8/7/22 12:18 PM, Bernd wrote:

Hello,

there is a longstanding issue in the PostgreSQL JDBC driver which 
reads secret keys in PKCS#8 format, but does not support the newer 
PKCS#5 2.0 (PBES2) modes (-v1 works). The (naive) code is here:


pgjdbc/LazyKeyManager.java at 80d4ed34c99d51dd8b06df00baad0265fd620fec 
· pgjdbc/pgjdbc · GitHub 



I was playing around with EncryptedPrivateKeyInfo in order to see 
whats needed to get it working with PBES2 encryption, but it did not 
work with quite a few tries.


I wonder is the Code behind PBES2Parameters in JCE supposed to work 
and interoperable with openssl PKCS#8? If I understand the api 
correctly the following code should work, but it results in a padding 
error:


     public static void main(String[] args) throws Throwable
     {
         byte[] b = readFileFully("test-key.p8"); // DER Format
         EncryptedPrivateKeyInfo ePKInfo = new 
EncryptedPrivateKeyInfo(b);
         System.out.println("en " + ePKInfo + " alg=" + 
ePKInfo.getAlgName()
                                        + " p=" + 
ePKInfo.getAlgParameters().toString());

         AlgorithmParameters algParams = ePKInfo.getAlgParameters();
         //PBEParameterSpec pbep = 
algParams.getParameterSpec(PBEParameterSpec.class);

         //System.out.println("pbep " + pbep);
         //AlgorithmParameterSpec cp = pbep.getParameterSpec();
         //System.out.println("cp = " + cp ); // IvParameters

         PBEKeySpec pbeKeySpec = new PBEKeySpec("test".toCharArray());
         //PBEKeySpec pbeKeySpec = new PBEKeySpec("test".toCharArray(),
         //   pbep.getSalt(), pbep.getIterationCount(), 256);
         SecretKeyFactory skFac = 
SecretKeyFactory.getInstance(algParams.toString());

         Key pbeKey = skFac.generateSecret(pbeKeySpec);

         Cipher cipher = Cipher.getInstance(algParams.toString());
         cipher.init(Cipher.DECRYPT_MODE, pbeKey, algParams);

         // Decrypt the encrypted private key
         // when passing pbeKey here instead of cipher the algParams 
are lost
         KeySpec pkcs8KeySpec = ePKInfo.getKeySpec(cipher); // L61 --> 
throws


         // not reached
         KeyFactory kf = KeyFactory.getInstance("RSA");
         PrivateKey key = kf.generatePrivate(pkcs8KeySpec);
         System.out.println("k=" + key);
}

The test object created with openssl:
 > openssl req -x509 -newkey rsa:2048 -keyout test-key.pem -out 
test-cert.pem -sha256 -days 365 -nodes
 > openssl pkcs8 -topk8 -in test-key.pem -out test-key.p8 -outform der 
# password "test"

 > openssl asn1parse -in test-key.p8 -inform DER
     0:d=0  hl=4 l=1325 cons: SEQUENCE
     4:d=1  hl=2 l=  87 cons: SEQUENCE
     6:d=2  hl=2 l=   9 prim: OBJECT            :PBES2
    17:d=2  hl=2 l=  74 cons: SEQUENCE
    19:d=3  hl=2 l=  41 cons: SEQUENCE
    21:d=4  hl=2 l=   9 prim: OBJECT            :PBKDF2
    32:d=4  hl=2 l=  28 cons: SEQUENCE
    34:d=5  hl=2 l=   8 prim: OCTET STRING      [HEX 
DUMP]:BDCF0B11DB8BAFAB

    44:d=5  hl=2 l=   2 prim: INTEGER           :0800
    48:d=5  hl=2 l=  12 cons: SEQUENCE
    50:d=6  hl=2 l=   8 prim: OBJECT            :hmacWithSHA256
    60:d=6  hl=2 l=   0 prim: NULL
    62:d=3  hl=2 l=  29 cons: SEQUENCE
    64:d=4  hl=2 l=   9 prim: OBJECT            :aes-256-cbc
    75:d=4  hl=2 l=  16 prim: OCTET STRING      [HEX 
DUMP]:E355E1C72C9F486DDBE2E1F58EE7B61E
    93:d=1  hl=4 l=1232 prim: OCTET STRING      [HEX 
DUMP]:E4D9C29E4789840093EE371AB6EACB3111920E636CCB924651125D97CBD5312156214AD173CF4159AEEDBB497900815FE3B24184846CA252A421784CAD121B59C93EE3427BEA7CF0E404FAD0F226A2D13B86BD4898455B0750FBA6C4FB5F0B66980BD586CFFCBB5FA2170A67917FD55F7AF0E03D03078E5191965F74C099E357F28B6DA969E3CF3D713ABBC35C20A513E8068822A1C9B67BAFB650FB4B8EB7755A9F1760CD0B82AEBFBCCA01F575C377CD5AA2732D42F10A43EEF46048650E492F9FE1FD56596DDAC70461BF3E60CEA97F7EA997