Re: RFR: 8274528: Add comment to explain an HKDF optimization in SSLSecretDerivation

[Jamil Nimeh]

On Thu, 30 Sep 2021 01:22:56 GMT, Bradford Wetmore  wrote:

> See comment, + a couple minor cleanups.

src/java.base/share/classes/sun/security/ssl/SSLSecretDerivation.java line 153:

> 151: private final byte[] label;
> 152: 
> 153: SecretSchedule(String label) {

Why are we opening the visibility on this enum?  As far as I can tell it is 
only ever referenced within the SSLSecretDerivation class and could remain 
private if it hasn't been causing any problems up to now.

-

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

RFR: 8274528: Add comment to explain an HKDF optimization in SSLSecretDerivation

[Bradford Wetmore]

See comment, + a couple minor cleanups.

-

Commit messages:
 - Minor cleanup.

Changes: https://git.openjdk.java.net/jdk/pull/5765/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5765=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274528
  Stats: 13 lines in 1 file changed: 10 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5765/head:pull/5765

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

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

[Sergey Bylokhov]

On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov  wrote:

> At the time Java supported applets and webstart, a special mechanism for 
> launching various applications in one JVM was used to reduce memory usage and 
> each application was isolated from each other.
> 
> This isolation was implemented via ThreadGroups where each application 
> created its own thread group and all data for the application was stored in 
> the context of its own group.
> 
> Some parts of the JDK used ThreadGroups directly, others used special classes 
> like sun.awt.AppContext.
> 
> Such sandboxing became useless since the plugin and webstart are no longer 
> supported and were removed in jdk11.
> 
> Note that this is just a first step for the overall cleanup, here is my plan:
> 1. Cleanup the usage of AppContext in the “java.util.logging.LogManager" 
> class in the java.base module.
> 2. Cleanup the usage of TheadGroup in the JavaSound
> 3. Cleanup the usage of TheadGroup in the JavaBeans
> 4. Cleanup the usage of AppContext in the Swing
> 5. Cleanup the usage of AppContext in the AWT
> 6. Delete the AppContext class.
> 
> The current PR is for the first step. So this is the request to delete the 
> usage of AppContext in the LogManager and related tests.
> 
> Tested by tier1/tier2/tier3 and jdk_desktop tests.

Does anybody have any other suggestions?

-

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

Re: Verification of OCSP Responses signed with RSASSA-PSS fails with Java 11 LTS

[Sean Mullan]

Thank you for reporting this issue. As far as I can tell, it looks like 
the JDK OCSP implementation has not yet been enhanced to support 
RSASSA-PSS signatures.


We will keep an eye out for the bug report you filed but I think it is 
still making its way through our system as I have not seen it yet.


--Sean

On 9/28/21 11:17 AM, can comert wrote:

Hello everyone,

I am trying to verify Certificate Revocation Status by using JDK and the 
preferred way is the OCSP request. I came across certificates provided 
by a certain Certificate Authority (Procilion) which I can not verify 
the Revocation Status by using the JDK (I tried with the latest 11 LTS 
and 16). Openssl on the other hand can verify the OCSP responses.


Here is the call for the openssl library:
openssl ocsp -CAfile ROOT.cer -issuer INTERMEDIATE.cer -cert 
APPLICATION.cer -text -url http://ocsp.spi-cloud.com/status/ 



which gives results such as:
APPLICATION.cer: good
  This Update: Sep 21 15:31:32 2021 GMT
  Next Update: Sep 21 16:31:32 2021 GMT
Response verify OK

With the Wireshark I can also read the OCSP Request and Response and 
Response contains status SUCCESSFUL.


Java runtime throws an exception with message "Parameters required for 
RSASSA-PSS signatures" during trying to verify the signature of the OCSP 
Response.


CA is using a separate certificate with Subject "OCSP Signer" to sign 
the OCSP Response. This certificate is delivered in the OCSP response 
and the signer certificate is signed by the same root as the issuer 
certificate of the certificate under test. Java seems to accept the 
signer certificate but fails to verify the signature.
Here is the debug output snaps from the Java Program I wrote to test the 
revocation check and executed with flag 
-Djava.security.auth.debug=certpath,ocsp:


start program
...
certpath: KeySizeConstraints.permits(): RSA
certpath: Responder's certificate includes the extension 
id-pkix-ocsp-nocheck.

certpath: OCSP response is signed by an Authorized Responder
...
certpath: RevocationChecker.check() java.security.SignatureException: 
Parameters required for RSASSA-PSS signatures

certpath: RevocationChecker.check() preparing to failover
...CRL check also fails due to some other reasons.
Parameters required for RSASSA-PSS signatures
end program

I have also created a Bug Report for the Open JDK with internal review 
id:9071579 since I could not find any related issues on the Bug database.


Root certificate is: procilonGROUPCustomerRootCA02.cer
Intermediate certificate is: procilonGROUPCustomerCAEDIFACT02.cer
Both available under https://pki.spi-cloud.com/issuer 
 (packed as p7b)


I can provide the example certificates and the Java program which is 
basically calling CertPathValidator.validate method to validate the 
revocation status if you need to reproduce the issue.


Kind Regards,
Can Cömert

RFR: 8274524: SSLSocket.close() hangs if it is called during the ssl handshake

[Alexey Bakhtin]

Please review the patch for JDK-8274524

The fix just adds locks around InputStream read and skip operations to prevent 
concurrent read from socket.
sun/security/ssl jtreg tests passed
api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed

-

Commit messages:
 - 8274524: SSLSocket.close() hangs if it is called during the ssl handshake

Changes: https://git.openjdk.java.net/jdk/pull/5760/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5760=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274524
  Stats: 26 lines in 1 file changed: 17 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5760.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5760/head:pull/5760

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

Re: RFR: 8274393: Suppress more warnings on non-serializable non-transient instance fields in security libs [v2]

[Joe Darcy]

> Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial 
> checking are out for review (#5709) and various security libraries would need 
> some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in 
> serializable types are not declared with a type statically known to be 
> serializable. That isn't necessarily a correctness issues, but it does merit 
> further scrutiny.

Joe Darcy 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 three additional commits since the 
last revision:

 - Add explanatory comments for SuppressWarnings annotations.
 - Merge branch 'master' into JDK-8274393
 - 8274393: Suppress more warnings on non-serializable non-transient instance 
fields in security libs

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5720/files
  - new: https://git.openjdk.java.net/jdk/pull/5720/files/5d95dea7..08718270

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

  Stats: 4821 lines in 185 files changed: 3414 ins; 967 del; 440 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5720.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5720/head:pull/5720

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

Re: RFR: 8274393: Suppress more warnings on non-serializable non-transient instance fields in security libs [v2]

[Joe Darcy]

On Wed, 29 Sep 2021 18:13:14 GMT, Joe Darcy  wrote:

>> Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial 
>> checking are out for review (#5709) and various security libraries would 
>> need some changes to pass under the expanded checks.
>> 
>> The changes are to suppress warnings where non-transient fields in 
>> serializable types are not declared with a type statically known to be 
>> serializable. That isn't necessarily a correctness issues, but it does merit 
>> further scrutiny.
>
> Joe Darcy 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 three additional commits since 
> the last revision:
> 
>  - Add explanatory comments for SuppressWarnings annotations.
>  - Merge branch 'master' into JDK-8274393
>  - 8274393: Suppress more warnings on non-serializable non-transient instance 
> fields in security libs

I added explanatory comments alongside the SuppressWarnings annotations to 
explain their presence.

-

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

Integrated: 8274050: Unnecessary Vector usage in javax.crypto

[Andrey Turbanov]

On Thu, 26 Aug 2021 06:19:49 GMT, Andrey Turbanov 
 wrote:

> In [JDK-8268873](https://bugs.openjdk.java.net/browse/JDK-8268873) I missed a 
> few places, where Vector could be replaced with ArrayList.
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to 
> use `ArrayList` if a thread-safe implementation is not needed.

This pull request has now been integrated.

Changeset: 79cebe2c
Author:Andrey Turbanov 
Committer: Valerie Peng 
URL:   
https://git.openjdk.java.net/jdk/commit/79cebe2c1b1e7f43377633b62c970528cac0a786
Stats: 31 lines in 2 files changed: 2 ins; 9 del; 20 mod

8274050: Unnecessary Vector usage in javax.crypto

Reviewed-by: valeriep

-

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

Re: RFR: 8274330: Incorrect encoding of the DistributionPointName object in IssuingDistributionPointExtension

[Anthony Scarpino]

On Sun, 26 Sep 2021 13:27:47 GMT, Weijun Wang  wrote:

> `DistributionPointName` in `IssuingDistributionPointExtension` is a CHOICE 
> and should not be encoded as IMPLICIT.
> 
> Please note that the parsing side (at 
> https://github.com/openjdk/jdk/blob/a9db70418f7bc6b2f95afdd36a36024f865c04bf/src/java.base/share/classes/sun/security/x509/IssuingDistributionPointExtension.java#L195)
>  is aware of this and has not called `resetTag()`.

looks find to me

-

Marked as reviewed by ascarpino (Reviewer).

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

Integrated: 8274330: Incorrect encoding of the DistributionPointName object in IssuingDistributionPointExtension

[Weijun Wang]

On Sun, 26 Sep 2021 13:27:47 GMT, Weijun Wang  wrote:

> `DistributionPointName` in `IssuingDistributionPointExtension` is a CHOICE 
> and should not be encoded as IMPLICIT.
> 
> Please note that the parsing side (at 
> https://github.com/openjdk/jdk/blob/a9db70418f7bc6b2f95afdd36a36024f865c04bf/src/java.base/share/classes/sun/security/x509/IssuingDistributionPointExtension.java#L195)
>  is aware of this and has not called `resetTag()`.

This pull request has now been integrated.

Changeset: edd9d1c9
Author:Weijun Wang 
URL:   
https://git.openjdk.java.net/jdk/commit/edd9d1c97b7fb50e76abc05d298c9d55db39cc1b
Stats: 52 lines in 2 files changed: 50 ins; 0 del; 2 mod

8274330: Incorrect encoding of the DistributionPointName object in 
IssuingDistributionPointExtension

Reviewed-by: ascarpino

-

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

RFR: 8273026: Slow LoginContext.login() on multi threading application

[Larry-N]

This fix adds a cache of service provider classes to LoginContext (in 
particular, it's a cache of LoginModules classes). The approach helps to 
increase the performance of the LoginContext.login() method significantly, 
especially in a multi-threading environment. Service Loader is used for polling 
on Service Provider classes, without instantiating LoginModules object if 
Service Provider name doesn't match record in .config file. The set of service 
providers is cached for each Context Loader separately.
This code passed successfully tier1 and tier2 tests on mac os.

-

Commit messages:
 - 8273026: Slow LoginContext.login() on multi threading application

Changes: https://git.openjdk.java.net/jdk/pull/5748/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5748=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273026
  Stats: 35 lines in 1 file changed: 23 ins; 3 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5748.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5748/head:pull/5748

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