Re: RFR: 8267721: Enable sun/security/pkcs11 tests for Amazon Linux 2 AArch64
This looks fine (and safe) to me. There are probably other Linux distros where
the NSS libraries are in /usr/lib64. Perhaps RHEL? "rpm -E %{rhel}" on AL2
produces "7", so there seems to be some RHEL DNA in AL2.
Thanks,
Paul
-Original Message-
From: security-dev on behalf of Evgeny
Astigeevich
Date: Wednesday, May 26, 2021 at 7:21 AM
To: "security-dev@openjdk.java.net"
Subject: RFR: 8267721: Enable sun/security/pkcs11 tests for Amazon Linux 2
AArch64
Tests sun/security/pkcs11 are skipped on AArch64 Linux when they cannot find
NSS libraries in one of the directories {'/usr/lib/aarch64-linux-gnu/',
'/usr/lib/aarch64-linux-gnu/nss/'}. On Amazon Linux 2 the libraries are in
/usr/lib64.
This patch adds '/usr/lib64' to the search list of directories.
Test:
- Before the patch
$ make run-test TEST=sun/security/pkcs11
$ cd build
$ find . -name '*.jtr' -exec grep 'find NSS' {} ; | wc -l
129
- After the patch
$ make run-test TEST=sun/security/pkcs11
$ cd build
$ find . -name '*.jtr' -exec grep 'find NSS' {} ; | wc -l
0
-
Commit messages:
- 8267721: Enable sun/security/pkcs11 tests for Amazon Linux 2 AArch64
Changes: https://git.openjdk.java.net/jdk/pull/4207/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4207&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8267721
Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
Patch: https://git.openjdk.java.net/jdk/pull/4207.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/4207/head:pull/4207
PR: https://git.openjdk.java.net/jdk/pull/4207
Re: [11u] RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms
There’s an extra blank line inserted at the end of java.security. Otherwise lgtm. I’m fine with using KnownOIDs.java from tip. One might object that now it’s in a different location and must be kept sync’ed with tip, but I don’t agree because the backported version must be updated only when a test that needs the update is backported, and if that’s needed it’ll be obvious what to do. Thanks, Paul From: security-dev on behalf of "Doerr, Martin" Date: Friday, April 30, 2021 at 9:35 AM To: "jdk-updates-...@openjdk.java.net" , security-dev Cc: "Langer, Christoph" Subject: [11u] RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms Hi, JDK-8153005 is backported to 11.0.12-oracle. I'd like to backport it for parity. It doesn't apply cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8153005 CSR covering 11u: https://bugs.openjdk.java.net/browse/JDK-8228481 Original change: https://github.com/openjdk/jdk/commit/f77a6585 11u rejected hunks: http://cr.openjdk.java.net/~mdoerr/8153005_PKCS12_11u/8153005_PKCS12_rej.txt Resolution: - Regular code is trivial to resolve, but the tests are tricky and the hunks were mostly integrated manually. - Introduce test/lib/jdk/test/lib/KnownOIDs.java as copy from jdk head src/java.base/share/classes/sun/security/util/KnownOIDs.java with last change from Oct 2020. Put into package jdk.test.lib and using System.out as debug output stream. This should make future backports easier, too. - DerUtils.java: ObjectIdentifier interface is diffent in 11u (different constructors). - Hunks in GenerateAll.java were skipped because the affected code is not in 11u (JDK-8242068). 11u backport: http://cr.openjdk.java.net/~mdoerr/8153005_PKCS12_11u/webrev.00/ Please review. Best regards, Martin
RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups
Ouch, missed that. Good to go.
Thanks,
Paul
-Original Message-
From: "Doerr, Martin"
Date: Thursday, April 8, 2021 at 2:53 AM
To: "Hohensee, Paul" , "Langer, Christoph"
, jdk-updates-dev ,
security-dev
Cc: "Lindenmaier, Goetz"
Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups
Hi Paul and Christoph,
thank you for the review and the approval.
I've added the blank line.
In addition, I've reviewed the whole change again and found a copy & paste bug
in my webrev.00:
SECT283_K1(0x0009, "sect283k1", true,
NamedGroupSpec.NAMED_GROUP_ECDHE,
ProtocolVersion.PROTOCOLS_TO_12,
-CurveDB.lookup("sect163k1")),
+CurveDB.lookup("sect283k1")),
This is the version I'm planning to push:
http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.01/
Tests have passed.
Best regards,
Martin
> -Original Message-
> From: Hohensee, Paul
> Sent: Donnerstag, 8. April 2021 01:01
> To: Langer, Christoph ; Doerr, Martin
> ; jdk-updates-dev d...@openjdk.java.net>; security-dev
> Cc: Lindenmaier, Goetz
> Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named
> groups
>
> Hmm, could have sworn...
>
> Thanks,
> Paul
>
> -Original Message-
> From: "Langer, Christoph"
> Date: Wednesday, April 7, 2021 at 3:16 PM
> To: "Hohensee, Paul" , "Doerr, Martin"
> , jdk-updates-dev d...@openjdk.java.net>, security-dev
> Cc: "Lindenmaier, Goetz"
> Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named
> groups
>
> Hi Paul,
>
> thanks for the review. The CSR that Martin mentions is the one that Oracle
> has filed for 11.0.12-oracle. so we can simply reuse it.
>
> As for 13, there exists a CSR as well: JDK-8256335
>
> Best regards
> Christoph
>
> > -Original Message-
> > From: Hohensee, Paul
> > Sent: Mittwoch, 7. April 2021 23:42
> > To: Doerr, Martin ; jdk-updates-dev updates-
> > d...@openjdk.java.net>; security-dev
> > Cc: Lindenmaier, Goetz ; Langer, Christoph
> >
> > Subject: Re: [11u] RFR: 8226374: Restrict TLS signature schemes and named
> > groups
> >
> > The backport looks fine, except there's a missing blank line after
> FFDHE_2048
> > in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be
> one
> > for the 13u backport: perhaps Yan will add one after the fact). I'm not a
> > security person, so it would be great if someone who is reviews the CSR to
> > see if there are any 11u-specific issues with it.
> >
> > Thanks,
> > Paul
> >
> > -Original Message-
> > From: jdk-updates-dev on
> > behalf of "Doerr, Martin"
> > Date: Wednesday, April 7, 2021 at 9:10 AM
> > To: jdk-updates-dev , security-dev
> >
> > Cc: "Lindenmaier, Goetz" , "Langer,
> > Christoph"
> > Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named
> > groups
> >
> > Hi,
> >
> > JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for
> > parity.
> > It doesn't apply cleanly. I've taken the 13u backport as source because it
> > resolves the wrong backport order with JDK-8242141.
> >
> > Bug:
> > https://bugs.openjdk.java.net/browse/JDK-8226374
> >
> > 11u CSR:
> > https://bugs.openjdk.java.net/browse/JDK-8264555
> >
> > Original change (JDK14):
> > https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644
> >
> > 13u backport:
> > https://github.com/openjdk/jdk13u-dev/commit/384445d2
> >
> > 11u rejected hunks (integrated manually):
> >
> http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt
> >
> > my new 11u backport:
> > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/
> >
> > Please review.
> >
> > Best regards,
> > Martin
> >
>
RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups
Hmm, could have sworn... Thanks, Paul -Original Message- From: "Langer, Christoph" Date: Wednesday, April 7, 2021 at 3:16 PM To: "Hohensee, Paul" , "Doerr, Martin" , jdk-updates-dev , security-dev Cc: "Lindenmaier, Goetz" Subject: RE: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Hi Paul, thanks for the review. The CSR that Martin mentions is the one that Oracle has filed for 11.0.12-oracle. so we can simply reuse it. As for 13, there exists a CSR as well: JDK-8256335 Best regards Christoph > -----Original Message- > From: Hohensee, Paul > Sent: Mittwoch, 7. April 2021 23:42 > To: Doerr, Martin ; jdk-updates-dev d...@openjdk.java.net>; security-dev > Cc: Lindenmaier, Goetz ; Langer, Christoph > > Subject: Re: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > The backport looks fine, except there's a missing blank line after FFDHE_2048 > in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be one > for the 13u backport: perhaps Yan will add one after the fact). I'm not a > security person, so it would be great if someone who is reviews the CSR to > see if there are any 11u-specific issues with it. > > Thanks, > Paul > > -Original Message- > From: jdk-updates-dev on > behalf of "Doerr, Martin" > Date: Wednesday, April 7, 2021 at 9:10 AM > To: jdk-updates-dev , security-dev > > Cc: "Lindenmaier, Goetz" , "Langer, > Christoph" > Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named > groups > > Hi, > > JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for > parity. > It doesn't apply cleanly. I've taken the 13u backport as source because it > resolves the wrong backport order with JDK-8242141. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8226374 > > 11u CSR: > https://bugs.openjdk.java.net/browse/JDK-8264555 > > Original change (JDK14): > https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 > > 13u backport: > https://github.com/openjdk/jdk13u-dev/commit/384445d2 > > 11u rejected hunks (integrated manually): > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt > > my new 11u backport: > http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ > > Please review. > > Best regards, > Martin >
Re: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups
The backport looks fine, except there's a missing blank line after FFDHE_2048 in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be one for the 13u backport: perhaps Yan will add one after the fact). I'm not a security person, so it would be great if someone who is reviews the CSR to see if there are any 11u-specific issues with it. Thanks, Paul -Original Message- From: jdk-updates-dev on behalf of "Doerr, Martin" Date: Wednesday, April 7, 2021 at 9:10 AM To: jdk-updates-dev , security-dev Cc: "Lindenmaier, Goetz" , "Langer, Christoph" Subject: [11u] RFR: 8226374: Restrict TLS signature schemes and named groups Hi, JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for parity. It doesn't apply cleanly. I've taken the 13u backport as source because it resolves the wrong backport order with JDK-8242141. Bug: https://bugs.openjdk.java.net/browse/JDK-8226374 11u CSR: https://bugs.openjdk.java.net/browse/JDK-8264555 Original change (JDK14): https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 13u backport: https://github.com/openjdk/jdk13u-dev/commit/384445d2 11u rejected hunks (integrated manually): http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/8226374_TLS_rej.txt my new 11u backport: http://cr.openjdk.java.net/~mdoerr/8226374_TLS_11u/webrev.00/ Please review. Best regards, Martin
Re: [11u] RFR 8259886: Improve SSL session cache performance and scalability
Pushed. In the future, it'd be great if you used "git hg-export" (one of the Skara tools) to generate the base changeset, because it includes the commit metadata we want to preserve in the 11u hg repo. Thanks, Paul -Original Message- From: security-dev on behalf of "Hohensee, Paul" Date: Wednesday, March 17, 2021 at 1:01 PM To: Daniel Jeliński Cc: "jdk-updates-...@openjdk.java.net" , "security-dev@openjdk.java.net" Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability Np, tagged. -Original Message- From: Daniel Jeliński Date: Tuesday, March 16, 2021 at 11:40 PM To: "Hohensee, Paul" Cc: "jdk-updates-...@openjdk.java.net" , "security-dev@openjdk.java.net" Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability Thanks again Paul. Could you sponsor the change? As far as I can tell, I'd need to add a fix request now, but I don't have access to issue tracker. Thanks, Daniel wt., 16 mar 2021 o 18:59 Hohensee, Paul napisał(a): > > Looks good! :) > > -Original Message- > From: Daniel Jeliński > Date: Tuesday, March 16, 2021 at 9:49 AM > To: "Hohensee, Paul" > Cc: "jdk-updates-...@openjdk.java.net" , > "security-dev@openjdk.java.net" > Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and > scalability > > Thanks Paul for your review and for the hint. > > Updated webrev: https://djelinski.github.io/8259886-11u/webrev2/index.html > > compared to original, changes to make/test/BuildMicrobenchmark.gmk > were dropped because file does not exist in jdk11 > compared to previous webrev, CacheBench was re-added. > > Testing: Linux x86_64 tier1 and tier2. > Thanks, > Daniel > > pon., 15 mar 2021 o 18:09 Hohensee, Paul napisał(a): > > > > The changes to Cache.java look fine, but please include CacheBench.java. > > I'd like to see 11u to stand on its own without reference to later > > releases, plus I believe the 11u maintainers prefer to backport as much of > > a patch as possible. > > > > Thanks, > > Paul > > > > -Original Message- > > From: security-dev on behalf of Daniel > > Jeliński > > Date: Tuesday, March 9, 2021 at 3:37 PM > > To: "jdk-updates-...@openjdk.java.net" > > Cc: "security-dev@openjdk.java.net" > > Subject: [11u] RFR 8259886: Improve SSL session cache performance and > > scalability > > > > Hi, > > Please review this 11u backport; this is the same patch as for head, > > except for microbenchmark makefile changes that did not apply because > > the file doesn't exist in 11u, and the actual microbenchmark, which > > would only add weight for no benefit. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 > > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html > > > > Testing: Linux x86_64 tier1 and tier2. > > > > Thanks, > > Daniel > > >
RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability
Np, tagged. -Original Message- From: Daniel Jeliński Date: Tuesday, March 16, 2021 at 11:40 PM To: "Hohensee, Paul" Cc: "jdk-updates-...@openjdk.java.net" , "security-dev@openjdk.java.net" Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability Thanks again Paul. Could you sponsor the change? As far as I can tell, I'd need to add a fix request now, but I don't have access to issue tracker. Thanks, Daniel wt., 16 mar 2021 o 18:59 Hohensee, Paul napisał(a): > > Looks good! :) > > -Original Message- > From: Daniel Jeliński > Date: Tuesday, March 16, 2021 at 9:49 AM > To: "Hohensee, Paul" > Cc: "jdk-updates-...@openjdk.java.net" , > "security-dev@openjdk.java.net" > Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and > scalability > > Thanks Paul for your review and for the hint. > > Updated webrev: https://djelinski.github.io/8259886-11u/webrev2/index.html > > compared to original, changes to make/test/BuildMicrobenchmark.gmk > were dropped because file does not exist in jdk11 > compared to previous webrev, CacheBench was re-added. > > Testing: Linux x86_64 tier1 and tier2. > Thanks, > Daniel > > pon., 15 mar 2021 o 18:09 Hohensee, Paul napisał(a): > > > > The changes to Cache.java look fine, but please include CacheBench.java. > > I'd like to see 11u to stand on its own without reference to later > > releases, plus I believe the 11u maintainers prefer to backport as much of > > a patch as possible. > > > > Thanks, > > Paul > > > > -Original Message- > > From: security-dev on behalf of Daniel > > Jeliński > > Date: Tuesday, March 9, 2021 at 3:37 PM > > To: "jdk-updates-...@openjdk.java.net" > > Cc: "security-dev@openjdk.java.net" > > Subject: [11u] RFR 8259886: Improve SSL session cache performance and > > scalability > > > > Hi, > > Please review this 11u backport; this is the same patch as for head, > > except for microbenchmark makefile changes that did not apply because > > the file doesn't exist in 11u, and the actual microbenchmark, which > > would only add weight for no benefit. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 > > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html > > > > Testing: Linux x86_64 tier1 and tier2. > > > > Thanks, > > Daniel > > >
RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability
Looks good! :) -Original Message- From: Daniel Jeliński Date: Tuesday, March 16, 2021 at 9:49 AM To: "Hohensee, Paul" Cc: "jdk-updates-...@openjdk.java.net" , "security-dev@openjdk.java.net" Subject: RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability Thanks Paul for your review and for the hint. Updated webrev: https://djelinski.github.io/8259886-11u/webrev2/index.html compared to original, changes to make/test/BuildMicrobenchmark.gmk were dropped because file does not exist in jdk11 compared to previous webrev, CacheBench was re-added. Testing: Linux x86_64 tier1 and tier2. Thanks, Daniel pon., 15 mar 2021 o 18:09 Hohensee, Paul napisał(a): > > The changes to Cache.java look fine, but please include CacheBench.java. I'd > like to see 11u to stand on its own without reference to later releases, plus > I believe the 11u maintainers prefer to backport as much of a patch as > possible. > > Thanks, > Paul > > -Original Message- > From: security-dev on behalf of Daniel > Jeliński > Date: Tuesday, March 9, 2021 at 3:37 PM > To: "jdk-updates-...@openjdk.java.net" > Cc: "security-dev@openjdk.java.net" > Subject: [11u] RFR 8259886: Improve SSL session cache performance and > scalability > > Hi, > Please review this 11u backport; this is the same patch as for head, > except for microbenchmark makefile changes that did not apply because > the file doesn't exist in 11u, and the actual microbenchmark, which > would only add weight for no benefit. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 > webrev: https://djelinski.github.io/8259886-11u/webrev/index.html > > Testing: Linux x86_64 tier1 and tier2. > > Thanks, > Daniel >
RE: [11u] RFR 8259886: Improve SSL session cache performance and scalability
The changes to Cache.java look fine, but please include CacheBench.java. I'd like to see 11u to stand on its own without reference to later releases, plus I believe the 11u maintainers prefer to backport as much of a patch as possible. Thanks, Paul -Original Message- From: security-dev on behalf of Daniel Jeliński Date: Tuesday, March 9, 2021 at 3:37 PM To: "jdk-updates-...@openjdk.java.net" Cc: "security-dev@openjdk.java.net" Subject: [11u] RFR 8259886: Improve SSL session cache performance and scalability Hi, Please review this 11u backport; this is the same patch as for head, except for microbenchmark makefile changes that did not apply because the file doesn't exist in 11u, and the actual microbenchmark, which would only add weight for no benefit. Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 webrev: https://djelinski.github.io/8259886-11u/webrev/index.html Testing: Linux x86_64 tier1 and tier2. Thanks, Daniel
Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class"
Thanks, Valerie. Pushed. From: Valerie Peng Organization: Oracle Corporation Date: Tuesday, September 24, 2019 at 9:42 PM To: "Hohensee, Paul" , "security-dev@openjdk.java.net" Subject: Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" Great, the update looks good. Thanks, Valerie On 9/24/2019 5:49 PM, Hohensee, Paul wrote: Thank you, Valerie. :) The patch needs a test, however, so I added a slightly modified version of Tianmin’s reproducer. New webrev at http://cr.openjdk.java.net/~phh/8231387/webrev.01/ The test fails without the fix. From: Valerie Peng <mailto:valerie.p...@oracle.com> Organization: Oracle Corporation Date: Tuesday, September 24, 2019 at 3:03 PM To: "Hohensee, Paul" <mailto:hohen...@amazon.com>, "security-dev@openjdk.java.net"<mailto:security-dev@openjdk.java.net> <mailto:security-dev@openjdk.java.net> Subject: Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" I am the security reviewer that you need. One should be enough. ;) Valerie On 9/24/2019 2:37 PM, Hohensee, Paul wrote: Yes, I’ll sponsor. Though it looks ok to me, I’m not a security expert, so do we need another security reviewer? From: security-dev <mailto:security-dev-boun...@openjdk.java.net> on behalf of Valerie Peng <mailto:valerie.p...@oracle.com> Organization: Oracle Corporation Date: Tuesday, September 24, 2019 at 2:17 PM To: "security-dev@openjdk.java.net"<mailto:security-dev@openjdk.java.net> <mailto:security-dev@openjdk.java.net> Subject: Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" Changes look fine. I suppose Paul will help sponsoring the fix as he is listed as the RE for 8231387? Thanks, Valerie On 9/24/2019 12:36 PM, Shi, Tianmin wrote: Hi Can someone help reviewing this fix? Bug: https://bugs.openjdk.java.net/browse/JDK-8231387 Webrev: http://cr.openjdk.java.net/~phh/8231387/webrev.00/ Thank you, Tianmin Shi
Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class"
Thank you, Valerie. :) The patch needs a test, however, so I added a slightly modified version of Tianmin’s reproducer. New webrev at http://cr.openjdk.java.net/~phh/8231387/webrev.01/ The test fails without the fix. From: Valerie Peng Organization: Oracle Corporation Date: Tuesday, September 24, 2019 at 3:03 PM To: "Hohensee, Paul" , "security-dev@openjdk.java.net" Subject: Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" I am the security reviewer that you need. One should be enough. ;) Valerie On 9/24/2019 2:37 PM, Hohensee, Paul wrote: Yes, I’ll sponsor. Though it looks ok to me, I’m not a security expert, so do we need another security reviewer? From: security-dev <mailto:security-dev-boun...@openjdk.java.net> on behalf of Valerie Peng <mailto:valerie.p...@oracle.com> Organization: Oracle Corporation Date: Tuesday, September 24, 2019 at 2:17 PM To: "security-dev@openjdk.java.net"<mailto:security-dev@openjdk.java.net> <mailto:security-dev@openjdk.java.net> Subject: Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" Changes look fine. I suppose Paul will help sponsoring the fix as he is listed as the RE for 8231387? Thanks, Valerie On 9/24/2019 12:36 PM, Shi, Tianmin wrote: Hi Can someone help reviewing this fix? Bug: https://bugs.openjdk.java.net/browse/JDK-8231387 Webrev: http://cr.openjdk.java.net/~phh/8231387/webrev.00/ Thank you, Tianmin Shi
Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class"
Yes, I’ll sponsor. Though it looks ok to me, I’m not a security expert, so do we need another security reviewer? From: security-dev on behalf of Valerie Peng Organization: Oracle Corporation Date: Tuesday, September 24, 2019 at 2:17 PM To: "security-dev@openjdk.java.net" Subject: Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" Changes look fine. I suppose Paul will help sponsoring the fix as he is listed as the RE for 8231387? Thanks, Valerie On 9/24/2019 12:36 PM, Shi, Tianmin wrote: Hi Can someone help reviewing this fix? Bug: https://bugs.openjdk.java.net/browse/JDK-8231387 Webrev: http://cr.openjdk.java.net/~phh/8231387/webrev.00/ Thank you, Tianmin Shi
Re: Issue related to backport JDK-7092821
I’ve filed https://bugs.openjdk.java.net/browse/JDK-8231387 to track this. Thanks, Paul From: "Shi, Tianmin" Date: Monday, September 23, 2019 at 1:21 AM To: "security-dev@openjdk.java.net" Cc: "Hohensee, Paul" Subject: Re: Issue related to backport JDK-7092821 Hi Everyone, I haven’t get any response yet for my previous email. so I would like to raise this issue again and also attached a small code sample to repo the issue. This sample code works fine in JDK8 but print out this line in JDK13 due to the race condition "CertificateFactory.Fixed is NULL" Thank you, From: "Shi, Tianmin" Date: Tuesday, September 17, 2019 at 12:46 PM To: "security-dev@openjdk.java.net" Subject: Issue related to backport JDK-7092821 Hi Everyone, This is Tianmin Shi from the Amazon Corretto team. I am new to JDK development, please let me know if I missed anything. I am working on backport JDK-7092821<https://bugs.openjdk.java.net/browse/JDK-7092821> to 8u and 11u. however I think there is a potential race condition introduced by the change, which could cause method getService in class java.security.Provider to return incorrect results. Which is due to the read of legacyMap at line 1260 is not synchronized with clear and repopulate of the same map’s entries inside ensureLegacyParsed(), the fix is a simpler one liner in the attached webrev. Can we push this change to tip so I can backport it with JDK-7092821<https://bugs.openjdk.java.net/browse/JDK-7092821> together? Thank you
Re: [11u]: RFR: Backport of 8215694: keytool cannot generate RSASSA-PSS certificates
In CertAndKeyGen.java, does generate() need a throws declaration? Otherwise looks good. We've been talking about backporting patches with CSRs and have done at least one. Imo, 8076190 and 8213400 are good backport candidates since the spec changes are minor. Thanks, Paul On 6/28/19, 12:33 AM, "jdk-updates-dev on behalf of Langer, Christoph" wrote: Hi again, I had to make some additions to get the test sun/security/tools/keytool/PSS.java to work. Firstly, I had to include the testlibrary utility class 'test/lib/jdk/test/lib/security/DerUtils.java' from the change for JDK-8076190. Then I had to add some code to src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java from JDK-8213400 to tolerate a keyBits value of -1. This is exercised in the PSS test when keytool is called with "-genkeypair -keyalg RSASSA-PSS -sigalg RSASSA-PSS" without specifying the -keysize parameter. Backporting JDK-8076190 or JDK-8213400 over to JDK11 is not possible due to their nature (CSR attached, behavioral change). The webrevs were updated in-place: http://cr.openjdk.java.net/~clanger/webrevs/8215694.11u.full.0/ http://cr.openjdk.java.net/~clanger/webrevs/8215694.11u.manual.0/ /Christoph > -Original Message- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Mittwoch, 26. Juni 2019 17:30 > To: jdk-updates-...@openjdk.java.net > Cc: security-dev > Subject: [CAUTION] [11u]: RFR: Backport of 8215694: keytool cannot > generate RSASSA-PSS certificates > > Hi, > > please help reviewing the backport of JDK- 8215694: keytool cannot generate > RSASSA-PSS certificates. The patch doesn't apply cleanly but the rejects are > only minor. The Item is needed as prerequisite to apply JDK-8216039. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215694 > Original Change: http://hg.openjdk.java.net/jdk/jdk12/rev/bdb29aa5fd31 > Rejects when applying original change: > http://cr.openjdk.java.net/~clanger/webrevs/8215694.rejects.patch > Full Webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8215694.11u.full.0/ > Incremental Webrev of added modifications: > http://cr.openjdk.java.net/~clanger/webrevs/8215694.11u.manual.0/ > > Thanks > Christoph
Re: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange
Looks good. Paul On 7/11/19, 2:14 PM, "jdk-updates-dev on behalf of Langer, Christoph" wrote: Ping... Can somebody please have a look at this backport? Regression testing shows no problems... Thanks Christoph From: Langer, Christoph Sent: Donnerstag, 4. Juli 2019 15:11 To: jdk-updates-...@openjdk.java.net Cc: security-dev Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange Hi, please help reviewing the backport of JDK-8216039 to jdk11u-dev. Since predecessor patch JDK-8211122 could not be applied to JDK 11 updates, some manual work is necessary. In src/java.base/share/classes/java/security/Signature.java and src/java.base/share/classes/sun/security/util/SignatureUtil.java the imports of jdk.internal.access have to be changed into jdk.internal.misc. The update that originally went to src/java.base/share/classes/jdk/internal/access/SharedSecrets.java obviously needs to be applied to src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java. The new file src/java.base/share/classes/jdk/internal/access/JavaSecuritySignatureAccess.java needs to be src/java.base/share/classes/jdk/internal/misc/JavaSecuritySignatureAccess.java in 11u. See the full webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.full.0/ The webrev for manual changes only: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.manual.0/ Original Bug: https://bugs.openjdk.java.net/browse/JDK-8216039 Thanks Christoph
Re: [11u]: RFR: Backport of 8215694: keytool cannot generate RSASSA-PSS certificates
Yes. Thanks, Paul. On 7/1/19, 7:26 AM, "Langer, Christoph" wrote: Hi Paul, thanks for your review. > In CertAndKeyGen.java, does generate() need a throws declaration? It doesn't. IllegalArgumentException is a RuntimeException and as such doesn't need a throws declaration. And InvalidKeyException is obviously not needed and was removed in the original changeset as well. > Otherwise looks good. Thanks. I also asked Max Wang to have a look off list and he seems to agree as well. > We've been talking about backporting patches with CSRs and have done at > least one. Imo, 8076190 and 8213400 are good backport candidates since the > spec changes are minor. Yes, a CSR is not necessarily a showstopper for a backport. But as it is not my area of expertise and there's no other reason that makes backports of these bugs important to me, I don't want to take the additional work and responsibility for these backports. But feel free to do this 😊 So, I guess I'm good to push this, once approved. Cheers, Christoph
Re: [11u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480
Add Original CSR: https://bugs.openjdk.java.net/browse/JDK-8213577 On 5/24/19, 9:42 AM, "jdk-updates-dev on behalf of Hohensee, Paul" wrote: Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8224765 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8224766 Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8210985 Original email thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018168.html Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/8a85d21d9616 Requesting approval for the backport CSR as well as the backport itself. Since this is a backport, I’ve gone with the one-phase CSR approval process and finalized the CSR. Original patch applies cleanly to 11u. Thanks, Paul
[11u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480
Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8224765 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8224766 Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8210985 Original email thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018168.html Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/8a85d21d9616 Requesting approval for the backport CSR as well as the backport itself. Since this is a backport, I’ve gone with the one-phase CSR approval process and finalized the CSR. Original patch applies cleanly to 11u. Thanks, Paul
[8u-dev] RFA (S): JDK-8210985: Update the default SSL session cache size to 20480
Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8224769 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8224770 Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8210985 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8213577 Original email thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018168.html Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/8a85d21d9616 Requesting approval for the backport CSR as well as the backport itself. Since this is a backport, I’ve gone with the one-phase CSR approval process and finalized the CSR. Original patch applies cleanly to 8u net of line numbers and file locations. Thanks, Paul
Re: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by JDK-8164656 needs same change as JDK-8190690
+1 Paul On 3/15/19, 4:00 AM, "jdk8u-dev on behalf of Aleksey Shipilev" wrote: On 3/15/19 5:55 AM, Andrew John Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8220641 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/ Looks good, ship it. -Aleksey
Re: SSL session cache default maximum number of entries
I've filed https://bugs.openjdk.java.net/browse/JDK-8210985. Thanks for looking into this. Paul On 9/17/18, 8:37 AM, "Sean Mullan" wrote: On 9/12/18 2:25 PM, Hohensee, Paul wrote: > Thanks very much for investigating. We're aware that the cache size can be set by the user, but many of our users haven't done so because it hasn't been necessary, and boom. Would you mind filing a bug and we will look into it? Thanks, Sean > > Paul > > On 9/11/18, 12:49 PM, "core-libs-dev on behalf of Sean Mullan" wrote: > > Hi Paul, > > Thank you for bringing this issue to our attention. While we agree that > this does indeed seem like an issue that should be addressed, it is > quite late in the JDK 11 schedule, and it does not appear to be a new > issue introduced in JDK 11. We will be investigating this offline and > will get back to you as soon as we can with more details. Offhand, I > think that we would be able to change the default in an update release. > > Also, you are probably already be aware of this, but you can use the > SSLSessionContext.setSessionCacheSize() API as well as the > "javax.net.ssl.sessionCacheSize" system property to customize the cache > size. > > --Sean > > On 9/11/18 12:02 PM, Sean Mullan wrote: > > cross-posting to security-dev since this is related to SSL/TLS. > > > > On 9/11/18 11:41 AM, Hohensee, Paul wrote: > >> The default value for the maximum number of entries in the SSL session > >> cache (which is a SoftReference cache) is infinite, and the entry > >> timeout is 24 hours. With larger heaps, we’re running into situations > >> where the cache ends up with several million entries when the 24 hours > >> are up. They’re then all invalidated at the same time, resulting in > >> multi-minute pauses (effectively service failures). We’ve experimented > >> with using 10k as the default maximum number of entries with good > >> results (i.e., no latency increases due to sessions falling out of the > >> cache). It’s late and a long shot for JDK11: we’d love to see it > >> changed there because 11 is an LTS release and this is, at least > >> nominally, a behavior change which might not be acceptable in 11u. > >> What do people think? > >> > >> Thanks, > >> > >> Paul > >> > >
Re: SSL session cache default maximum number of entries
Thanks very much for investigating. We're aware that the cache size can be set by the user, but many of our users haven't done so because it hasn't been necessary, and boom. Paul On 9/11/18, 12:49 PM, "core-libs-dev on behalf of Sean Mullan" wrote: Hi Paul, Thank you for bringing this issue to our attention. While we agree that this does indeed seem like an issue that should be addressed, it is quite late in the JDK 11 schedule, and it does not appear to be a new issue introduced in JDK 11. We will be investigating this offline and will get back to you as soon as we can with more details. Offhand, I think that we would be able to change the default in an update release. Also, you are probably already be aware of this, but you can use the SSLSessionContext.setSessionCacheSize() API as well as the "javax.net.ssl.sessionCacheSize" system property to customize the cache size. --Sean On 9/11/18 12:02 PM, Sean Mullan wrote: > cross-posting to security-dev since this is related to SSL/TLS. > > On 9/11/18 11:41 AM, Hohensee, Paul wrote: >> The default value for the maximum number of entries in the SSL session >> cache (which is a SoftReference cache) is infinite, and the entry >> timeout is 24 hours. With larger heaps, we’re running into situations >> where the cache ends up with several million entries when the 24 hours >> are up. They’re then all invalidated at the same time, resulting in >> multi-minute pauses (effectively service failures). We’ve experimented >> with using 10k as the default maximum number of entries with good >> results (i.e., no latency increases due to sessions falling out of the >> cache). It’s late and a long shot for JDK11: we’d love to see it >> changed there because 11 is an LTS release and this is, at least >> nominally, a behavior change which might not be acceptable in 11u. >> What do people think? >> >> Thanks, >> >> Paul >>
