RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop 10

[Alisen Chung]

redo of 8280400

-

Commit messages:
 - 8280400: JDK 19 L10n resource files update - msgdrop 10

Changes: https://git.openjdk.java.net/jdk/pull/8026/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8026=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283805
  Stats: 11316 lines in 139 files changed: 9124 ins; 1252 del; 940 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8026/head:pull/8026

PR: https://git.openjdk.java.net/jdk/pull/8026

Re: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v8]

[Valerie Peng]

> Can someone help review this update to the PSSParameterSpec class regarding 
> the constructor with int argument and the DEFAULT static field? Just added 
> @Deprecate javadoc tag and caution about their usage as suggested in the bug 
> record.
> 
> A CSR will be filed once the wording changes are reviewed.
> 
> Thanks,
> Valerie

Valerie Peng has updated the pull request incrementally with one additional 
commit since the last revision:

  Changed the PSSParameterSpec javadoc link to show arguments.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7913/files
  - new: https://git.openjdk.java.net/jdk/pull/7913/files/db4dddb1..26e31a64

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7913=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7913=06-07

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7913.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7913/head:pull/7913

PR: https://git.openjdk.java.net/jdk/pull/7913

Re: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v7]

[Valerie Peng]

On Tue, 29 Mar 2022 14:08:26 GMT, Sean Mullan  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Update again with Sean's wording suggestion.
>
> src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 98:
> 
>> 96: 
>> 97: /**
>> 98:  * The PSS parameter set with all default values
> 
> Nit - add period at end of sentence.

Sure.

> src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 106:
> 
>> 104:  * a new {@code PSSParameterSpec} with the desired 
>> parameter values
>> 105:  * using
>> 106:  * {@link #PSSParameterSpec(String, String, 
>> AlgorithmParameterSpec, int, int) PSSParameterSpec}.
> 
> I think it would be more clear to see the full signature of the ctor that you 
> are recommending be used instead, so I would change these 2 lines to:
> 
> `using the {@link #PSSParameterSpec(String, String, AlgorithmParameterSpec, 
> int, int)} constructor.`

Makes sense.

> src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 175:
> 
>> 173:  * standard for more details. Thus, it is recommended to 
>> explicitly
>> 174:  * specify all desired parameter values with
>> 175:  * {@link #PSSParameterSpec(String, String, 
>> AlgorithmParameterSpec, int, int) PSSParameterSpec}.
> 
> Same comment about seeing the full signature of the ctor as mentioned above.

Yes.

-

PR: https://git.openjdk.java.net/jdk/pull/7913

Re: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368 [v3]

[Bradford Wetmore]

> JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal 
> internal_error (80) and invalidate existing sessions (either completed or 
> under construction) as described in (RFC 4346/TLSv1.1+) if a connection was 
> closed without receiving a close_notify alert from the peer.  
> 
> This change introduces similar behavior to SSLEngine.
> 
> The unit test checks that closing the read(input) sides of the 
> SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their 
> respective sessions.
> 
> Tier1/2 mach5 tests have been successfully run.

Bradford Wetmore has updated the pull request with a new target base due to a 
merge or a rebase. The incremental webrev excludes the unrelated changes 
brought in by the merge/rebase. The pull request contains 13 additional commits 
since the last revision:

 - Merge branch 'master' into JDK-8273553
 - Code review comment: enclose conContext.closeInbound() in a try/finally 
block.
 - Merge branch 'master' into JDK-8273553
 - Merge branch 'master' into JDK-8273553
 - Added SSLSocket bugid since we're actually checking both sides now.
 - I/O Issues, rewrite the I/O section so that early Socket closes don't kill 
our server-side reads.
 - Merge branch 'master' into JDK-8273553
 - Merge branch 'master' into JDK-8273553
 - Merge
 - Minor test tweaks.
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/38460839...08d22aee

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7796/files
  - new: https://git.openjdk.java.net/jdk/pull/7796/files/b2f64d92..08d22aee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7796=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7796=01-02

  Stats: 65793 lines in 503 files changed: 62965 ins; 887 del; 1941 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7796.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7796/head:pull/7796

PR: https://git.openjdk.java.net/jdk/pull/7796

Re: RFR: 8281717: Cover logout method for several LoginModule [v3]

[Rajan Halade]

On Tue, 29 Mar 2022 06:24:16 GMT, Sibabrata Sahoo  wrote:

>> Added coverage to logout method.
>
> Sibabrata Sahoo has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Update AllPlatforms.java
>   
>   Updated exception handling to ignore the case where the running platform 
> doesn't match the test case. In that case required native library loading 
> will fail.

Marked as reviewed by rhalade (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7940

Re: RFR: 8281717: Cover logout method for several LoginModule [v3]

[Rajan Halade]

On Mon, 28 Mar 2022 06:58:29 GMT, Sibabrata Sahoo  wrote:

>> test/jdk/com/sun/security/auth/module/AllPlatforms.java line 45:
>> 
>>> 43: UNIX_MODULE, "optional",
>>> 44: NT_MODULE, "optional");
>>> 45: login(OS.replaceAll("[^a-zA-Z0-9]", ""), 
>>> getPlatformLoginModule(), "required");
>> 
>> I think test should still be run on all platforms even though login would 
>> fail. On other platforms than the test being run on, test shouldn't fail 
>> with "UnsatisfiedLinkError" as per JDK-8039951.
>
> Now it will run in all platform other than the running one and the expected 
> failure is LoginException. So any other types of Exception will be treated as 
> failure including UnsatisfiedLinkError.

thanks for addressing it!

-

PR: https://git.openjdk.java.net/jdk/pull/7940

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v13]

[Maurizio Cimadamore]

> This PR contains the API and implementation changes for JEP-424 [1]. A more 
> detailed description of such changes, to avoid repetitions during the review 
> process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one 
additional commit since the last revision:

  Switch to daemon threads for async upcalls

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/55aee872..43dc6be3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7888=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7888=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v12]

[Maurizio Cimadamore]

> This PR contains the API and implementation changes for JEP-424 [1]. A more 
> detailed description of such changes, to avoid repetitions during the review 
> process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request with a new target base due to 
a merge or a rebase. The incremental webrev excludes the unrelated changes 
brought in by the merge/rebase. The pull request contains 27 additional commits 
since the last revision:

 - Use thread local storage to optimize attach of async threads
 - Drop support for Constable from MemoryLayout/FunctionDescriptor
 - Merge branch 'master' into foreign-preview
 - Revert changes to RunTests.gmk
 - Add --enable-preview to micro benchmark java options
 - Address more review comments
 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Jorn Vernee 
 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Jorn Vernee 
 - Address review comments
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Jorn Vernee 
 - ... and 17 more: https://git.openjdk.java.net/jdk/compare/02333d66...55aee872

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/504b564a..55aee872

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7888=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7888=10-11

  Stats: 99257 lines in 1550 files changed: 79659 ins; 15544 del; 4054 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA

[xueleifan(XueleiFan)]

> On Mar 29, 2022, at 10:18 AM, Anders Rundgren  
> wrote:
> 
> On 2022-03-28 21:57, xueleifan(XueleiFan) wrote:
>> Thank you for the information and discussion, Anders, Bernd and Mike.  I had 
>> a better understand of JOSE/COSE and the problems.
> 
> Thanx Xuelei!
> May I ask a highly related question?
> 
> Assume there is a new cool XYZ algorithm family supported by a third party 
> JCE provider.
> What would be needed in order to make XYZ public keys in X.509 certificates 
> automatically decode into an associated XYXPublicKey (also supplied by the 
> third party)?
> 
It depends.  For the JDK X509 certificate implementation, KeyFactory are used  
to generated the public key from X509 encoded key specification (public key DER 
value in the cert).

X509EncodedKeySpec x509KeySpec
= new X509EncodedKeySpec(x509EncodedKeyStream.toByteArray());
KeyFactory keyFac = KeyFactory.getInstance(algid.getName());
keyFac.generatePublic(x509KeySpec);

The “algid” is also recorded in the X.509 certificate.  So, a third party 
provider may be able to get it supported by support XYZ algorithm in its 
KeyFactory implementation.

KeyFactory keyFac = KeyFactory.getInstance(“XYZ”/“XYZ-OID”);

But it really depends on the X.509 provider implementation behaviors.  I know 
there are cases that X.509 provider was updated, or forked, here and there in 
order to support new algorithms, unfortunately.

Best,
Xuelei


> I tried to follow the JDK X.509 decoder source but I failed :(
> 
> Regards,
> Anders
> 
>> For the crypto implementation, for example Ed25519 in the SunEC provider, I 
>> would prefer to keep the footprint in OpenJDK as minimal as possible.  For 
>> example, the Ed25519 key factory could accept XECPublicKeySpec and 
>> XECPrivateKeySpec only, and support no more encoding format (currently, 
>> X509EncodedKeySpec and PKCS8EncodedKeySpec are also supported by the SunEC 
>> provider).  Except COSE/JOSE/PEM, there may be a few other known encoding 
>> formats, and more in the future.  It would be challenging to track many 
>> encoding formats in specific protocols and their development in OpenJDK.  If 
>> a provider does not support protocol specific format, the application rely 
>> on it could fail, which is not good for application developers.  And thus 
>> the purpose to support more encoding format in one provider could be 
>> frangible.
>> There could be third party's encoding format specific provider, for example 
>> a KeyFactory provider accepting JOSE/COSE format and converting between 
>> XECPublicKeySpec/XECPrivateKeySpec and protocol specific formats.  The 
>> factory might belong more to the protocol specific library, rather than the 
>> OpenJDK reference implementation. Unfortunately, the current 
>> KeyFactory.getInstance(“ Ed25519”) design cannot identify the encoding 
>> formats, and thus may just return a provider that does not support the 
>> expected encoding format.  It might be a workaround to use different 
>> algorithm name, like “JOSE/Ed25519”.
>> Alternatively, the JOSE/COSE could transfer the encoded stream to 
>> XECPublicKeySpec and XECPrivateKeySpec, without using KeyFactory.  It may be 
>> transparent to application developers if the transferring is wrapped in the 
>> protocol specific lib.
>> Just my $.02.
>> Xuelei
>>> On Mar 28, 2022, at 2:30 AM, Bernd Eckenfels >> > wrote:
>>> 
>>> Hello,
>>> 
>>> I think both might be too protocol specific to include it in JCE, but a 
>>> library for JWK would fit into JWT support in Jakarta EE.
>>> 
>>>  For COSE the key descriptors are very simple (no certificates), not sure 
>>> if anything besides a cose library is really needed. (That library would 
>>> benefit from a curve registry, but since cose uses its own code values for 
>>> the curve access to the CurveDB would not help I think).
>>> 
>>> CBOR is not QR specific, it’s specific for the Covid Vaccination 
>>> Certificate framework (due to the QR code size restriction it can’t use 
>>> JSON).
>>> 
>>> Gruss
>>> Bernd
>>> -- 
>>> http://bernd.eckenfels.net 
>>> 

Re: "Pluggable" key serialization in JCE/JCA

[Anders Rundgren]

On 2022-03-28 21:57, xueleifan(XueleiFan) wrote:

Thank you for the information and discussion, Anders, Bernd and Mike.  I had a 
better understand of JOSE/COSE and the problems.


Thanx Xuelei!
May I ask a highly related question?

Assume there is a new cool XYZ algorithm family supported by a third party JCE 
provider.
What would be needed in order to make XYZ public keys in X.509 certificates 
automatically decode into an associated XYXPublicKey (also supplied by the 
third party)?

I tried to follow the JDK X.509 decoder source but I failed :(

Regards,
Anders



For the crypto implementation, for example Ed25519 in the SunEC provider, I 
would prefer to keep the footprint in OpenJDK as minimal as possible.  For 
example, the Ed25519 key factory could accept XECPublicKeySpec and 
XECPrivateKeySpec only, and support no more encoding format (currently, 
X509EncodedKeySpec and PKCS8EncodedKeySpec are also supported by the SunEC 
provider).  Except COSE/JOSE/PEM, there may be a few other known encoding 
formats, and more in the future.  It would be challenging to track many 
encoding formats in specific protocols and their development in OpenJDK.  If a 
provider does not support protocol specific format, the application rely on it 
could fail, which is not good for application developers.  And thus the purpose 
to support more encoding format in one provider could be frangible.

There could be third party's encoding format specific provider, for example a 
KeyFactory provider accepting JOSE/COSE format and converting between 
XECPublicKeySpec/XECPrivateKeySpec and protocol specific formats.  The factory 
might belong more to the protocol specific library, rather than the OpenJDK 
reference implementation. Unfortunately, the current KeyFactory.getInstance(“ 
Ed25519”) design cannot identify the encoding formats, and thus may just return 
a provider that does not support the expected encoding format.  It might be a 
workaround to use different algorithm name, like “JOSE/Ed25519”.

Alternatively, the JOSE/COSE could transfer the encoded stream to 
XECPublicKeySpec and XECPrivateKeySpec, without using KeyFactory.  It may be 
transparent to application developers if the transferring is wrapped in the 
protocol specific lib.

Just my $.02.

Xuelei


On Mar 28, 2022, at 2:30 AM, Bernd Eckenfels mailto:e...@zusammenkunft.net>> wrote:

Hello,

I think both might be too protocol specific to include it in JCE, but a library 
for JWK would fit into JWT support in Jakarta EE.

 For COSE the key descriptors are very simple (no certificates), not sure if 
anything besides a cose library is really needed. (That library would benefit 
from a curve registry, but since cose uses its own code values for the curve 
access to the CurveDB would not help I think).

CBOR is not QR specific, it’s specific for the Covid Vaccination Certificate 
framework (due to the QR code size restriction it can’t use JSON).

Gruss
Bernd
--
http://bernd.eckenfels.net 
--
*Von:* Anthony Scarpino mailto:anthony.scarp...@oracle.com>>
*Gesendet:* Monday, March 28, 2022 6:31:29 AM
*An:* Anders Rundgren mailto:anders.rundgren@gmail.com>>
*Cc:* Bernd Eckenfels mailto:e...@zusammenkunft.net>>; 
security-dev@openjdk.java.net  mailto:security-dev@openjdk.java.net>>
*Betreff:* Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA
Thanks for all the info. We don’t have experience with JOSE or COSE, I think we 
need to digest some of this data before making a future step

Not knowing this technology until you brought it up a few days ago, a few 
questions i have are how is this used and how common?  Would I see this used 
for more secure sites like banks or shopping through the browser or it more 
common sites. Is it only browser-based or are their other used cases?  Bernd 
mentioned QR codes, is COSE used inside the QR code or the authentication for 
the user to get to their QR code?

Thanks

Tony

> On Mar 26, 

Re: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v7]

[Sean Mullan]

On Mon, 28 Mar 2022 22:18:20 GMT, Valerie Peng  wrote:

>> Can someone help review this update to the PSSParameterSpec class regarding 
>> the constructor with int argument and the DEFAULT static field? Just added 
>> @Deprecate javadoc tag and caution about their usage as suggested in the bug 
>> record.
>> 
>> A CSR will be filed once the wording changes are reviewed.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Update again with Sean's wording suggestion.

src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 98:

> 96: 
> 97: /**
> 98:  * The PSS parameter set with all default values

Nit - add period at end of sentence.

src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 106:

> 104:  * a new {@code PSSParameterSpec} with the desired parameter 
> values
> 105:  * using
> 106:  * {@link #PSSParameterSpec(String, String, 
> AlgorithmParameterSpec, int, int) PSSParameterSpec}.

I think it would be more clear to see the full signature of the ctor that you 
are recommending be used instead, so I would change these 2 lines to:

`using the {@link #PSSParameterSpec(String, String, AlgorithmParameterSpec, 
int, int)} constructor.`

src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 175:

> 173:  * standard for more details. Thus, it is recommended to 
> explicitly
> 174:  * specify all desired parameter values with
> 175:  * {@link #PSSParameterSpec(String, String, 
> AlgorithmParameterSpec, int, int) PSSParameterSpec}.

Same comment about seeing the full signature of the ctor as mentioned above.

-

PR: https://git.openjdk.java.net/jdk/pull/7913

Re: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3]

[Сергей Цыпанов]

On Sat, 26 Mar 2022 16:35:14 GMT, liach  wrote:

>> Сергей Цыпанов has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   8282662: Revert dubious changes in MethodType
>
> Just curious, this issue asks to replace set constructions with `Set.of`, but 
> there is no such code changes in this pull request. Is there any set creation 
> patterns that aren't detected by your ide cleanups, such as 
> `Collections.addAll(set, elements)` for creating hash set contents from array?

@liach I've found a couple of places:
- `AsynchronousFileChannel.open()`
- `FileChannel.open()`
- `DecimalStyle.getAvailableLocales()`
They all either rely on user input, i.e. might throw NPE or IAE for nulls or 
duplicates respectively, or return the set, which is currently modifiable 
`HashSet`. I think the possible win isn't worth the effort.

-

PR: https://git.openjdk.java.net/jdk/pull/7729

Re: RFR: 8281717: Cover logout method for several LoginModule [v3]

[Sibabrata Sahoo]

> Added coverage to logout method.

Sibabrata Sahoo has updated the pull request incrementally with one additional 
commit since the last revision:

  Update AllPlatforms.java
  
  Updated exception handling to ignore the case where the running platform 
doesn't match the test case. In that case required native library loading will 
fail.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7940/files
  - new: https://git.openjdk.java.net/jdk/pull/7940/files/13a999b0..b7e3bc04

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7940=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7940=01-02

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7940.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7940/head:pull/7940

PR: https://git.openjdk.java.net/jdk/pull/7940