From dcherepanov at azul.com  Tue Feb  1 11:21:21 2022
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Tue, 1 Feb 2022 14:21:21 +0300
Subject: [8u] RFR: JDK-8231507: Update Apache Santuario (XML Signature) to
 version 2.1.4
Message-ID: <fe7ffd1e-89e7-f53c-5338-83ce8ec206d5@azul.com>

JBS: https://bugs.openjdk.java.net/browse/JDK-8231507
Webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8231507/webrev.01/
11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8727ed99cb0c

The patch for 11u applies cleanly to 8u with path shuffling except the following two places
 ?- XMLDSigRI.java,? context changed due to JDK-8130181 isn't present in 8u
 ?- santuario.md, updated version in THIRD_PARTY_README files

Verified with jdk_security tests.

Thanks

Dmitry


From mbalao at redhat.com  Tue Feb  1 21:47:50 2022
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 1 Feb 2022 16:47:50 -0500
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
Message-ID: <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>

Hi Alexey,

Thanks for proposing a new version of your patch.

If we change the default behavior for an empty "storetype" parameter (that
is: trying to get the value from the file using a SunJCE class instead of
using the default keystore type value), we would need to include that in
the CSR for 8u. However, I believe that this behavioral change is not
strictly required and have a couple of concerns:

1) We are using a SunJCE class as the only engine prober and perhaps SunJCE
is not even available/enabled in runtime. This is different in JDK-11
because all security providers are probed through a JCA API, and if one
happens to handle PKCS#12 and identify the InputStream as such, we get a
KeyStore instance of it.

2) In JDK-11, the "storetype" value is whatever the probed security
provider wants it to be. In JDK-8, we would be fixing the algorithm name to
SunJCE's "pkcs12" value -even if SunJCE is not available/enabled as
mentioned in #1-. This can break backward-compatibility in my view. The
scenario that I have in mind is for example: SunJCE disabled, a 3rd party
security provider that handles PKCS#12 and calls the algorithm "P12", a
java.security property set with "keystore.type=P12" and an invocation to
Keytool without a "storetype" parameter. In that case, SunJCE will jump-in,
say that it's a PKCS#12 keystore and rename "storetype" from the default
"P12" to "pkcs12". The invocation will later fail at "keyStore =
KeyStore.getInstance(storetype);".

In general, I'm a bit concerned about the 8u backport of this enhancement.
Can you please elaborate on the reasons why it would be justified for such
an old release? It looks to me that we are looking into password-less
PKCS#12 keystores and being more flexible with the algorithms used to
encrypt certificates and keystore integrity (note that private keys
encryption is not under the scope of this enhancement, as there is already
flexibility to choose the algorithms). While the latter could be seen as a
security concern, we should be able to leverage on the file-system/OS
permissions for that. Let me know of your thoughts. I'd like the 8u
maintainers to be involved in this discussion as well.

Thanks,
Martin.-


On Wed, Sep 8, 2021 at 1:54 PM Alexey Bakhtin <alexey at azul.com> wrote:

> Hi Martin,
>
> Thank you a lot for review.
> I?ve simplified keytool code almost as you suggested but I still think
> PKCS12 probing is useful here.
> I?m agree, the first version of kstype detection was not correct, so I?ve
> implemented it via PKCS12KeyStore.probe as you suggested in the first mail.
> Without such probing the passwordless feature looks strange: "keytool
> -list? cmd prints PKCS12 store type and warning about password for the
> passwordless keystore (if storetype is not indicated explicitly). The same
> is for other commands.
> Also, I have removed changes in the
> test/lib/jdk/test/lib/SecurityTools.java and updated tests to use
> jdk/test/lib/jdk/test/lib/SecurityTools.java
>
> All sun/security/pkcs12  and sun/security/tools/keytool tests passed
>
> New version of the patch is available at :
> http://cr.openjdk.java.net/~abakhtin/8076190_8u/webrev.v1/
>
> Regards
> Alexey
>
> > On 24 Aug 2021, at 18:50, Martin Balao <mbalao at redhat.com> wrote:
> >
> > Hi Alexey,
> >
> > Final comments for this first round:
> >
> > * src/share/classes/sun/security/tools/keytool/Main.java
> >  * @@ -2025,7 +2058,14 @@
> >   * Seems to have an issue similar to the one before:
> >    * 'srcstoretype' is changed based on probing (which was not a
> > JDK-8 behavior)
> >    * the value set is based on the assumption that
> > '!"JKS".equalsIgnoreCase(realType)' is PKCS#12 and that may not be
> > correct on some cases
> >    * there might be some redundancy in the checks 'srcksfile != null
> > && is != null && srcProviderName == null'
> >   * I'd consider a similar approach to the one proposed earlier: take
> > the 'srcstoretype' value for certain, compare against 'pkcs12' and
> > handle the existing-keystore scenario. In this case, 'is' seems to be
> > the variable to decide whether there is an existing keystore or not.
> >
> > * test/lib/jdk/test/lib/SecurityTools.java
> >  * For some reason, there are 2 SecurityTools files in JDK-8:
> >   * jdk/test/lib/testlibrary/jdk/testlibrary/SecurityTools.java
> >   * jdk/test/lib/jdk/test/lib/SecurityTools.java
> >  * Can we avoid this change by making the test use the other one?
> >   * Looks like
> > 'jdk/test/lib/testlibrary/jdk/testlibrary/SecurityTools.java' is the
> > one that you want for the test
> >   * If we apply your proposed change, then the 2 libs will be equal
> > in regards to the affected method and I'm in general concerned about
> > the side-effects of modifying libraries; the set of regression tests
> > that you ran may not be enough to make sure that we don't introduce a
> > regression.
> >
> > Thanks,
> > Martin.-
> >
>
>

From jhuttana at redhat.com  Wed Feb  2 06:03:53 2022
From: jhuttana at redhat.com (Jayashree Huttanagoudar)
Date: Wed, 2 Feb 2022 11:33:53 +0530
Subject: OpenJDK 8u322 Released
In-Reply-To: <Yfc2G1rGTYwN5/Fg@hex.discworld.ac.uk>
References: <Yfc2G1rGTYwN5/Fg@hex.discworld.ac.uk>
Message-ID: <CAJ8kv5PKz3kXFR4y5yTv_w1JPsUG+mzct_dHmQC7_zg+AKcOMA@mail.gmail.com>

Hi,

On Mon, Jan 31, 2022 at 6:37 AM Andrew Hughes <gnu.andrew at redhat.com> wrote:

> We are pleased to announce the release of OpenJDK 8u322.
>
> The source tarball is available from:
>
> * https://openjdk-sources.osci.io/openjdk8/openjdk8u322-ga.tar.xz
>
> The tarball is accompanied by a digital signature available at:
>
> * https://openjdk-sources.osci.io/openjdk8/openjdk8u322-ga.tar.xz.sig
>
> This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):
>
> PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
> Fingerprint = CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F
>
> SHA256 checksums:
>
> e1ce7fc5def4446ca62df355f70548b2deb53fdcad548b0b3550ceaa96395247
> openjdk8u322-ga.tar.xz
> 1f8cc08c2c03d68c865409bd9c4f07c4121a7f179dfd6d081fd2938f0246f56e
> openjdk8u322-ga.tar.xz.sig
>
> The checksums can be downloaded from:
>
> * https://openjdk-sources.osci.io/openjdk8/openjdk8u322-ga.sha256
>
> The binaries to go with this are here :
https://adoptopenjdk.net/upstream.html?variant=openjdk8&jvmVariant=hotspot

Thanks & Regards,
Jaya

> Thanks,
> --
> Andrew :)
> Pronouns: he / him or they / them
> Senior Free Java Software Engineer
> OpenJDK Package Owner
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>

From sgehwolf at redhat.com  Wed Feb  2 09:31:17 2022
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 02 Feb 2022 10:31:17 +0100
Subject: [8u] RFR: 8280963: Incorrect PrintFlags formatting on Windows
In-Reply-To: <CABUxsJ3ZQSe-RHFzCPUCOqx4jd3dAEh0=de9wNe_9NFUHxSKdg@mail.gmail.com>
References: <CABUxsJ3ZQSe-RHFzCPUCOqx4jd3dAEh0=de9wNe_9NFUHxSKdg@mail.gmail.com>
Message-ID: <8e7dcaeebb2f8fdb37f03f37adca37b6b10c36de.camel@redhat.com>

Hi Alex,

On Mon, 2022-01-31 at 17:09 +0000, Alex Kashchenko wrote:
> Hi,
> 
> Please review a fix to 8u-only Windows-specific problem with
> -XX:+PrintFlags* output:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8280963
> 
> Webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8280963/webrev.01/

+1 on using a partial backport for this usability issue as it reduces
risks as compared to a full JDK-8042893 backport.

Looks good to me.

Thanks,
Severin

> Problem description on Stack Overflow by Andrei Pangin:
> https://stackoverflow.com/a/63309395
> 
> The problem was fixed in jdk9 as part of JDK-8042893 [1], but this
> jdk9 change [2] doesn't look like a good candidate for the 8u backport
> according to 8u Best Practices [3]. Still the problem manifests itself
> as a customer-visible bug on Windows because people do use
> -XX:+PrintFlagsFinal to find out the actual flags picked up by JVM and
> can be confused by unexpected zeros in the output. Proposed patch
> cherry-picks the minimal change from JDK-8042893 commit [4].
> 
> Testing:
> 
> ?- regression test is included with the proposed patch
> ?- checked that it builds on Windows 64-bit and 32-bit on VS2017 and VS2010
> ?- ran jtreg:hotspot/test/runtime on Windows and Linux
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8042893
> [2] https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15
> [3] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012002.html
> [4] https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15#l53.1
> 
> 


From akashche at redhat.com  Wed Feb  2 11:27:22 2022
From: akashche at redhat.com (Alex Kashchenko)
Date: Wed, 2 Feb 2022 11:27:22 +0000
Subject: [8u] RFR: 8280963: Incorrect PrintFlags formatting on Windows
In-Reply-To: <8e7dcaeebb2f8fdb37f03f37adca37b6b10c36de.camel@redhat.com>
References: <CABUxsJ3ZQSe-RHFzCPUCOqx4jd3dAEh0=de9wNe_9NFUHxSKdg@mail.gmail.com>
 <8e7dcaeebb2f8fdb37f03f37adca37b6b10c36de.camel@redhat.com>
Message-ID: <CABUxsJ2bhtWT3HU9GFL-Adn3VC7r9dbY_dTOD-Vb7MBEyGKcCA@mail.gmail.com>

On 2/2/22, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> Hi Alex,
>
> On Mon, 2022-01-31 at 17:09 +0000, Alex Kashchenko wrote:
>> Hi,
>>
>> Please review a fix to 8u-only Windows-specific problem with
>> -XX:+PrintFlags* output:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8280963
>>
>> Webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8280963/webrev.01/
>
> +1 on using a partial backport for this usability issue as it reduces
> risks as compared to a full JDK-8042893 backport.
>
> Looks good to me.

Thanks for the review! I've marked the bug for approval.


>
> [...]
>

-- 
-Alex


From alexey at azul.com  Wed Feb  2 14:35:11 2022
From: alexey at azul.com (Alexey Bakhtin)
Date: Wed, 2 Feb 2022 14:35:11 +0000
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
Message-ID: <A97E28C9-9110-438F-B078-0F201F021686@azul.com>

Hi Martin,

Thank you for review. I see the issue with SunJCE now.
There are several reasons to request this backport. The first, as you mentioned, is password-less PKCS#12 keystores. It minimises behavior differences between JKS and PKCS12 keystores and makes keytool behavior close to JDK11+ version.
Another reason of this backport is to fix incompatibility issues between OpenSSL and JDK8 keystores. It is described in JDK-8245169 [1] and fixed by JDK-8076190.

In case of these changes are too major for JDK8 release, I d?like to fix JDK-8245169 issue (PBES2Parameters file only [2] ) in a separate review.

Thank you
Alexey

[1] - https://bugs.openjdk.java.net/browse/JDK-8245169
[2] - http://cr.openjdk.java.net/~abakhtin/8076190_8u/webrev.v1/src/share/classes/com/sun/crypto/provider/PBES2Parameters.java.udiff.html


> On 2 Feb 2022, at 00:47, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Alexey,
> 
> Thanks for proposing a new version of your patch.
> 
> If we change the default behavior for an empty "storetype" parameter (that is: trying to get the value from the file using a SunJCE class instead of using the default keystore type value), we would need to include that in the CSR for 8u. However, I believe that this behavioral change is not strictly required and have a couple of concerns:
> 
> 1) We are using a SunJCE class as the only engine prober and perhaps SunJCE is not even available/enabled in runtime. This is different in JDK-11 because all security providers are probed through a JCA API, and if one happens to handle PKCS#12 and identify the InputStream as such, we get a KeyStore instance of it.
> 
> 2) In JDK-11, the "storetype" value is whatever the probed security provider wants it to be. In JDK-8, we would be fixing the algorithm name to SunJCE's "pkcs12" value -even if SunJCE is not available/enabled as mentioned in #1-. This can break backward-compatibility in my view. The scenario that I have in mind is for example: SunJCE disabled, a 3rd party security provider that handles PKCS#12 and calls the algorithm "P12", a java.security property set with "keystore.type=P12" and an invocation to Keytool without a "storetype" parameter. In that case, SunJCE will jump-in, say that it's a PKCS#12 keystore and rename "storetype" from the default "P12" to "pkcs12". The invocation will later fail at "keyStore = KeyStore.getInstance(storetype);".
> 
> In general, I'm a bit concerned about the 8u backport of this enhancement. Can you please elaborate on the reasons why it would be justified for such an old release? It looks to me that we are looking into password-less PKCS#12 keystores and being more flexible with the algorithms used to encrypt certificates and keystore integrity (note that private keys encryption is not under the scope of this enhancement, as there is already flexibility to choose the algorithms). While the latter could be seen as a security concern, we should be able to leverage on the file-system/OS permissions for that. Let me know of your thoughts. I'd like the 8u maintainers to be involved in this discussion as well.
> 
> Thanks,
> Martin.-
> 
> 
> On Wed, Sep 8, 2021 at 1:54 PM Alexey Bakhtin <alexey at azul.com> wrote:
> Hi Martin,
> 
> Thank you a lot for review.
> I?ve simplified keytool code almost as you suggested but I still think PKCS12 probing is useful here.
> I?m agree, the first version of kstype detection was not correct, so I?ve implemented it via PKCS12KeyStore.probe as you suggested in the first mail.
> Without such probing the passwordless feature looks strange: "keytool -list? cmd prints PKCS12 store type and warning about password for the passwordless keystore (if storetype is not indicated explicitly). The same is for other commands.
> Also, I have removed changes in the test/lib/jdk/test/lib/SecurityTools.java and updated tests to use  jdk/test/lib/jdk/test/lib/SecurityTools.java
> 
> All sun/security/pkcs12  and sun/security/tools/keytool tests passed
> 
> New version of the patch is available at : http://cr.openjdk.java.net/~abakhtin/8076190_8u/webrev.v1/
> 
> Regards
> Alexey
> 
> > On 24 Aug 2021, at 18:50, Martin Balao <mbalao at redhat.com> wrote:
> >
> > Hi Alexey,
> >
> > Final comments for this first round:
> >
> > * src/share/classes/sun/security/tools/keytool/Main.java
> >  * @@ -2025,7 +2058,14 @@
> >   * Seems to have an issue similar to the one before:
> >    * 'srcstoretype' is changed based on probing (which was not a
> > JDK-8 behavior)
> >    * the value set is based on the assumption that
> > '!"JKS".equalsIgnoreCase(realType)' is PKCS#12 and that may not be
> > correct on some cases
> >    * there might be some redundancy in the checks 'srcksfile != null
> > && is != null && srcProviderName == null'
> >   * I'd consider a similar approach to the one proposed earlier: take
> > the 'srcstoretype' value for certain, compare against 'pkcs12' and
> > handle the existing-keystore scenario. In this case, 'is' seems to be
> > the variable to decide whether there is an existing keystore or not.
> >
> > * test/lib/jdk/test/lib/SecurityTools.java
> >  * For some reason, there are 2 SecurityTools files in JDK-8:
> >   * jdk/test/lib/testlibrary/jdk/testlibrary/SecurityTools.java
> >   * jdk/test/lib/jdk/test/lib/SecurityTools.java
> >  * Can we avoid this change by making the test use the other one?
> >   * Looks like
> > 'jdk/test/lib/testlibrary/jdk/testlibrary/SecurityTools.java' is the
> > one that you want for the test
> >   * If we apply your proposed change, then the 2 libs will be equal
> > in regards to the affected method and I'm in general concerned about
> > the side-effects of modifying libraries; the set of regression tests
> > that you ran may not be enough to make sure that we don't introduce a
> > regression.
> >
> > Thanks,
> > Martin.-
> >
> 


From mbalao at redhat.com  Wed Feb  2 15:02:39 2022
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 2 Feb 2022 10:02:39 -0500
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
Message-ID: <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>

Hi Alexey,

Thanks for your insights.

JDK-8245169 is a bug affecting 8u and should be trivial / no-risk to
backport. That will be easy to do, review and get maintainers approval.

As I understand it, the only argument to justify an 8u backport of
JDK-8076190 would be to minimize behavior differences between JKS and
PKCS12 keystores. Can you please explain how this is affecting users? A
real use-case would help. In my view, we would need a strong reason to move
forward because 8076190 is not an easy fit for 8u and we would need to look
at backward-compatibility issues thoroughly -which would be a time
investment for both of us-.

Thanks,
Martin.-


On Wed, Feb 2, 2022 at 9:35 AM Alexey Bakhtin <alexey at azul.com> wrote:

> Hi Martin,
>
> Thank you for review. I see the issue with SunJCE now.
> There are several reasons to request this backport. The first, as you
> mentioned, is password-less PKCS#12 keystores. It minimises behavior
> differences between JKS and PKCS12 keystores and makes keytool behavior
> close to JDK11+ version.
> Another reason of this backport is to fix incompatibility issues between
> OpenSSL and JDK8 keystores. It is described in JDK-8245169 [1] and fixed by
> JDK-8076190.
>
> In case of these changes are too major for JDK8 release, I d?like to fix
> JDK-8245169 issue (PBES2Parameters file only [2] ) in a separate review.
>
> Thank you
> Alexey
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8245169
> [2] -
> http://cr.openjdk.java.net/~abakhtin/8076190_8u/webrev.v1/src/share/classes/com/sun/crypto/provider/PBES2Parameters.java.udiff.html
>
>
> > On 2 Feb 2022, at 00:47, Martin Balao <mbalao at redhat.com> wrote:
> >
> > Hi Alexey,
> >
> > Thanks for proposing a new version of your patch.
> >
> > If we change the default behavior for an empty "storetype" parameter
> (that is: trying to get the value from the file using a SunJCE class
> instead of using the default keystore type value), we would need to include
> that in the CSR for 8u. However, I believe that this behavioral change is
> not strictly required and have a couple of concerns:
> >
> > 1) We are using a SunJCE class as the only engine prober and perhaps
> SunJCE is not even available/enabled in runtime. This is different in
> JDK-11 because all security providers are probed through a JCA API, and if
> one happens to handle PKCS#12 and identify the InputStream as such, we get
> a KeyStore instance of it.
> >
> > 2) In JDK-11, the "storetype" value is whatever the probed security
> provider wants it to be. In JDK-8, we would be fixing the algorithm name to
> SunJCE's "pkcs12" value -even if SunJCE is not available/enabled as
> mentioned in #1-. This can break backward-compatibility in my view. The
> scenario that I have in mind is for example: SunJCE disabled, a 3rd party
> security provider that handles PKCS#12 and calls the algorithm "P12", a
> java.security property set with "keystore.type=P12" and an invocation to
> Keytool without a "storetype" parameter. In that case, SunJCE will jump-in,
> say that it's a PKCS#12 keystore and rename "storetype" from the default
> "P12" to "pkcs12". The invocation will later fail at "keyStore =
> KeyStore.getInstance(storetype);".
> >
> > In general, I'm a bit concerned about the 8u backport of this
> enhancement. Can you please elaborate on the reasons why it would be
> justified for such an old release? It looks to me that we are looking into
> password-less PKCS#12 keystores and being more flexible with the algorithms
> used to encrypt certificates and keystore integrity (note that private keys
> encryption is not under the scope of this enhancement, as there is already
> flexibility to choose the algorithms). While the latter could be seen as a
> security concern, we should be able to leverage on the file-system/OS
> permissions for that. Let me know of your thoughts. I'd like the 8u
> maintainers to be involved in this discussion as well.
> >
> > Thanks,
> > Martin.-
> >
> >
> > On Wed, Sep 8, 2021 at 1:54 PM Alexey Bakhtin <alexey at azul.com> wrote:
> > Hi Martin,
> >
> > Thank you a lot for review.
> > I?ve simplified keytool code almost as you suggested but I still think
> PKCS12 probing is useful here.
> > I?m agree, the first version of kstype detection was not correct, so
> I?ve implemented it via PKCS12KeyStore.probe as you suggested in the first
> mail.
> > Without such probing the passwordless feature looks strange: "keytool
> -list? cmd prints PKCS12 store type and warning about password for the
> passwordless keystore (if storetype is not indicated explicitly). The same
> is for other commands.
> > Also, I have removed changes in the
> test/lib/jdk/test/lib/SecurityTools.java and updated tests to use
> jdk/test/lib/jdk/test/lib/SecurityTools.java
> >
> > All sun/security/pkcs12  and sun/security/tools/keytool tests passed
> >
> > New version of the patch is available at :
> http://cr.openjdk.java.net/~abakhtin/8076190_8u/webrev.v1/
> >
> > Regards
> > Alexey
> >
> > > On 24 Aug 2021, at 18:50, Martin Balao <mbalao at redhat.com> wrote:
> > >
> > > Hi Alexey,
> > >
> > > Final comments for this first round:
> > >
> > > * src/share/classes/sun/security/tools/keytool/Main.java
> > >  * @@ -2025,7 +2058,14 @@
> > >   * Seems to have an issue similar to the one before:
> > >    * 'srcstoretype' is changed based on probing (which was not a
> > > JDK-8 behavior)
> > >    * the value set is based on the assumption that
> > > '!"JKS".equalsIgnoreCase(realType)' is PKCS#12 and that may not be
> > > correct on some cases
> > >    * there might be some redundancy in the checks 'srcksfile != null
> > > && is != null && srcProviderName == null'
> > >   * I'd consider a similar approach to the one proposed earlier: take
> > > the 'srcstoretype' value for certain, compare against 'pkcs12' and
> > > handle the existing-keystore scenario. In this case, 'is' seems to be
> > > the variable to decide whether there is an existing keystore or not.
> > >
> > > * test/lib/jdk/test/lib/SecurityTools.java
> > >  * For some reason, there are 2 SecurityTools files in JDK-8:
> > >   * jdk/test/lib/testlibrary/jdk/testlibrary/SecurityTools.java
> > >   * jdk/test/lib/jdk/test/lib/SecurityTools.java
> > >  * Can we avoid this change by making the test use the other one?
> > >   * Looks like
> > > 'jdk/test/lib/testlibrary/jdk/testlibrary/SecurityTools.java' is the
> > > one that you want for the test
> > >   * If we apply your proposed change, then the 2 libs will be equal
> > > in regards to the affected method and I'm in general concerned about
> > > the side-effects of modifying libraries; the set of regression tests
> > > that you ran may not be enough to make sure that we don't introduce a
> > > regression.
> > >
> > > Thanks,
> > > Martin.-
> > >
> >
>
>

From aph at redhat.com  Thu Feb  3 09:27:37 2022
From: aph at redhat.com (Andrew Haley)
Date: Thu, 3 Feb 2022 09:27:37 +0000
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
Message-ID: <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>

On 2/2/22 15:02, Martin Balao wrote:
> As I understand it, the only argument to justify an 8u backport of
> JDK-8076190 would be to minimize behavior differences between JKS and
> PKCS12 keystores.

JDK-8076190 is a P3 enhancement. On that basis I would have thought
it would be unlikely to be approved for backporting to 8u.
Having said that, Oracle seem to have backported it to everything,
so there's perhaps a parity issue to consider.

I'd like to see a strong justification -- i.e. more than "It would
me nice" -- for the backport.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From mbalao at redhat.com  Thu Feb  3 14:47:53 2022
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 3 Feb 2022 09:47:53 -0500
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
Message-ID: <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>

On 2/3/22 4:27 AM, Andrew Haley wrote:
> 
> Oracle seem to have backported it to everything,
> so there's perhaps a parity issue to consider.
>

At first I thought that they could have backported only the parts
related to 8245169 (PBES2Parameters.java), and count it as a backport of
8076190. But after reading their CSR [1], looks like they went for the
whole thing.

Anyways, if there is a call to go for it, I'll continue the review.

Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8265424


From alexey at azul.com  Thu Feb  3 15:38:21 2022
From: alexey at azul.com (Alexey Bakhtin)
Date: Thu, 3 Feb 2022 15:38:21 +0000
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
 <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
Message-ID: <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>

Yes, according to my investigations Oracle implemented password-less feature as part of JDK-8076190
So, we have behaviour difference between Oracle and OpenJDK implementation now.
I think the parity with Oracle is a good reason to backport all features of JDK-8076190 (not PBES2Parameters.java only)

Alexey

> On 3 Feb 2022, at 17:47, Martin Balao <mbalao at redhat.com> wrote:
> 
> On 2/3/22 4:27 AM, Andrew Haley wrote:
>> 
>> Oracle seem to have backported it to everything,
>> so there's perhaps a parity issue to consider.
>> 
> 
> At first I thought that they could have backported only the parts
> related to 8245169 (PBES2Parameters.java), and count it as a backport of
> 8076190. But after reading their CSR [1], looks like they went for the
> whole thing.
> 
> Anyways, if there is a call to go for it, I'll continue the review.
> 
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8265424
> 


From mbalao at redhat.com  Thu Feb  3 17:16:06 2022
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 3 Feb 2022 12:16:06 -0500
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
 <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
 <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>
Message-ID: <CAKZz+gcub0-G2U-j=ARGdrLeeh4MnZqBHU84kGEHoepoV3L+9g@mail.gmail.com>

Hi Alexey,

On Thu, Feb 3, 2022 at 10:38 AM Alexey Bakhtin <alexey at azul.com> wrote:

> Yes, according to my investigations Oracle implemented password-less
> feature as part of JDK-8076190
> So, we have behaviour difference between Oracle and OpenJDK implementation
> now.
> I think the parity with Oracle is a good reason to backport all features
> of JDK-8076190 (not PBES2Parameters.java only)
>

While we agree that Oracle parity is one of the inputs that we take into
account when making these backports decisions, it shouldn't be the only one
in my view. To put that into context, 8u is now an old release where more
stability/backward-compatibility is expected and patches tend to divert
more as we move forward. This particular case is an example of that. I
asked about other reasons because we can weigh risk with, for example, a
common use case and multiple users affected.

Let me ask you 2 questions:

1) Would backporting only the parts related to 8245169 be a good compromise
solution for you?

2) If not, are you willing to redesign the backport so it does not break
compatibility in scenarios where SunJCE is disabled? I've not put thinking
into alternatives but I'm open to review whatever you come up with.

Thanks,
Martin.-

From sgehwolf at redhat.com  Thu Feb  3 19:33:58 2022
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 03 Feb 2022 20:33:58 +0100
Subject: [Ping2?] [8u] RFR: 8210283:  Support git as an SCM alternative
 in the build
In-Reply-To: <001bf6943ff9fb504cb44a1cfdfaf8bb658ca2bb.camel@redhat.com>
References: <018e4ec4ebaabd486047b9594da773887d53eee2.camel@redhat.com>
 <001bf6943ff9fb504cb44a1cfdfaf8bb658ca2bb.camel@redhat.com>
Message-ID: <5c859ba3ede97bba746538dfdf090fc8a83a11d0.camel@redhat.com>

On Wed, 2021-12-22 at 11:14 +0100, Severin Gehwolf wrote:
> On Fri, 2021-12-10 at 15:11 +0100, Severin Gehwolf wrote:
> > Hi,
> > 
> > Please review this adaptation of the corresponding JDK 11 patch. The
> > JDK 11u patch didn't apply because the build system is widely different
> > between these two releases.
> > 
> > The main difference is make/common/MakeBase.gmk (JDK 8) vs
> > make/SourceRevision.gmk (JDK 11). I've basically rewritten those parts
> > of the patch. All the SCM handling in JDK 8 is in MakeBase.
> > FindAllReposAbs isn't present in JDK 8u.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8210283
> > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210283/01/webrev/
> > 
> > Testing: "make --trace source-tips" on mercurial tree as well as
> > ???????? the git mirror. $IMAGE_DIR/release file contains the SHA of
> > ???????? the sources it was built from with 'git:' or 'hg:' prefixes.
> > 
> > Thoughts?
> 
> Anyone? When building from the git read-only mirror the "release" file
> no longer includes the git sha it was built from without this fix.

Anyone willing to review this?

Thanks,
Severin


From alexey at azul.com  Thu Feb  3 20:29:11 2022
From: alexey at azul.com (Alexey Bakhtin)
Date: Thu, 3 Feb 2022 20:29:11 +0000
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <CAKZz+gcub0-G2U-j=ARGdrLeeh4MnZqBHU84kGEHoepoV3L+9g@mail.gmail.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
 <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
 <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>
 <CAKZz+gcub0-G2U-j=ARGdrLeeh4MnZqBHU84kGEHoepoV3L+9g@mail.gmail.com>
Message-ID: <CD703EE0-5CDC-4CF2-9835-81B1302DD3FB@azul.com>

Hi Martin,

Right now the password-less PKCS12 keystore feature is not critical for us. So, the fixes for the 8245169 would be OK for now.
Thank you for discussion. I will prepare the patch for the JDK-8245169 and send it for review

Thank you
Alexey

> On 3 Feb 2022, at 20:16, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Alexey,
> 
> On Thu, Feb 3, 2022 at 10:38 AM Alexey Bakhtin <alexey at azul.com <mailto:alexey at azul.com>> wrote:
> Yes, according to my investigations Oracle implemented password-less feature as part of JDK-8076190
> So, we have behaviour difference between Oracle and OpenJDK implementation now.
> I think the parity with Oracle is a good reason to backport all features of JDK-8076190 (not PBES2Parameters.java only)
> 
> While we agree that Oracle parity is one of the inputs that we take into account when making these backports decisions, it shouldn't be the only one in my view. To put that into context, 8u is now an old release where more stability/backward-compatibility is expected and patches tend to divert more as we move forward. This particular case is an example of that. I asked about other reasons because we can weigh risk with, for example, a common use case and multiple users affected.
> 
> Let me ask you 2 questions:
> 
> 1) Would backporting only the parts related to 8245169 be a good compromise solution for you?
> 
> 2) If not, are you willing to redesign the backport so it does not break compatibility in scenarios where SunJCE is disabled? I've not put thinking into alternatives but I'm open to review whatever you come up with.
> 
> Thanks,
> Martin.-
> 


From alexey at azul.com  Thu Feb  3 21:29:33 2022
From: alexey at azul.com (Alexey Bakhtin)
Date: Thu, 3 Feb 2022 21:29:33 +0000
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <CD703EE0-5CDC-4CF2-9835-81B1302DD3FB@azul.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
 <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
 <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>
 <CAKZz+gcub0-G2U-j=ARGdrLeeh4MnZqBHU84kGEHoepoV3L+9g@mail.gmail.com>
 <CD703EE0-5CDC-4CF2-9835-81B1302DD3FB@azul.com>
Message-ID: <09658B4B-DDFB-46CB-A48B-4262C3278453@azul.com>

Hi Martin,

The issue described in the [1] is related to HmacPBESHA256 support in the PKCS12KeyStore. This issue is not covered by the JDK-8245169 but fixed by another part of  JDK-8076190
Should it be considered as a separate issue with new Bug Id ? or should we fix altogether as a
JDK-8076190 backport without password-less support ?

[1] -  https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014473.html


> On 3 Feb 2022, at 23:29, Alexey Bakhtin <alexey at azul.com> wrote:
> 
> Hi Martin,
> 
> Right now the password-less PKCS12 keystore feature is not critical for us. So, the fixes for the 8245169 would be OK for now.
> Thank you for discussion. I will prepare the patch for the JDK-8245169 and send it for review
> 
> Thank you
> Alexey
> 
>> On 3 Feb 2022, at 20:16, Martin Balao <mbalao at redhat.com> wrote:
>> 
>> Hi Alexey,
>> 
>> On Thu, Feb 3, 2022 at 10:38 AM Alexey Bakhtin <alexey at azul.com <mailto:alexey at azul.com>> wrote:
>> Yes, according to my investigations Oracle implemented password-less feature as part of JDK-8076190
>> So, we have behaviour difference between Oracle and OpenJDK implementation now.
>> I think the parity with Oracle is a good reason to backport all features of JDK-8076190 (not PBES2Parameters.java only)
>> 
>> While we agree that Oracle parity is one of the inputs that we take into account when making these backports decisions, it shouldn't be the only one in my view. To put that into context, 8u is now an old release where more stability/backward-compatibility is expected and patches tend to divert more as we move forward. This particular case is an example of that. I asked about other reasons because we can weigh risk with, for example, a common use case and multiple users affected.
>> 
>> Let me ask you 2 questions:
>> 
>> 1) Would backporting only the parts related to 8245169 be a good compromise solution for you?
>> 
>> 2) If not, are you willing to redesign the backport so it does not break compatibility in scenarios where SunJCE is disabled? I've not put thinking into alternatives but I'm open to review whatever you come up with.
>> 
>> Thanks,
>> Martin.-
>> 
> 


From gnu.andrew at redhat.com  Fri Feb  4 04:22:29 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 4 Feb 2022 04:22:29 +0000
Subject: jdk8u322 release and packaging
In-Reply-To: <df7b8b73-9399-a796-c06b-325f74c75048@tarent.de>
References: <df7b8b73-9399-a796-c06b-325f74c75048@tarent.de>
Message-ID: <YfyqBUzqXBqZfl0a@hex.discworld.ac.uk>

On 22:07 Sat 22 Jan     , Thorsten Glaser wrote:
> Hi,
> 
> I?m currently packaging openjdk-8 for Debian (unstable, where
> it is tested for LTS/ELTS updating older releases). I have
> taken it over from the previous maintainer, but I am ?mostly?
> keeping this alive.
>

Welcome to OpenJDK maintenance :-)

> I see that the 8u322 release (which I had put into my calendar
> https://wiki.openjdk.java.net/display/jdk8u/Main#Main-Timelines
> from ?) seems to be delayed because of repository changes.
>

No, it was delayed a little to allow time for the large number
of security patches in the release to be fully tested. The changes
themselves were pushed to the repositories on the 18th, to allow
others to test as well. This was a relatively moderate security
update, and so we believe allowing this extra time to be the
preferred course of action, rather than running the risk of
making a release with regressions.

The transition to the new Mercurial monorepository took place
back at the end of November and didn't affect the security
update. If anything, it was a little easier working with
one repository rather than over half a dozen.

> These repository changes are a problem. The packaging depends
> heavily on being able to download the individual hg releases?
> tarballs, plus aarch32 and aarch64-shenandoah, separately and
> put them together in suitable ways depending on the architecture
> building for.
>

I'm not familiar with how each vendor chooses to package OpenJDK.

Source code repositories are primarily targeted at developers, who
need to work with them on a daily basis. The use of multiple
Mercurial repositories, with some patches needing to be duplicated
across all of them, has been causing extra work for those working
on 8u for some time. Having a completely different process for 8u
compared to later maintained versions (11u, 13u, 15u, 17u) - which
are now all handled via GitHub pull requests - further impedes work
on 8u.

It's also worth noting that 7u decided to follow us down the same
route in December for similar reasons.

We have tried to minimise the effect of this on downstream consumers.
I myself handle packaging for Fedora & RHEL, as well as still
maintaining IcedTea for 7u & 8u, so I have considerable experience
of the packaging side.

Primarily, we provide a release tarball for downstream consumers,
so they do not have to care about the source code repositories
at all.  The tarball for this release [0] and the last [1] only
differ by a number of new files and directories being added:

$ tar -xJf /home/downloads/java/drops/openjdk8/openjdk8u312-ga.tar.xz
$ tar -xJf /home/downloads/java/drops/openjdk8/openjdk8u322-ga.tar.xz
$ pushd jdk8u312-ga; find | sort > /tmp/8u312 ; popd
$ pushd jdk8u322-ga; find | sort > /tmp/8u322 ; popd
$ diff -u /tmp/8u3{1,2}2

+./.hgtags-top-repo
+./hotspot/test/compiler/arraycopy
+./hotspot/test/compiler/arraycopy/TestInitializingACLoadWithBadMem.java
-./jdk/make/data/cacerts/globalsignr2ca
-./jdk/make/data/cacerts/identrustdstx3
+./jdk/src/share/classes/jdk/internal/misc
+./jdk/src/share/classes/jdk/internal/misc/TerminatingThreadLocal.java
+./jdk/src/share/classes/sun/security/util/KnownOIDs.java
+./jdk/test/com/sun/net/httpserver/bugs/TruncatedRequestBody.java
+./jdk/test/java/awt/ColorClass
+./jdk/test/java/awt/ColorClass/EqualityTest
+./jdk/test/java/awt/ColorClass/EqualityTest/EqualityTest.java
+./jdk/test/java/awt/event/MouseEvent/AltGraphModifierTest
+./jdk/test/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java
+./jdk/test/java/awt/font/Rotate/A.ttf
+./jdk/test/java/awt/font/Rotate/RotatedItalicsTest.java
+./jdk/test/java/awt/image/RescaleOp
+./jdk/test/java/awt/image/RescaleOp/ImageRescaleOpTest.java
+./jdk/test/java/awt/image/RescaleOp/RescaleAlphaTest.java
+./jdk/test/java/awt/print/PrinterJob/ExceptionFromPrintableIsIgnoredTest.java
+./jdk/test/java/awt/print/PrinterJob/PageDialogMarginTest.java
+./jdk/test/java/awt/Robot/NonEmptyErrorStream.java
+./jdk/test/java/beans/XMLEncoder/ReferenceToNonStaticField.java
-./jdk/test/java/net/MulticastSocket/JoinGroup.java
-./jdk/test/java/net/MulticastSocket/Leave.java
+./jdk/test/java/net/MulticastSocket/JoinLeave.java
+./jdk/test/java/net/NetworkConfigurationProbe.java
+./jdk/test/java/nio/channels/FileChannel/TempDirectBuffersReclamation.java
+./jdk/test/java/nio/file/etc/MacVolumesTest.java
+./jdk/test/java/util/TimeZone/Bug8066652.java
+./jdk/test/java/util/TimeZone/Bug8066652.sh
+./jdk/test/javax/swing/JEditorPane/5076514
+./jdk/test/javax/swing/JEditorPane/5076514/bug5076514.java
+./jdk/test/javax/swing/plaf/metal/MetalUtils
+./jdk/test/javax/swing/plaf/metal/MetalUtils/bug6190373.java
+./jdk/test/jdk/internal/misc
+./jdk/test/jdk/internal/misc/TerminatingThreadLocal
+./jdk/test/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
+./jdk/test/jdk/java/awt/font
+./jdk/test/jdk/java/awt/font/Rotate
+./jdk/test/jdk/java/awt/font/Rotate/RotatedItalicsTest.java
+./jdk/test/lib/testlibrary/jdk/testlibrary/NetworkConfiguration.java
+./jdk/test/sun/net/www/http/RequestMethodCheck
+./jdk/test/sun/net/www/http/RequestMethodCheck/RequestMethodEquality.java
+./jdk/test/sun/net/www/http/RequestMethodCheck/sun
+./jdk/test/sun/net/www/http/RequestMethodCheck/sun/net
+./jdk/test/sun/net/www/http/RequestMethodCheck/sun/net/www
+./jdk/test/sun/net/www/http/RequestMethodCheck/sun/net/www/http
+./jdk/test/sun/net/www/http/RequestMethodCheck/sun/net/www/http/HttpClientAccess.java
+./jdk/test/sun/security/tools/jarsigner/warnings/LowerCaseManifest.java

Downstream are, of course, welcome to consume the code directly from
the source code repositories if they wish. We specifically made sure
that a read-only Git mirror of the mono repositories was active
straight away, so downstream could ignore the transition phase and
move to consuming from GitHub straight away. The only people who need
to be interacting with the mono Mercurial repositories are those who
need to write to them.

> As I said above, I?ve taken this over because nobody else was
> doing it so I?m not heavily invested in this packaging. I?m
> trying to not change too much.
>

Again, this really depends on what you were doing to begin with.

The changes we made for Fedora were very minimal [2]; change the
download command from 'hg' to 'git' and remove the need to
download any subtrees.

> Is there any way (which will stay stable, even when you?re going
> to move repositories *again*, to git) to split the download into
> what the old repositories have been, so I can still get my tarballs
> in the way the current packaging requires?
>

As I said above, our release tarballs have remained stable and will
continue to do so.

I might be able to help more if you can describe how you obtain
your tarballs.

> Otherwise I?d have to change things a lot, which will be tricky
> *and* time-consuming (and I?d have to ask $employer for more time
> than I can currently use for this).
> 
> I?d prefer best if you would just push the new releases also to
> the old repositories and tag them appropriately. But I understand
> chances for this going to happen are small as you seem to be very
> interested in this new-fangled git thingy :/
>

Well, yes, it would require applying every single patch to a different
set of repositories, including altering metadata and paths so they apply
to subrepositories. In other words, exactly the work we've made this
transition to try and reduce with patches from later JDK versions.

Recreating it just for building the source is considerably easier:

$ git clone -b jdk8u322-ga https://github.com/openjdk/jdk8u.git openjdk
$ mv openjdk/{corba,jaxp,jaxws,langtools,nashorn,jdk,hotspot} .
$ for repos in openjdk corba jaxp jaxws langtools nashorn jdk hotspot ; do
  tar cJf ${repos}.tar.xz ${repos}
  done

That will give you the original eight individual repository
tarballs. You can also replace the git clone step with just using the
release tarball instead.

> Thanks in advance,
> //mirabilos
> -- 
> Infrastrukturexperte ? tarent solutions GmbH
> Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
> Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
> HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
> Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
> 
>                         ****************************************************
> /?\ The UTF-8 Ribbon
> ??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
> ??? HTML eMail! Also,     https://www.tarent.de/newsletter
> ??? header encryption!
>                         ****************************************************
> 

[0] https://bitly.com/openjdk8u322
[1] https://bitly.com/openjdk8u312
[2] https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/c/1df9f60904f8e1ac182c80755a94cfca094e8844?branch=f35

Hope that helps,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From alexey at azul.com  Fri Feb  4 14:26:50 2022
From: alexey at azul.com (Alexey Bakhtin)
Date: Fri, 4 Feb 2022 14:26:50 +0000
Subject: [8u] RFR: 8245169: EncryptedPrivateKeyInfo incorrectly decodes KDF
 algorithm
Message-ID: <6C8D6AB8-391A-4391-A3FC-7770377F8204@azul.com>

JBS: https://bugs.openjdk.java.net/browse/JDK-8245169
Webrev: http://cr.openjdk.java.net/~abakhtin/8245169/webrev.0/

The supplied keystore does not have the optional key length field which leads to the parsing of KDF being skipped unexpectedly.
This issue is fixed by com/sun/crypto/provider/PBES2Parameters.java part of the JDK-8076190 [1] enhancement.
JDK-8076190 enhancement can not be applied to JDK8u, so this issue is fixed as a separate fix.

Tested by the test attached in the issue

Regards
Alexey

[1] - https://bugs.openjdk.java.net/browse/JDK-8076190

From t.glaser at tarent.de  Fri Feb  4 15:29:50 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Fri, 4 Feb 2022 16:29:50 +0100 (CET)
Subject: jdk8u322 release and packaging
In-Reply-To: <YfyqBUzqXBqZfl0a@hex.discworld.ac.uk>
References: <df7b8b73-9399-a796-c06b-325f74c75048@tarent.de>
 <YfyqBUzqXBqZfl0a@hex.discworld.ac.uk>
Message-ID: <ae8fba8-55eb-87c1-ec9d-6e2b9c4939b1@tarent.de>

Hi,

> Welcome to OpenJDK maintenance :-)

thanks ?

> Recreating it just for building the source is considerably easier:
> 
> $ git clone -b jdk8u322-ga https://github.com/openjdk/jdk8u.git openjdk
> $ mv openjdk/{corba,jaxp,jaxws,langtools,nashorn,jdk,hotspot} .
> $ for repos in openjdk corba jaxp jaxws langtools nashorn jdk hotspot ; do
>   tar cJf ${repos}.tar.xz ${repos}
>   done

OK, so the listed top-level directories under the monorepo *directly*
correspond to the old repositories, and the remainder of the monorepo
is the old ?root? repository?

> That will give you the original eight individual repository
> tarballs. You can also replace the git clone step with just using the
> release tarball instead.

Yeah, it?ll be a bit more complicated considering aarch32 and
aarch64-shenandoah? but this helps already. I still have no idea
what I?d do if either of these changes anything outside of hotspot?

Just doing 8 here; 11/17 are actively maintained by doko, and
7 has ended (ELTS supplies 8 instead).

bye,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://www.tarent.de/newsletter
??? header encryption!
                        ****************************************************

From mbalao at redhat.com  Sat Feb  5 01:41:03 2022
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 4 Feb 2022 20:41:03 -0500
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <CD703EE0-5CDC-4CF2-9835-81B1302DD3FB@azul.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
 <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
 <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>
 <CAKZz+gcub0-G2U-j=ARGdrLeeh4MnZqBHU84kGEHoepoV3L+9g@mail.gmail.com>
 <CD703EE0-5CDC-4CF2-9835-81B1302DD3FB@azul.com>
Message-ID: <CAKZz+gdOPTWjPSQmtmDRJn39ErrDBsWtd_1ngH0ULBv+N4CByw@mail.gmail.com>

Hi Alexey,

On Thu, Feb 3, 2022 at 3:29 PM Alexey Bakhtin <alexey at azul.com> wrote:

> Right now the password-less PKCS12 keystore feature is not critical for
> us. So, the fixes for the 8245169 would be OK for now.
> Thank you for discussion. I will prepare the patch for the JDK-8245169
> and send it for review
>

Thanks, that is appreciated. If circumstances change in the future, let me
know.

Martin.-

From mbalao at redhat.com  Sat Feb  5 02:27:59 2022
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 4 Feb 2022 21:27:59 -0500
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <09658B4B-DDFB-46CB-A48B-4262C3278453@azul.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
 <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
 <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>
 <CAKZz+gcub0-G2U-j=ARGdrLeeh4MnZqBHU84kGEHoepoV3L+9g@mail.gmail.com>
 <CD703EE0-5CDC-4CF2-9835-81B1302DD3FB@azul.com>
 <09658B4B-DDFB-46CB-A48B-4262C3278453@azul.com>
Message-ID: <CAKZz+gfvx1mbbZEx0coKckB2Zcn=7M7BnaW8B6yWBfLHUfUB2g@mail.gmail.com>

Hi Alexey,

On Thu, Feb 3, 2022 at 4:29 PM Alexey Bakhtin <alexey at azul.com> wrote:

> The issue described in the [1] is related to HmacPBESHA256 support in the
> PKCS12KeyStore. This issue is not covered by the JDK-8245169 but fixed by
> another part of  JDK-8076190
> Should it be considered as a separate issue with new Bug Id ? or should we
> fix altogether as a
> JDK-8076190 backport without password-less support ?
>
> [1] -
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014473.html


Hmm... The HmacPBESHA* part means introducing
'keystore.pkcs12.macAlgorithm' which can be, eventually, 'NONE'. If the
user invokes Keytool with 'storetype' equals to 'pkcs12',
'keystore.pkcs12.macAlgorithm=NONE' and SunJCE is handling that, it should
be fine to generate a new keystore without a Mac. Same for certificates and
keys probably. It looks to me that the real backward-compatibility breaker
is changing the 'storetype' based on the file, not the whole passwordless
thing. Perhaps we can skip those parts causing trouble and move forward
with the rest of it. I'll have a look again next week.

I suggest keeping this backport under 8076190.

Martin.-

From mbalao at redhat.com  Sat Feb  5 02:34:19 2022
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 4 Feb 2022 21:34:19 -0500
Subject: [8u] RFR: 8245169: EncryptedPrivateKeyInfo incorrectly decodes
 KDF algorithm
In-Reply-To: <6C8D6AB8-391A-4391-A3FC-7770377F8204@azul.com>
References: <6C8D6AB8-391A-4391-A3FC-7770377F8204@azul.com>
Message-ID: <CAKZz+gfaRGK6CSAFvvCKb0rvztnOscCE3X0cGQ87FipQo1mz-A@mail.gmail.com>

Hi Alexey,

Thanks for proposing this backport.

As said in [1], let me have a look at your 8076190 backport again
(Webrev.01) and see if we can cut through the parts that do not break
backward-compatibility -such as the 'storetype' setting on-the-fly-, and we
can get HMAC-SHA256, etc. support too.

Martin.-

--
[1] -
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-February/014547.html

On Fri, Feb 4, 2022 at 9:26 AM Alexey Bakhtin <alexey at azul.com> wrote:

> JBS: https://bugs.openjdk.java.net/browse/JDK-8245169
> Webrev: http://cr.openjdk.java.net/~abakhtin/8245169/webrev.0/
>
> The supplied keystore does not have the optional key length field which
> leads to the parsing of KDF being skipped unexpectedly.
> This issue is fixed by com/sun/crypto/provider/PBES2Parameters.java part
> of the JDK-8076190 [1] enhancement.
> JDK-8076190 enhancement can not be applied to JDK8u, so this issue is
> fixed as a separate fix.
>
> Tested by the test attached in the issue
>
> Regards
> Alexey
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8076190
>

From mbalao at redhat.com  Tue Feb  8 05:18:21 2022
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 8 Feb 2022 00:18:21 -0500
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <CAKZz+gfvx1mbbZEx0coKckB2Zcn=7M7BnaW8B6yWBfLHUfUB2g@mail.gmail.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
 <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
 <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>
 <CAKZz+gcub0-G2U-j=ARGdrLeeh4MnZqBHU84kGEHoepoV3L+9g@mail.gmail.com>
 <CD703EE0-5CDC-4CF2-9835-81B1302DD3FB@azul.com>
 <09658B4B-DDFB-46CB-A48B-4262C3278453@azul.com>
 <CAKZz+gfvx1mbbZEx0coKckB2Zcn=7M7BnaW8B6yWBfLHUfUB2g@mail.gmail.com>
Message-ID: <CAKZz+gcpeQrhZR=SjHhddbMrwcCXFa=dBkK0cX8VaovugGFfgw@mail.gmail.com>

Hi Alexey,

I've gone through this 8u backport again and made some changes:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8076190/8076190.webrev.8u.02/

This is the assessment for each non-test file modified:

 * src/share/classes/com/sun/crypto/provider/PBES2Parameters.java
  * Ok. Applies cleanly and fixes an actual bug when keyLength is not
specified (the field is marked as optional in the RFC).

 * src/share/classes/com/sun/crypto/provider/SunJCE.java
  * Ok. Adaptations necessary to 8u's way of registering services. All of
them are consistent to changes in 11u.

 * src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
  * Ok. Extended to handle a variable number of iterations for PBE
algorithms and custom MAC and Cipher algorithms (which includes NONE).
   * 8u new behavior
    * When loading a store, the certProtectionAlgorithm value comes from
the last encrypted certificate bag (contentType ==
ContentInfo.ENCRYPTED_DATA_OID). If certificates are seen but no encrypted
bags, certProtectionAlgorithm = "NONE". If the keystore is new or no
certificates are seen, a default value for certProtectionAlgorithm is used
when storing.
    * When loading a store, the macAlgorithm value comes from the
(optional) MacData section of the PKCS#12 keystore if a password was
provided. If no MacData section is available, then macAlgorithm = "NONE".
If there is a MacData section but a password was not provided to load
(notice that passwords when loading are optional), a default macAlgorithm
value will be used later when storing. If the keystore is new, a default
value for macAlgorithm is used when storing.
    * certProtectionAlgorithm and macAlgorithm values are set when loading,
or set to default values otherwise, and can be overwritten when storing by
means of System/Security properties.
    * certProtectionAlgorithm and macAlgorithm values that are set to NONE
do not enable data encryption or authentication when storing.
   * In my view, all these changes provide an extension of what was
previously supported in a way that is acceptable for backward-compatibility.
    * Note: creating a new passwordless keystore and trying to open it with
a previous 8u release won't work, but that is fine.
  * Removed the function to detect PKCS#12 keystores based on the file. My
proposal is not to change 8u Keytool behavior to enable this capability.
See below.

 * src/share/classes/sun/security/tools/keytool/Main.java
  * This is how my 8u proposal differs from 11u:
   * In 11u, when 'storetype' is not set, it's detected based on the file
if a file is provided. This is not fundamental to 8076190 and it's not a
natural fit because the engine probe API is not available. This is where I
had backward-compatibility concerns in Webrev.00 and 01.
   * 8u will only decide passworless status if 'storetype' is set to
case-insensitive 'pkcs12' (either by Keytool parameter explicitly or taken
from the keystore.type security property) AND if the security provider in
use is SunJCE.
    * The behavior for non-SunJCE security providers using case-insensitive
'pkcs12' algorithm name remains unchanged. They will not take advantage of
this but they will not be broken if they were not supporting passwordless
keystores.
    * If there is an existing keystore, SunJCE's PKCS12KeyStore will be
used to check passwordless status.
    * If there is not an existing keystore, passwordless status is taken
from the
keystore.pkcs12.certProtectionAlgorithm/keystore.pkcs12.macAlgorithm
properties.
    * passwordless status matters to Keytool for checks, asking for
passwords and warnings.
  * The rest of it looks good to me.

 * src/share/classes/sun/security/x509/AlgorithmId.java
  * Ok

 * src/share/lib/security/java.security-*
  * Ok

 * src/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java
  * Ok

 * src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java
  * Ok

 * src/java.base/share/classes/java/security/KeyStore.java
  * Ok, no probing in 8u.

Tests:

 * test/sun/security/pkcs12/ParamsPreferences.java
  * Ok

 * test/sun/security/pkcs12/ParamsTest.java
  * @Alexey, can you please elaborate on why there are differences in
'.shouldContain("Enter key password for <a>")' and '.shouldContain("Enter
key password for <b>")' ?
  * Not passing.

 * test/sun/security/pkcs12/params/README
  * Ok

 * test/sun/security/pkcs12/params/kandc
  * Ok

 * test/sun/security/pkcs12/params/ks
  * Ok

 * test/sun/security/pkcs12/params/os2
  * Ok

 * test/sun/security/pkcs12/params/os3
  * Ok

 * test/sun/security/pkcs12/params/os4
  * Ok

 * test/sun/security/pkcs12/params/os5
  * Ok

 * test/jdk/sun/security/tools/keytool/ProbingFailure.java
  * Ok, no probing in 8u.

@Alexey:

 * Can you please review and fully test this proposal?
  * I've only tested 'sun/security/pkcs12' category, observing 1 failure in
'test/sun/security/pkcs12/ParamsTest.java' (see below)
  * I'm particularly interested in testing sun/security/tools/keytool

 * Can you please have a look at my
'test/sun/security/pkcs12/ParamsTest.java' comment above and make the
changes necessary for this test to pass?

 * Can you please write a CSR for 8u based on the 11u one but describing
the differences (Keytool)?

Thanks,
Martin.-



On Fri, Feb 4, 2022 at 9:27 PM Martin Balao <mbalao at redhat.com> wrote:

> Hi Alexey,
>
> On Thu, Feb 3, 2022 at 4:29 PM Alexey Bakhtin <alexey at azul.com> wrote:
>
>> The issue described in the [1] is related to HmacPBESHA256 support in the
>> PKCS12KeyStore. This issue is not covered by the JDK-8245169 but fixed by
>> another part of  JDK-8076190
>> Should it be considered as a separate issue with new Bug Id ? or should
>> we fix altogether as a
>> JDK-8076190 backport without password-less support ?
>>
>> [1] -
>> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014473.html
>
>
> Hmm... The HmacPBESHA* part means introducing
> 'keystore.pkcs12.macAlgorithm' which can be, eventually, 'NONE'. If the
> user invokes Keytool with 'storetype' equals to 'pkcs12',
> 'keystore.pkcs12.macAlgorithm=NONE' and SunJCE is handling that, it should
> be fine to generate a new keystore without a Mac. Same for certificates and
> keys probably. It looks to me that the real backward-compatibility breaker
> is changing the 'storetype' based on the file, not the whole passwordless
> thing. Perhaps we can skip those parts causing trouble and move forward
> with the rest of it. I'll have a look again next week.
>
> I suggest keeping this backport under 8076190.
>
> Martin.-
>
>

From tianshuang.me at qq.com  Tue Feb  8 07:26:27 2022
From: tianshuang.me at qq.com (=?ISO-8859-1?B?UG9pc29u?=)
Date: Tue, 8 Feb 2022 15:26:27 +0800
Subject: About the perfInit() method in LinuxOperatingSystem.c
Message-ID: <tencent_670E5BFD49A2416225C1E339C988ED0DAF07@qq.com>

In JDK8 com.sun.management.OperatingSystemMXBean#getSystemCpuLoad, when the operating system is Linux, the perfInit() method will be called for initialization, but will the initialized variable cause the code in the if block to not be executed?


Source code(https://github.com/openjdk/jdk/blob/jdk8-b120/jdk/src/solaris/native/sun/management/LinuxOperatingSystem.c#L193): 
/**
&nbsp;* This method must be called first, before any data can be gathererd.
&nbsp;*/
int perfInit() {
&nbsp; &nbsp; static int initialized=1;


&nbsp; &nbsp; if (!initialized) {
&nbsp; &nbsp; &nbsp; &nbsp; int&nbsp; i;


&nbsp; &nbsp; &nbsp; &nbsp; int n = sysconf(_SC_NPROCESSORS_ONLN);
&nbsp; &nbsp; &nbsp; &nbsp; if (n <= 0) {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; n = 1;
&nbsp; &nbsp; &nbsp; &nbsp; }


&nbsp; &nbsp; &nbsp; &nbsp; counters.cpus = calloc(n,sizeof(ticks));
&nbsp; &nbsp; &nbsp; &nbsp; if (counters.cpus != NULL)&nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; // For the CPU load
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; get_totalticks(-1, &amp;counters.cpuTicks);


&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; for (i = 0; i < n; i++) {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; get_totalticks(i, &amp;counters.cpus[i]);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; // For JVM load
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; get_jvmticks(&amp;counters.jvmTicks);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; initialized = 1;
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; }


&nbsp; &nbsp; return initialized ? 0 : -1;
}



Thanks.

From shade at redhat.com  Tue Feb  8 07:44:12 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 8 Feb 2022 10:44:12 +0300
Subject: About the perfInit() method in LinuxOperatingSystem.c
In-Reply-To: <tencent_670E5BFD49A2416225C1E339C988ED0DAF07@qq.com>
References: <tencent_670E5BFD49A2416225C1E339C988ED0DAF07@qq.com>
Message-ID: <f55d891e-b788-9c24-e0da-fb39d8a70181@redhat.com>

On 2/8/22 10:26, Poison wrote:
> In JDK8 com.sun.management.OperatingSystemMXBean#getSystemCpuLoad, when the operating system 
> isLinux, the perfInit() method will be called for initialization, but will the initialized 
> variable cause the code in the if block to not be executed?
Yes, but that problem was fixed as part of:
   8226575: OperatingSystemMXBean should be made container aware

...which was backported to 8u272.

Here it is in 8u tip:
 
https://github.com/openjdk/jdk8u/blob/8d5c7386c619a2602d9731c4adbbb1b01aeb449f/jdk/src/solaris/native/sun/management/LinuxOperatingSystem.c#L202-L204

-- 
Thanks,
-Aleksey


From alexey at azul.com  Tue Feb  8 14:05:15 2022
From: alexey at azul.com (Alexey Bakhtin)
Date: Tue, 8 Feb 2022 14:05:15 +0000
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <CAKZz+gcpeQrhZR=SjHhddbMrwcCXFa=dBkK0cX8VaovugGFfgw@mail.gmail.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
 <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
 <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>
 <CAKZz+gcub0-G2U-j=ARGdrLeeh4MnZqBHU84kGEHoepoV3L+9g@mail.gmail.com>
 <CD703EE0-5CDC-4CF2-9835-81B1302DD3FB@azul.com>
 <09658B4B-DDFB-46CB-A48B-4262C3278453@azul.com>
 <CAKZz+gfvx1mbbZEx0coKckB2Zcn=7M7BnaW8B6yWBfLHUfUB2g@mail.gmail.com>
 <CAKZz+gcpeQrhZR=SjHhddbMrwcCXFa=dBkK0cX8VaovugGFfgw@mail.gmail.com>
Message-ID: <24775ADC-D776-4485-B24E-27A3CD02662C@azul.com>

Hello Martin,

Thank you a lot for detailed review, description and new proposal.
The changes are OK for me except of PKCS12 keystore provider.
Right now PKCS12 Keystore is defined in the SunJSSE provider only (not SunJCE):
* https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/7fcf35286d52/src/share/classes/sun/security/ssl/SunJSSE.java#l233 <https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/7fcf35286d52/src/share/classes/sun/security/ssl/SunJSSE.java#l233>
I was thinking to add PKCS12 into the SUN provider similar to JDK11+  but it could affect custom providers with PKCS12 support ( PKCS12 keystore implementation could be changed because of high SUN provider priority)

Also I have updated sun/security/pkcs12/ParamsTest.java test to explicitly specify PKCS12 storetype for passwordless keystores.
All sun/security/pkcs12 and sun/security/tools/keytool tests are passed

New version of the patch is available at :
https://cr.openjdk.java.net/~abakhtin/8076190_8u/webrev.v3 <https://cr.openjdk.java.net/~abakhtin/8076190_8u/webrev.v3>


Regards
Alexey


> On 8 Feb 2022, at 08:18, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Alexey,
> 
> I've gone through this 8u backport again and made some changes:
> 
>  * http://cr.openjdk.java.net/~mbalao/webrevs/8076190/8076190.webrev.8u.02/ <http://cr.openjdk.java.net/~mbalao/webrevs/8076190/8076190.webrev.8u.02/>
> 
> This is the assessment for each non-test file modified:
> 
>  * src/share/classes/com/sun/crypto/provider/PBES2Parameters.java
>   * Ok. Applies cleanly and fixes an actual bug when keyLength is not specified (the field is marked as optional in the RFC).
> 
>  * src/share/classes/com/sun/crypto/provider/SunJCE.java
>   * Ok. Adaptations necessary to 8u's way of registering services. All of them are consistent to changes in 11u.
> 
>  * src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
>   * Ok. Extended to handle a variable number of iterations for PBE algorithms and custom MAC and Cipher algorithms (which includes NONE).
>    * 8u new behavior
>     * When loading a store, the certProtectionAlgorithm value comes from the last encrypted certificate bag (contentType == ContentInfo.ENCRYPTED_DATA_OID). If certificates are seen but no encrypted bags, certProtectionAlgorithm = "NONE". If the keystore is new or no certificates are seen, a default value for certProtectionAlgorithm is used when storing.
>     * When loading a store, the macAlgorithm value comes from the (optional) MacData section of the PKCS#12 keystore if a password was provided. If no MacData section is available, then macAlgorithm = "NONE". If there is a MacData section but a password was not provided to load (notice that passwords when loading are optional), a default macAlgorithm value will be used later when storing. If the keystore is new, a default value for macAlgorithm is used when storing.
>     * certProtectionAlgorithm and macAlgorithm values are set when loading, or set to default values otherwise, and can be overwritten when storing by means of System/Security properties.
>     * certProtectionAlgorithm and macAlgorithm values that are set to NONE do not enable data encryption or authentication when storing.
>    * In my view, all these changes provide an extension of what was previously supported in a way that is acceptable for backward-compatibility.
>     * Note: creating a new passwordless keystore and trying to open it with a previous 8u release won't work, but that is fine.
>   * Removed the function to detect PKCS#12 keystores based on the file. My proposal is not to change 8u Keytool behavior to enable this capability. See below.
> 
>  * src/share/classes/sun/security/tools/keytool/Main.java
>   * This is how my 8u proposal differs from 11u:
>    * In 11u, when 'storetype' is not set, it's detected based on the file if a file is provided. This is not fundamental to 8076190 and it's not a natural fit because the engine probe API is not available. This is where I had backward-compatibility concerns in Webrev.00 and 01.
>    * 8u will only decide passworless status if 'storetype' is set to case-insensitive 'pkcs12' (either by Keytool parameter explicitly or taken from the keystore.type security property) AND if the security provider in use is SunJCE.
>     * The behavior for non-SunJCE security providers using case-insensitive 'pkcs12' algorithm name remains unchanged. They will not take advantage of this but they will not be broken if they were not supporting passwordless keystores.
>     * If there is an existing keystore, SunJCE's PKCS12KeyStore will be used to check passwordless status.
>     * If there is not an existing keystore, passwordless status is taken from the keystore.pkcs12.certProtectionAlgorithm/keystore.pkcs12.macAlgorithm properties.
>     * passwordless status matters to Keytool for checks, asking for passwords and warnings.
>   * The rest of it looks good to me.
> 
>  * src/share/classes/sun/security/x509/AlgorithmId.java
>   * Ok
> 
>  * src/share/lib/security/java.security-*
>   * Ok
> 
>  * src/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java
>   * Ok
> 
>  * src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java
>   * Ok
> 
>  * src/java.base/share/classes/java/security/KeyStore.java
>   * Ok, no probing in 8u.
> 
> Tests:
> 
>  * test/sun/security/pkcs12/ParamsPreferences.java
>   * Ok
> 
>  * test/sun/security/pkcs12/ParamsTest.java
>   * @Alexey, can you please elaborate on why there are differences in '.shouldContain("Enter key password for <a>")' and '.shouldContain("Enter key password for <b>")' ?
>   * Not passing.
> 
>  * test/sun/security/pkcs12/params/README
>   * Ok
> 
>  * test/sun/security/pkcs12/params/kandc
>   * Ok
> 
>  * test/sun/security/pkcs12/params/ks
>   * Ok
> 
>  * test/sun/security/pkcs12/params/os2
>   * Ok
> 
>  * test/sun/security/pkcs12/params/os3
>   * Ok
> 
>  * test/sun/security/pkcs12/params/os4
>   * Ok
> 
>  * test/sun/security/pkcs12/params/os5
>   * Ok
> 
>  * test/jdk/sun/security/tools/keytool/ProbingFailure.java
>   * Ok, no probing in 8u.
> 
> @Alexey:
> 
>  * Can you please review and fully test this proposal?
>   * I've only tested 'sun/security/pkcs12' category, observing 1 failure in 'test/sun/security/pkcs12/ParamsTest.java' (see below)
>   * I'm particularly interested in testing sun/security/tools/keytool
> 
>  * Can you please have a look at my 'test/sun/security/pkcs12/ParamsTest.java' comment above and make the changes necessary for this test to pass?
> 
>  * Can you please write a CSR for 8u based on the 11u one but describing the differences (Keytool)?
> 
> Thanks,
> Martin.-
> 
> 
> 
> On Fri, Feb 4, 2022 at 9:27 PM Martin Balao <mbalao at redhat.com <mailto:mbalao at redhat.com>> wrote:
> Hi Alexey,
> 
> On Thu, Feb 3, 2022 at 4:29 PM Alexey Bakhtin <alexey at azul.com <mailto:alexey at azul.com>> wrote:
> The issue described in the [1] is related to HmacPBESHA256 support in the PKCS12KeyStore. This issue is not covered by the JDK-8245169 but fixed by another part of  JDK-8076190
> Should it be considered as a separate issue with new Bug Id ? or should we fix altogether as a
> JDK-8076190 backport without password-less support ?
> 
> [1] -  https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014473.html <https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014473.html>
> 
> Hmm... The HmacPBESHA* part means introducing 'keystore.pkcs12.macAlgorithm' which can be, eventually, 'NONE'. If the user invokes Keytool with 'storetype' equals to 'pkcs12', 'keystore.pkcs12.macAlgorithm=NONE' and SunJCE is handling that, it should be fine to generate a new keystore without a Mac. Same for certificates and keys probably. It looks to me that the real backward-compatibility breaker is changing the 'storetype' based on the file, not the whole passwordless thing. Perhaps we can skip those parts causing trouble and move forward with the rest of it. I'll have a look again next week.
> 
> I suggest keeping this backport under 8076190.
> 
> Martin.-
> 


From alexey at azul.com  Tue Feb  8 15:06:54 2022
From: alexey at azul.com (Alexey Bakhtin)
Date: Tue, 8 Feb 2022 15:06:54 +0000
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <24775ADC-D776-4485-B24E-27A3CD02662C@azul.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
 <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
 <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>
 <CAKZz+gcub0-G2U-j=ARGdrLeeh4MnZqBHU84kGEHoepoV3L+9g@mail.gmail.com>
 <CD703EE0-5CDC-4CF2-9835-81B1302DD3FB@azul.com>
 <09658B4B-DDFB-46CB-A48B-4262C3278453@azul.com>
 <CAKZz+gfvx1mbbZEx0coKckB2Zcn=7M7BnaW8B6yWBfLHUfUB2g@mail.gmail.com>
 <CAKZz+gcpeQrhZR=SjHhddbMrwcCXFa=dBkK0cX8VaovugGFfgw@mail.gmail.com>
 <24775ADC-D776-4485-B24E-27A3CD02662C@azul.com>
Message-ID: <F4077B0D-98AF-4AEF-BD6A-107997390F3A@azul.com>

The CSR for the JDK-8076190 is updated with the section, describing the differences from JDK11.

CSR: https://bugs.openjdk.java.net/browse/JDK-8267040 <https://bugs.openjdk.java.net/browse/JDK-8267040>

Regards
Alexey

> On 8 Feb 2022, at 17:05, Alexey Bakhtin <alexey at azul.com> wrote:
> 
> Hello Martin,
> 
> Thank you a lot for detailed review, description and new proposal.
> The changes are OK for me except of PKCS12 keystore provider.
> Right now PKCS12 Keystore is defined in the SunJSSE provider only (not SunJCE):
> * https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/7fcf35286d52/src/share/classes/sun/security/ssl/SunJSSE.java#l233 <https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/7fcf35286d52/src/share/classes/sun/security/ssl/SunJSSE.java#l233>
> I was thinking to add PKCS12 into the SUN provider similar to JDK11+  but it could affect custom providers with PKCS12 support ( PKCS12 keystore implementation could be changed because of high SUN provider priority)
> 
> Also I have updated sun/security/pkcs12/ParamsTest.java test to explicitly specify PKCS12 storetype for passwordless keystores.
> All sun/security/pkcs12 and sun/security/tools/keytool tests are passed
> 
> New version of the patch is available at :
> https://cr.openjdk.java.net/~abakhtin/8076190_8u/webrev.v3 <https://cr.openjdk.java.net/~abakhtin/8076190_8u/webrev.v3>
> 
> 
> Regards
> Alexey
> 
> 
>> On 8 Feb 2022, at 08:18, Martin Balao <mbalao at redhat.com> wrote:
>> 
>> Hi Alexey,
>> 
>> I've gone through this 8u backport again and made some changes:
>> 
>> * http://cr.openjdk.java.net/~mbalao/webrevs/8076190/8076190.webrev.8u.02/ <http://cr.openjdk.java.net/~mbalao/webrevs/8076190/8076190.webrev.8u.02/>
>> 
>> This is the assessment for each non-test file modified:
>> 
>> * src/share/classes/com/sun/crypto/provider/PBES2Parameters.java
>>  * Ok. Applies cleanly and fixes an actual bug when keyLength is not specified (the field is marked as optional in the RFC).
>> 
>> * src/share/classes/com/sun/crypto/provider/SunJCE.java
>>  * Ok. Adaptations necessary to 8u's way of registering services. All of them are consistent to changes in 11u.
>> 
>> * src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
>>  * Ok. Extended to handle a variable number of iterations for PBE algorithms and custom MAC and Cipher algorithms (which includes NONE).
>>   * 8u new behavior
>>    * When loading a store, the certProtectionAlgorithm value comes from the last encrypted certificate bag (contentType == ContentInfo.ENCRYPTED_DATA_OID). If certificates are seen but no encrypted bags, certProtectionAlgorithm = "NONE". If the keystore is new or no certificates are seen, a default value for certProtectionAlgorithm is used when storing.
>>    * When loading a store, the macAlgorithm value comes from the (optional) MacData section of the PKCS#12 keystore if a password was provided. If no MacData section is available, then macAlgorithm = "NONE". If there is a MacData section but a password was not provided to load (notice that passwords when loading are optional), a default macAlgorithm value will be used later when storing. If the keystore is new, a default value for macAlgorithm is used when storing.
>>    * certProtectionAlgorithm and macAlgorithm values are set when loading, or set to default values otherwise, and can be overwritten when storing by means of System/Security properties.
>>    * certProtectionAlgorithm and macAlgorithm values that are set to NONE do not enable data encryption or authentication when storing.
>>   * In my view, all these changes provide an extension of what was previously supported in a way that is acceptable for backward-compatibility.
>>    * Note: creating a new passwordless keystore and trying to open it with a previous 8u release won't work, but that is fine.
>>  * Removed the function to detect PKCS#12 keystores based on the file. My proposal is not to change 8u Keytool behavior to enable this capability. See below.
>> 
>> * src/share/classes/sun/security/tools/keytool/Main.java
>>  * This is how my 8u proposal differs from 11u:
>>   * In 11u, when 'storetype' is not set, it's detected based on the file if a file is provided. This is not fundamental to 8076190 and it's not a natural fit because the engine probe API is not available. This is where I had backward-compatibility concerns in Webrev.00 and 01.
>>   * 8u will only decide passworless status if 'storetype' is set to case-insensitive 'pkcs12' (either by Keytool parameter explicitly or taken from the keystore.type security property) AND if the security provider in use is SunJCE.
>>    * The behavior for non-SunJCE security providers using case-insensitive 'pkcs12' algorithm name remains unchanged. They will not take advantage of this but they will not be broken if they were not supporting passwordless keystores.
>>    * If there is an existing keystore, SunJCE's PKCS12KeyStore will be used to check passwordless status.
>>    * If there is not an existing keystore, passwordless status is taken from the keystore.pkcs12.certProtectionAlgorithm/keystore.pkcs12.macAlgorithm properties.
>>    * passwordless status matters to Keytool for checks, asking for passwords and warnings.
>>  * The rest of it looks good to me.
>> 
>> * src/share/classes/sun/security/x509/AlgorithmId.java
>>  * Ok
>> 
>> * src/share/lib/security/java.security-*
>>  * Ok
>> 
>> * src/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java
>>  * Ok
>> 
>> * src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java
>>  * Ok
>> 
>> * src/java.base/share/classes/java/security/KeyStore.java
>>  * Ok, no probing in 8u.
>> 
>> Tests:
>> 
>> * test/sun/security/pkcs12/ParamsPreferences.java
>>  * Ok
>> 
>> * test/sun/security/pkcs12/ParamsTest.java
>>  * @Alexey, can you please elaborate on why there are differences in '.shouldContain("Enter key password for <a>")' and '.shouldContain("Enter key password for <b>")' ?
>>  * Not passing.
>> 
>> * test/sun/security/pkcs12/params/README
>>  * Ok
>> 
>> * test/sun/security/pkcs12/params/kandc
>>  * Ok
>> 
>> * test/sun/security/pkcs12/params/ks
>>  * Ok
>> 
>> * test/sun/security/pkcs12/params/os2
>>  * Ok
>> 
>> * test/sun/security/pkcs12/params/os3
>>  * Ok
>> 
>> * test/sun/security/pkcs12/params/os4
>>  * Ok
>> 
>> * test/sun/security/pkcs12/params/os5
>>  * Ok
>> 
>> * test/jdk/sun/security/tools/keytool/ProbingFailure.java
>>  * Ok, no probing in 8u.
>> 
>> @Alexey:
>> 
>> * Can you please review and fully test this proposal?
>>  * I've only tested 'sun/security/pkcs12' category, observing 1 failure in 'test/sun/security/pkcs12/ParamsTest.java' (see below)
>>  * I'm particularly interested in testing sun/security/tools/keytool
>> 
>> * Can you please have a look at my 'test/sun/security/pkcs12/ParamsTest.java' comment above and make the changes necessary for this test to pass?
>> 
>> * Can you please write a CSR for 8u based on the 11u one but describing the differences (Keytool)?
>> 
>> Thanks,
>> Martin.-
>> 
>> 
>> 
>> On Fri, Feb 4, 2022 at 9:27 PM Martin Balao <mbalao at redhat.com <mailto:mbalao at redhat.com>> wrote:
>> Hi Alexey,
>> 
>> On Thu, Feb 3, 2022 at 4:29 PM Alexey Bakhtin <alexey at azul.com <mailto:alexey at azul.com>> wrote:
>> The issue described in the [1] is related to HmacPBESHA256 support in the PKCS12KeyStore. This issue is not covered by the JDK-8245169 but fixed by another part of  JDK-8076190
>> Should it be considered as a separate issue with new Bug Id ? or should we fix altogether as a
>> JDK-8076190 backport without password-less support ?
>> 
>> [1] -  https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014473.html <https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014473.html>
>> 
>> Hmm... The HmacPBESHA* part means introducing 'keystore.pkcs12.macAlgorithm' which can be, eventually, 'NONE'. If the user invokes Keytool with 'storetype' equals to 'pkcs12', 'keystore.pkcs12.macAlgorithm=NONE' and SunJCE is handling that, it should be fine to generate a new keystore without a Mac. Same for certificates and keys probably. It looks to me that the real backward-compatibility breaker is changing the 'storetype' based on the file, not the whole passwordless thing. Perhaps we can skip those parts causing trouble and move forward with the rest of it. I'll have a look again next week.
>> 
>> I suggest keeping this backport under 8076190.
>> 
>> Martin.-
>> 
> 


From mbalao at redhat.com  Tue Feb  8 15:12:34 2022
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 8 Feb 2022 10:12:34 -0500
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <24775ADC-D776-4485-B24E-27A3CD02662C@azul.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
 <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
 <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>
 <CAKZz+gcub0-G2U-j=ARGdrLeeh4MnZqBHU84kGEHoepoV3L+9g@mail.gmail.com>
 <CD703EE0-5CDC-4CF2-9835-81B1302DD3FB@azul.com>
 <09658B4B-DDFB-46CB-A48B-4262C3278453@azul.com>
 <CAKZz+gfvx1mbbZEx0coKckB2Zcn=7M7BnaW8B6yWBfLHUfUB2g@mail.gmail.com>
 <CAKZz+gcpeQrhZR=SjHhddbMrwcCXFa=dBkK0cX8VaovugGFfgw@mail.gmail.com>
 <24775ADC-D776-4485-B24E-27A3CD02662C@azul.com>
Message-ID: <CAKZz+ge7OGmRgioGK4w7NDLKoNCTo5XTgKRxcQnYogmGxjwyvA@mail.gmail.com>

Hi Alexey,

Thanks for your new proposal.

On Tue, Feb 8, 2022 at 9:05 AM Alexey Bakhtin <alexey at azul.com> wrote:

> The changes are OK for me except of PKCS12 keystore provider.
> Right now PKCS12 Keystore is defined in the SunJSSE provider only (not
> SunJCE):
> *
> https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/7fcf35286d52/src/share/classes/sun/security/ssl/SunJSSE.java#l233
>

Yes, you are right in that it's not SunJCE but SunJSSE.

Just for the record, PKCS#12 keystores can be handled by SUN as part of the
dual-format support. SUN does not register its KeyStore services for the
algorithm "PKCS12" but for "JKS". My understanding is, thus, that Keytool
won't support the passwordless feature in those because 'storetype' (which
is used for KeyStore.getInstance(storetype,...)) is checked to be "PKCS12"
(case-insensitive).

I was thinking to add PKCS12 into the SUN provider similar to JDK11+  but
> it could affect custom providers with PKCS12 support ( PKCS12 keystore
> implementation could be changed because of high SUN provider priority)
>

I'd suggest no changes there for the same reason.


>
> Also I have updated sun/security/pkcs12/ParamsTest.java test to explicitly
> specify PKCS12 storetype for passwordless keystores.
> All sun/security/pkcs12 and sun/security/tools/keytool tests are passed
>

Thanks, but I still have the previous question regarding changes in the
assertions. In particular, 11u checks the following:

+        // -importkeystore prompts for srckeypass
+        SecurityTools.setResponse("changeit", "changeit");
+        keytool("-importkeystore -srckeystore ksnopass "
+                + "-destkeystore jks3 -deststorepass changeit")
+                .shouldContain("Enter key password for <a>")
+                .shouldContain("Enter key password for <b>")
+                .shouldContain("2 entries successfully imported");

Apparently, ".shouldContain("Enter key password for <a>")" and
".shouldContain("Enter key password for <b>")" were removed in 8u backport.
Why?

The same here:

+        // -importkeystore prompts for srckeypass for private keys
+        // and no prompt for certs
+        SecurityTools.setResponse("changeit", "changeit");
+        keytool("-importkeystore -srckeystore ksnopass2 "
+                + "-destkeystore jks5 -deststorepass changeit")
+                .shouldContain("Enter key password for <a>")
+                .shouldContain("Enter key password for <b>")
+                .shouldNotContain("Enter key password for <aa>")
+                .shouldNotContain("Enter key password for <bb>")
+                .shouldContain("4 entries successfully imported");

".shouldContain("Enter key password for <a>")" and ".shouldContain("Enter
key password for <b>")" were removed. Why?

Best,
Martin.-

From alexey at azul.com  Tue Feb  8 15:50:47 2022
From: alexey at azul.com (Alexey Bakhtin)
Date: Tue, 8 Feb 2022 15:50:47 +0000
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <CAKZz+ge7OGmRgioGK4w7NDLKoNCTo5XTgKRxcQnYogmGxjwyvA@mail.gmail.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
 <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
 <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>
 <CAKZz+gcub0-G2U-j=ARGdrLeeh4MnZqBHU84kGEHoepoV3L+9g@mail.gmail.com>
 <CD703EE0-5CDC-4CF2-9835-81B1302DD3FB@azul.com>
 <09658B4B-DDFB-46CB-A48B-4262C3278453@azul.com>
 <CAKZz+gfvx1mbbZEx0coKckB2Zcn=7M7BnaW8B6yWBfLHUfUB2g@mail.gmail.com>
 <CAKZz+gcpeQrhZR=SjHhddbMrwcCXFa=dBkK0cX8VaovugGFfgw@mail.gmail.com>
 <24775ADC-D776-4485-B24E-27A3CD02662C@azul.com>
 <CAKZz+ge7OGmRgioGK4w7NDLKoNCTo5XTgKRxcQnYogmGxjwyvA@mail.gmail.com>
Message-ID: <F9CABA8C-C564-4D47-915A-7DF5CD633B8B@azul.com>

Hi Martin,

Thank you for test findings.
These commands missed ?-srcstoretype PKCS12? and were checked incorrectly.
I?ve added ?-srcstoretype PKCS12? and reverted original assertions. Test passed.
Now all assertions in the 8u version are identical to the 11u version of the ParamsTest.java.
The only test difference is explicit specification of the src/dststoretype PKCS12

New webrev: https://cr.openjdk.java.net/~abakhtin/8076190_8u/webrev.v4/ <https://cr.openjdk.java.net/~abakhtin/8076190_8u/webrev.v4/>

Regards
Alexey

> On 8 Feb 2022, at 18:12, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Alexey,
> 
> Thanks for your new proposal.
> 
> On Tue, Feb 8, 2022 at 9:05 AM Alexey Bakhtin <alexey at azul.com <mailto:alexey at azul.com>> wrote:
> The changes are OK for me except of PKCS12 keystore provider.
> Right now PKCS12 Keystore is defined in the SunJSSE provider only (not SunJCE):
> * https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/7fcf35286d52/src/share/classes/sun/security/ssl/SunJSSE.java#l233 <https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/7fcf35286d52/src/share/classes/sun/security/ssl/SunJSSE.java#l233>
> 
> Yes, you are right in that it's not SunJCE but SunJSSE.
> 
> Just for the record, PKCS#12 keystores can be handled by SUN as part of the dual-format support. SUN does not register its KeyStore services for the algorithm "PKCS12" but for "JKS". My understanding is, thus, that Keytool won't support the passwordless feature in those because 'storetype' (which is used for KeyStore.getInstance(storetype,...)) is checked to be "PKCS12" (case-insensitive).
> 
> I was thinking to add PKCS12 into the SUN provider similar to JDK11+  but it could affect custom providers with PKCS12 support ( PKCS12 keystore implementation could be changed because of high SUN provider priority)
> 
> I'd suggest no changes there for the same reason.
> 
> 
> Also I have updated sun/security/pkcs12/ParamsTest.java test to explicitly specify PKCS12 storetype for passwordless keystores.
> All sun/security/pkcs12 and sun/security/tools/keytool tests are passed
> 
> Thanks, but I still have the previous question regarding changes in the assertions. In particular, 11u checks the following:
> 
> +        // -importkeystore prompts for srckeypass
> +        SecurityTools.setResponse("changeit", "changeit");
> +        keytool("-importkeystore -srckeystore ksnopass "
> +                + "-destkeystore jks3 -deststorepass changeit")
> +                .shouldContain("Enter key password for <a>")
> +                .shouldContain("Enter key password for <b>")
> +                .shouldContain("2 entries successfully imported");
> 
> Apparently, ".shouldContain("Enter key password for <a>")" and ".shouldContain("Enter key password for <b>")" were removed in 8u backport. Why?
> 
> The same here:
> 
> +        // -importkeystore prompts for srckeypass for private keys
> +        // and no prompt for certs
> +        SecurityTools.setResponse("changeit", "changeit");
> +        keytool("-importkeystore -srckeystore ksnopass2 "
> +                + "-destkeystore jks5 -deststorepass changeit")
> +                .shouldContain("Enter key password for <a>")
> +                .shouldContain("Enter key password for <b>")
> +                .shouldNotContain("Enter key password for <aa>")
> +                .shouldNotContain("Enter key password for <bb>")
> +                .shouldContain("4 entries successfully imported");
> 
> ".shouldContain("Enter key password for <a>")" and ".shouldContain("Enter key password for <b>")" were removed. Why?
> 
> Best,
> Martin.-
> 


From mbalao at redhat.com  Tue Feb  8 16:23:47 2022
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 8 Feb 2022 11:23:47 -0500
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <F9CABA8C-C564-4D47-915A-7DF5CD633B8B@azul.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
 <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
 <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>
 <CAKZz+gcub0-G2U-j=ARGdrLeeh4MnZqBHU84kGEHoepoV3L+9g@mail.gmail.com>
 <CD703EE0-5CDC-4CF2-9835-81B1302DD3FB@azul.com>
 <09658B4B-DDFB-46CB-A48B-4262C3278453@azul.com>
 <CAKZz+gfvx1mbbZEx0coKckB2Zcn=7M7BnaW8B6yWBfLHUfUB2g@mail.gmail.com>
 <CAKZz+gcpeQrhZR=SjHhddbMrwcCXFa=dBkK0cX8VaovugGFfgw@mail.gmail.com>
 <24775ADC-D776-4485-B24E-27A3CD02662C@azul.com>
 <CAKZz+ge7OGmRgioGK4w7NDLKoNCTo5XTgKRxcQnYogmGxjwyvA@mail.gmail.com>
 <F9CABA8C-C564-4D47-915A-7DF5CD633B8B@azul.com>
Message-ID: <CAKZz+gfea-RwJRzdwvSVKEbL_r-SXkLw1bigEE8qF4LOfND7GA@mail.gmail.com>

Hi Alexey,

Thanks for your quick response.

Last 2 things regarding the patch (have not looked into the CSR yet):

1) have you checked for regressions in sun/security/tools/keytool tests
category?

2) have you tested the actual passwordless feature? There must be failures
after Webrev.02 because of the security provider checked and I'm not sure
at this point if there were because
'test/sun/security/pkcs12/ParamsTest.java' never passed for a different
reason (explicit storetype parameter).

Thanks,
Martin.-

From alexey at azul.com  Tue Feb  8 17:14:58 2022
From: alexey at azul.com (Alexey Bakhtin)
Date: Tue, 8 Feb 2022 17:14:58 +0000
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <CAKZz+gfea-RwJRzdwvSVKEbL_r-SXkLw1bigEE8qF4LOfND7GA@mail.gmail.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
 <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
 <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>
 <CAKZz+gcub0-G2U-j=ARGdrLeeh4MnZqBHU84kGEHoepoV3L+9g@mail.gmail.com>
 <CD703EE0-5CDC-4CF2-9835-81B1302DD3FB@azul.com>
 <09658B4B-DDFB-46CB-A48B-4262C3278453@azul.com>
 <CAKZz+gfvx1mbbZEx0coKckB2Zcn=7M7BnaW8B6yWBfLHUfUB2g@mail.gmail.com>
 <CAKZz+gcpeQrhZR=SjHhddbMrwcCXFa=dBkK0cX8VaovugGFfgw@mail.gmail.com>
 <24775ADC-D776-4485-B24E-27A3CD02662C@azul.com>
 <CAKZz+ge7OGmRgioGK4w7NDLKoNCTo5XTgKRxcQnYogmGxjwyvA@mail.gmail.com>
 <F9CABA8C-C564-4D47-915A-7DF5CD633B8B@azul.com>
 <CAKZz+gfea-RwJRzdwvSVKEbL_r-SXkLw1bigEE8qF4LOfND7GA@mail.gmail.com>
Message-ID: <AF902F37-473A-413D-86C8-2D34E024F418@azul.com>

Hi Martin,

Yes, I?ve run sun/security/tools/keytool tests. No regression found. All 30 tests passed.

After Webrev.02, the ParamsTest fails on the first attempt to list certificates in the passwordless keystore.
There were two reasons: missed ?-storetype PKCS12? argument and wrong security provider name. The test passed only after fixes in the both files:  test and sun/security/tools/keytool/Main.java

Regards
Alexey

> On 8 Feb 2022, at 19:23, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Alexey,
> 
> Thanks for your quick response.
> 
> Last 2 things regarding the patch (have not looked into the CSR yet):
> 
> 1) have you checked for regressions in sun/security/tools/keytool tests category?
> 
> 2) have you tested the actual passwordless feature? There must be failures after Webrev.02 because of the security provider checked and I'm not sure at this point if there were because 'test/sun/security/pkcs12/ParamsTest.java' never passed for a different reason (explicit storetype parameter).
> 
> Thanks,
> Martin.-
> 


From mbalao at redhat.com  Tue Feb  8 17:43:36 2022
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 8 Feb 2022 12:43:36 -0500
Subject: [8u] RFR: 8076190: Customizing the generation of a PKCS12 keystore
In-Reply-To: <AF902F37-473A-413D-86C8-2D34E024F418@azul.com>
References: <D26A7C91-E556-47CF-8B9B-E5158E850006@azul.com>
 <CAKZz+gdRGigBJBfE6YJ_3JLGVF1sMGzpK4_KpGkp2zkM_P6Brw@mail.gmail.com>
 <CAKZz+gdSWA7TS-Hd_gmMc-2zDaBnD7=MNeQUj1wucLt6MuQ+=w@mail.gmail.com>
 <CAKZz+gcW9DZyk=KD6A-pqYLgkyF-xzLB2WZ8SKsFuMmfhNandw@mail.gmail.com>
 <EAA8A3AB-DBC2-4A7B-9D7C-D3A2042E9A86@azul.com>
 <CAKZz+geiWXTRxAmJ67E1zgmnj8eOaatdqNgMSPo9e6XF9CDkMA@mail.gmail.com>
 <A97E28C9-9110-438F-B078-0F201F021686@azul.com>
 <CAKZz+gd-9fxJq7oF+SFZWVOg+Z7QRwSg6fnCHNoFLAgFtKnEKw@mail.gmail.com>
 <cdb09c16-b6cc-ae41-7b90-c489494590dc@redhat.com>
 <37e498b1-048c-a8f5-8778-af6ccb24666f@redhat.com>
 <71E44066-9528-4FC6-8195-D024F1B7F22F@azul.com>
 <CAKZz+gcub0-G2U-j=ARGdrLeeh4MnZqBHU84kGEHoepoV3L+9g@mail.gmail.com>
 <CD703EE0-5CDC-4CF2-9835-81B1302DD3FB@azul.com>
 <09658B4B-DDFB-46CB-A48B-4262C3278453@azul.com>
 <CAKZz+gfvx1mbbZEx0coKckB2Zcn=7M7BnaW8B6yWBfLHUfUB2g@mail.gmail.com>
 <CAKZz+gcpeQrhZR=SjHhddbMrwcCXFa=dBkK0cX8VaovugGFfgw@mail.gmail.com>
 <24775ADC-D776-4485-B24E-27A3CD02662C@azul.com>
 <CAKZz+ge7OGmRgioGK4w7NDLKoNCTo5XTgKRxcQnYogmGxjwyvA@mail.gmail.com>
 <F9CABA8C-C564-4D47-915A-7DF5CD633B8B@azul.com>
 <CAKZz+gfea-RwJRzdwvSVKEbL_r-SXkLw1bigEE8qF4LOfND7GA@mail.gmail.com>
 <AF902F37-473A-413D-86C8-2D34E024F418@azul.com>
Message-ID: <CAKZz+gcBFyZX-WA_o1BPZo0u1ToRCehZDD1v+OkpjoRgjfa-Zg@mail.gmail.com>

Good, thanks.

Webrev.04 looks good to me and I've seen that the CSR is already approved.

Please request 8u-maintainers approval for this enhancement.

Regards,
Martin.-


On Tue, Feb 8, 2022 at 12:15 PM Alexey Bakhtin <alexey at azul.com> wrote:

> Hi Martin,
>
> Yes, I?ve run sun/security/tools/keytool tests. No regression found. All
> 30 tests passed.
>
> After Webrev.02, the ParamsTest fails on the first attempt to list
> certificates in the passwordless keystore.
> There were two reasons: missed ?-storetype PKCS12? argument and wrong
> security provider name. The test passed only after fixes in the both
> files:  test and sun/security/tools/keytool/Main.java
>
> Regards
> Alexey
>
> > On 8 Feb 2022, at 19:23, Martin Balao <mbalao at redhat.com> wrote:
> >
> > Hi Alexey,
> >
> > Thanks for your quick response.
> >
> > Last 2 things regarding the patch (have not looked into the CSR yet):
> >
> > 1) have you checked for regressions in sun/security/tools/keytool tests
> category?
> >
> > 2) have you tested the actual passwordless feature? There must be
> failures after Webrev.02 because of the security provider checked and I'm
> not sure at this point if there were because
> 'test/sun/security/pkcs12/ParamsTest.java' never passed for a different
> reason (explicit storetype parameter).
> >
> > Thanks,
> > Martin.-
> >
>
>

From hedongbo at huawei.com  Wed Feb  9 01:09:01 2022
From: hedongbo at huawei.com (hedongbo)
Date: Wed, 9 Feb 2022 01:09:01 +0000
Subject: [8u] PRF:8194154 :System property user.dir should not be changed
In-Reply-To: <07afb1ecf87a4ff4a79065616e9b514c@huawei.com>
References: <17042e3e995f4c9895c41163848d2a6d@huawei.com>
 <07afb1ecf87a4ff4a79065616e9b514c@huawei.com>
Message-ID: <72c3d2abd3fb41678791c26f545d24cd@huawei.com>

Ping...

From: hedongbo
Sent: Monday, January 24, 2022 3:55 PM
To: 'jdk8u-dev' <jdk8u-dev at openjdk.java.net>
Subject: RE: [8u] PRF:8194154 :System property user.dir should not be changed

Ping?

Thanks,
hedongbo

From: hedongbo
Sent: Thursday, January 13, 2022 10:29 AM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>
Subject: [8u] PRF:8194154 :System property user.dir should not be changed

Hi,

Please review the backport of JDK-8194154 to 8u.
Bug: https://bugs.openjdk.java.net/browse/JDK-8194154
Original commit: http://hg.openjdk.java.net/jdk/jdk/rev/847a988152b8
8u webrev: https://cr.openjdk.java.net/~dongbohe/8194154/webrev.00/

Patch doesn't apply cleanly but is trivial, because JDK-8154231[1] and JDK-8155775[2] does not exist in 8,
and some copyright year conflicts.

Testing: checked that added test fails without the patch and passes with the patch, tested with tier1.

[1] https://bugs.openjdk.java.net/browse/JDK-8154231
[2] https://bugs.openjdk.java.net/browse/JDK-8155775

Thanks,
hedongbo

From gnu.andrew at redhat.com  Wed Feb  9 03:54:51 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 9 Feb 2022 03:54:51 +0000
Subject: [Ping2?] [8u] RFR: 8210283:  Support git as an SCM alternative
 in the build
In-Reply-To: <5c859ba3ede97bba746538dfdf090fc8a83a11d0.camel@redhat.com>
References: <018e4ec4ebaabd486047b9594da773887d53eee2.camel@redhat.com>
 <001bf6943ff9fb504cb44a1cfdfaf8bb658ca2bb.camel@redhat.com>
 <5c859ba3ede97bba746538dfdf090fc8a83a11d0.camel@redhat.com>
Message-ID: <YgM7C/NOx7uBczJv@hex.discworld.ac.uk>

On 20:33 Thu 03 Feb     , Severin Gehwolf wrote:
> On Wed, 2021-12-22 at 11:14 +0100, Severin Gehwolf wrote:
> > On Fri, 2021-12-10 at 15:11 +0100, Severin Gehwolf wrote:
> > > Hi,
> > > 
> > > Please review this adaptation of the corresponding JDK 11 patch. The
> > > JDK 11u patch didn't apply because the build system is widely different
> > > between these two releases.
> > > 
> > > The main difference is make/common/MakeBase.gmk (JDK 8) vs
> > > make/SourceRevision.gmk (JDK 11). I've basically rewritten those parts
> > > of the patch. All the SCM handling in JDK 8 is in MakeBase.
> > > FindAllReposAbs isn't present in JDK 8u.
> > > 
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210283
> > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210283/01/webrev/
> > > 
> > > Testing: "make --trace source-tips" on mercurial tree as well as
> > > ???????? the git mirror. $IMAGE_DIR/release file contains the SHA of
> > > ???????? the sources it was built from with 'git:' or 'hg:' prefixes.
> > > 
> > > Thoughts?
> > 
> > Anyone? When building from the git read-only mirror the "release" file
> > no longer includes the git sha it was built from without this fix.
>

Well, surely it's never contained a git SHA? :)
It doesn't have the source IDs because there is no Mercurial repository
information, so it's as if it was built from a source tarball or some such.

> Anyone willing to review this?
> 
> Thanks,
> Severin
> 

This looks ok to me. I would omit the line "Called from
jdk/make/closed/bundles.gmk" because this file doesn't exist in our
repository and we have no idea what it does or doesn't contain.

I think it's also worth noting in the summary text that this removes
the forest handling, which wasn't part of the original change for
obvious reasons.

JDK-8031567 was the change that introduced make/SourceRevision.gmk,
but that was at a time when Mercurial forests were still in use, and
it seems that the use of `hg id` has been adopted in 8u separately
form that bug anyway.

I think this change is simple enough as is for what we need, though
I'll admit I've never made use of this functionality myself.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From sgehwolf at redhat.com  Thu Feb 10 13:09:16 2022
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 10 Feb 2022 14:09:16 +0100
Subject: [Ping2?] [8u] RFR: 8210283:  Support git as an SCM alternative
 in the build
In-Reply-To: <YgM7C/NOx7uBczJv@hex.discworld.ac.uk>
References: <018e4ec4ebaabd486047b9594da773887d53eee2.camel@redhat.com>
 <001bf6943ff9fb504cb44a1cfdfaf8bb658ca2bb.camel@redhat.com>
 <5c859ba3ede97bba746538dfdf090fc8a83a11d0.camel@redhat.com>
 <YgM7C/NOx7uBczJv@hex.discworld.ac.uk>
Message-ID: <1ab8f8792f8b4bb66704b8a60c35991b1d372ae5.camel@redhat.com>

Hi Andrew,

On Wed, 2022-02-09 at 03:54 +0000, Andrew Hughes wrote:
> On 20:33 Thu 03 Feb???? , Severin Gehwolf wrote:
> > On Wed, 2021-12-22 at 11:14 +0100, Severin Gehwolf wrote:
> > > On Fri, 2021-12-10 at 15:11 +0100, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Please review this adaptation of the corresponding JDK 11 patch. The
> > > > JDK 11u patch didn't apply because the build system is widely different
> > > > between these two releases.
> > > > 
> > > > The main difference is make/common/MakeBase.gmk (JDK 8) vs
> > > > make/SourceRevision.gmk (JDK 11). I've basically rewritten those parts
> > > > of the patch. All the SCM handling in JDK 8 is in MakeBase.
> > > > FindAllReposAbs isn't present in JDK 8u.
> > > > 
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210283
> > > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210283/01/webrev/
> > > > 
> > > > Testing: "make --trace source-tips" on mercurial tree as well as
> > > > ???????? the git mirror. $IMAGE_DIR/release file contains the SHA of
> > > > ???????? the sources it was built from with 'git:' or 'hg:' prefixes.
> > > > 
> > > > Thoughts?
> > > 
> > > Anyone? When building from the git read-only mirror the "release" file
> > > no longer includes the git sha it was built from without this fix.
> > 
> 
> Well, surely it's never contained a git SHA? :)
> It doesn't have the source IDs because there is no Mercurial repository
> information, so it's as if it was built from a source tarball or some such.
> 
> > Anyone willing to review this?
> > 
> > Thanks,
> > Severin
> > 
> 
> This looks ok to me. I would omit the line "Called from
> jdk/make/closed/bundles.gmk" because this file doesn't exist in our
> repository and we have no idea what it does or doesn't contain.

Removed that part of the comment.

> I think it's also worth noting in the summary text that this removes
> the forest handling, which wasn't part of the original change for
> obvious reasons.

Done.

> JDK-8031567 was the change that introduced make/SourceRevision.gmk,
> but that was at a time when Mercurial forests were still in use, and
> it seems that the use of `hg id` has been adopted in 8u separately
> form that bug anyway.
> 
> I think this change is simple enough as is for what we need, though
> I'll admit I've never made use of this functionality myself.

Latest webrev:
https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210283/02/webrev/

OK?

Thanks,
Severin


From yibo.yl at alibaba-inc.com  Fri Feb 11 08:41:45 2022
From: yibo.yl at alibaba-inc.com (Long Yang)
Date: Fri, 11 Feb 2022 16:41:45 +0800
Subject: =?UTF-8?B?W0dlbnRsZSBQaW5nP11bOHVdIFJGUjogODI2MDU4OTogQ3Jhc2ggaW4gSmZyVHJhY2VJZExv?=
 =?UTF-8?B?YWRCYXJyaWVyOjpsb2FkKF9qY2xhc3MqKQ==?=
In-Reply-To: <1fd986c0-90ff-4ab2-8c67-f9911493686a.yibo.yl@alibaba-inc.com>
References: <1fd986c0-90ff-4ab2-8c67-f9911493686a.yibo.yl@alibaba-inc.com>
Message-ID: <d828e004-288b-4779-b1a9-4a56518a0a61.yibo.yl@alibaba-inc.com>

Anyone willing to review this?

Thanks,
Long Yang (??/??)
 ------------------???? ------------------
???:??(??) <yibo.yl at alibaba-inc.com>
????:Wed Jan 12 15:28:06 2022
???:jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
??:[8u] RFR: 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*)

Hi,
I would appreciate it if you could review the backport of JDK-8260589 to 8u.
This crash problem is very easy to reproduce, so I feel it is necessary to backport it to 8u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8260589
11u commit: https://github.com/openjdk/jdk11u-dev/commit/1d204c554ffe969567161cc05992486ff47d346d
8u webrev: https://cr.openjdk.java.net/~ddong/8260589/webrev.00
Test: jdk/test/jdk/jfr/jvm/TestPrimitiveClasses.java passed.


Due to the differences between JFR in 11u and 17, Denghui made some changes when backporting this fix to 11u. 
Denghui's changes also apply to 8u, so I directly quote Denghui's list here. (4 in total)
1. use MaxJfrEventId + 101 instead of LAST_TYPE_ID + 1 as the klass id of void.class
2. jdk 11 doesn't support jfr streaming, so I removed the call `JfrTraceIdEpoch::set_changed_tag_state()` in `load_primitive`
3. the Class in jdk 11 doesn't have the field 'hidden', so I removed `writer->write<bool>(false);` in `write_primitive`
4. there are many differences in the API of JfrTraceId between 11u and tip

In addition to the above differences, I also make supplementary explanations for the modifications I made.
1. The static global variable clear_artifacts in 11u was introduced by the bugfix https://bugs.openjdk.java.net/browse/JDK-8231081, but this fix has not been backported to 8u, so I removed the code related to clear_artifacts. In 8u, the metadata of the primitive types will be written into the previous chunk on every chunk rotation.
2. In 11u, _artifacts and _class_unload are static global variables, but in 8u, they are static member variables of JfrTypeSet, so I also made necessary changes to the functions that use these two variables.

Thanks,
Long Yang


From gnu.andrew at redhat.com  Tue Feb 15 02:53:30 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 15 Feb 2022 02:53:30 +0000
Subject: [Ping2?] [8u] RFR: 8210283:  Support git as an SCM alternative
 in the build
In-Reply-To: <1ab8f8792f8b4bb66704b8a60c35991b1d372ae5.camel@redhat.com>
References: <018e4ec4ebaabd486047b9594da773887d53eee2.camel@redhat.com>
 <001bf6943ff9fb504cb44a1cfdfaf8bb658ca2bb.camel@redhat.com>
 <5c859ba3ede97bba746538dfdf090fc8a83a11d0.camel@redhat.com>
 <YgM7C/NOx7uBczJv@hex.discworld.ac.uk>
 <1ab8f8792f8b4bb66704b8a60c35991b1d372ae5.camel@redhat.com>
Message-ID: <YgsVqogbjsrRcXGU@hex.discworld.ac.uk>

On 14:09 Thu 10 Feb     , Severin Gehwolf wrote:
> 
> Latest webrev:
> https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210283/02/webrev/
> 
> OK?
> 
> Thanks,
> Severin
> 

This looks fine. Please flag for approval.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Tue Feb 15 02:57:47 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 15 Feb 2022 02:57:47 +0000
Subject: [8u] RFR: 8280963: Incorrect PrintFlags formatting on Windows
In-Reply-To: <CABUxsJ3ZQSe-RHFzCPUCOqx4jd3dAEh0=de9wNe_9NFUHxSKdg@mail.gmail.com>
References: <CABUxsJ3ZQSe-RHFzCPUCOqx4jd3dAEh0=de9wNe_9NFUHxSKdg@mail.gmail.com>
Message-ID: <YgsWq4/YZhDW6BEu@hex.discworld.ac.uk>

On 17:09 Mon 31 Jan     , Alex Kashchenko wrote:
> Hi,
> 
> Please review a fix to 8u-only Windows-specific problem with
> -XX:+PrintFlags* output:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8280963
> 
> Webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8280963/webrev.01/
> 
> Problem description on Stack Overflow by Andrei Pangin:
> https://stackoverflow.com/a/63309395
> 
> The problem was fixed in jdk9 as part of JDK-8042893 [1], but this
> jdk9 change [2] doesn't look like a good candidate for the 8u backport
> according to 8u Best Practices [3]. Still the problem manifests itself
> as a customer-visible bug on Windows because people do use
> -XX:+PrintFlagsFinal to find out the actual flags picked up by JVM and
> can be confused by unexpected zeros in the output. Proposed patch
> cherry-picks the minimal change from JDK-8042893 commit [4].
> 
> Testing:
> 
>  - regression test is included with the proposed patch
>  - checked that it builds on Windows 64-bit and 32-bit on VS2017 and VS2010
>  - ran jtreg:hotspot/test/runtime on Windows and Linux
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8042893
> [2] https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15
> [3] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012002.html
> [4] https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15#l53.1
> 
> 
> -- 
> -Alex
> 

Where does hotspot/test/runtime/CommandLine/PrintFlagsUintxTest.java come from?
I don't see it in 11u. It should really go to the later branches as well.

I agree with no backporting a swarm of gcc warning fixes as well.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From sgehwolf at redhat.com  Tue Feb 15 10:53:37 2022
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 15 Feb 2022 11:53:37 +0100
Subject: [Ping2?] [8u] RFR: 8210283:  Support git as an SCM alternative
 in the build
In-Reply-To: <YgsVqogbjsrRcXGU@hex.discworld.ac.uk>
References: <018e4ec4ebaabd486047b9594da773887d53eee2.camel@redhat.com>
 <001bf6943ff9fb504cb44a1cfdfaf8bb658ca2bb.camel@redhat.com>
 <5c859ba3ede97bba746538dfdf090fc8a83a11d0.camel@redhat.com>
 <YgM7C/NOx7uBczJv@hex.discworld.ac.uk>
 <1ab8f8792f8b4bb66704b8a60c35991b1d372ae5.camel@redhat.com>
 <YgsVqogbjsrRcXGU@hex.discworld.ac.uk>
Message-ID: <87a4d5cbf3899ee351dba89d46c42dfe69799e9a.camel@redhat.com>

On Tue, 2022-02-15 at 02:53 +0000, Andrew Hughes wrote:
> On 14:09 Thu 10 Feb???? , Severin Gehwolf wrote:
> > 
> > Latest webrev:
> > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210283/02/webrev/
> > 
> > OK?
> > 
> > Thanks,
> > Severin
> > 
> 
> This looks fine. Please flag for approval.

Thanks for the review. Done.

Cheers,
Severin


From gnu.andrew at redhat.com  Tue Feb 15 16:04:32 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 15 Feb 2022 16:04:32 +0000
Subject: jdk8u322 release and packaging
In-Reply-To: <ae8fba8-55eb-87c1-ec9d-6e2b9c4939b1@tarent.de>
References: <df7b8b73-9399-a796-c06b-325f74c75048@tarent.de>
 <YfyqBUzqXBqZfl0a@hex.discworld.ac.uk>
 <ae8fba8-55eb-87c1-ec9d-6e2b9c4939b1@tarent.de>
Message-ID: <YgvPEHptsSVipsYH@hex.discworld.ac.uk>

On 16:29 Fri 04 Feb     , Thorsten Glaser wrote:
> Hi,
> 
> > Welcome to OpenJDK maintenance :-)
> 
> thanks ?
> 
> > Recreating it just for building the source is considerably easier:
> > 
> > $ git clone -b jdk8u322-ga https://github.com/openjdk/jdk8u.git openjdk
> > $ mv openjdk/{corba,jaxp,jaxws,langtools,nashorn,jdk,hotspot} .
> > $ for repos in openjdk corba jaxp jaxws langtools nashorn jdk hotspot ; do
> >   tar cJf ${repos}.tar.xz ${repos}
> >   done
> 
> OK, so the listed top-level directories under the monorepo *directly*
> correspond to the old repositories, and the remainder of the monorepo
> is the old ?root? repository?
>

Correct.

We've avoided any file movement that would also mean changes to the
build system.

> > That will give you the original eight individual repository
> > tarballs. You can also replace the git clone step with just using the
> > release tarball instead.
> 
> Yeah, it?ll be a bit more complicated considering aarch32 and
> aarch64-shenandoah? but this helps already. I still have no idea
> what I?d do if either of these changes anything outside of hotspot?
>

I'm looking at these myself at the moment, as I still also maintain IcedTea
and that does the same thing of swapping in HotSpot bundles for Shenandoah
and aarch32. I'm thinking I'm going to have to clone the whole repo and
then just tarball the HotSpot subdirectory.

All the needed Shenandoah changes are in the HotSpot subdirectory. There are
a few minor differences outside that at present, but these don't affect the
code being built and we intend to get them upstream into 8u. I reviewed
what was there when doing a bulk import of the changes into git [0]. That
should soon be in the 8u Shenandoah git repository [1]

AArch32 does have changes in the root & jdk directories to handle the
architecture in configure and I had to cherry-pick these across to
IcedTea. I don't know how Debian currently handles this. Are there
local patches?  [2] [3] [4] [5]

> Just doing 8 here; 11/17 are actively maintained by doko, and
> 7 has ended (ELTS supplies 8 instead).
>

Feel free to ask if you need any more help :)

> bye,
> //mirabilos
> -- 
> Infrastrukturexperte ? tarent solutions GmbH
> Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
> Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
> HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
> Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
> 
>                         ****************************************************
> /?\ The UTF-8 Ribbon
> ??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
> ??? HTML eMail! Also,     https://www.tarent.de/newsletter
> ??? header encryption!
>                         ****************************************************
> 

[0] https://github.com/gnu-andrew/jdk8u/commit/d475f9eb9bbb9e91db6473679f7334dd8372c8f9?diff=unified
[1] https://github.com/openjdk/shenandoah-jdk8u
[2] https://icedtea.wildebeest.org/hg/icedtea8-forest/rev/c1756ee15e69
[3] https://icedtea.wildebeest.org/hg/icedtea8-forest/rev/7c357084c459
[4] https://icedtea.wildebeest.org/hg/icedtea8-forest/jdk/rev/c05781ed8e5c
[5] https://icedtea.wildebeest.org/hg/icedtea8-forest/rev/3e39851fea09
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Tue Feb 15 16:12:13 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 15 Feb 2022 16:12:13 +0000
Subject: OpenJDK 8u322 Released
In-Reply-To: <35ec318a-b1fd-67fb-dfd7-ca54f71fc3f@tarent.de>
References: <Yfc2G1rGTYwN5/Fg@hex.discworld.ac.uk>
 <35ec318a-b1fd-67fb-dfd7-ca54f71fc3f@tarent.de>
Message-ID: <YgvQ3UKQr3zwGcf+@hex.discworld.ac.uk>

On 16:02 Mon 31 Jan     , Thorsten Glaser wrote:

snip...

> > 
> > This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):
> > 
> > PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
> > Fingerprint = CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F
> 
> Would be nice to have a trust path to that (that doesn?t involve
> expired/revoked/1024-bit keys)? currently it looks like this:
> 
> 92EF8D39DC13168F OpenJDK Team ? A5CD6035332FA671 Andrew Haley (rsa2048 2009-05-18)
> 
> A5CD6035332FA671 ? 672F2227C2C07028 Andrew Haley (dsa1024 2003-05-15 revoked)
> A5CD6035332FA671 ? 33C16EF5E22673CF Andrew Gross (rsa4096 2018-01-18)
> A5CD6035332FA671 ? FBB7576BA7CB0B6B David Howells (rsa4096 2011-10-05)
> A5CD6035332FA671 ? F286F14F66484681 Omair Majid (rsa4096 2012-01-18 expired 2017)
> A5CD6035332FA671 ? 69DA36AE31C5C4B3 Andrew Dinn (rsa2048 2010-07-20)
> 
> 33C16EF5E22673CF is not signed by anyone else.
> FBB7576BA7CB0B6B is not signed by anyone else.
> 69DA36AE31C5C4B3 is not signed by anyone else.
> 
> F286F14F66484681 (expired) was signed
>  by 3B96A578248BDC07 (Andrew Hughes) (rsa4096 2011-09-28 expired 2012)
> 
> This is rather sad?
>

It is. It should at least be signed with my (current) key. It is locally,
so I guess I need to sync what I have to an appropriate key server.
Any recommendations? I have hkp://hkps.pool.sks-keyservers.net in my
config but a refresh with that seems to fail.

> bye,
> //mirabilos (Debian Developer)
> -- 
> Infrastrukturexperte ? tarent solutions GmbH
> Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
> Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
> HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
> Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
> 
>                         ****************************************************
> /?\ The UTF-8 Ribbon
> ??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
> ??? HTML eMail! Also,     https://www.tarent.de/newsletter
> ??? header encryption!
>                         ****************************************************
> 

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Tue Feb 15 16:47:35 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 15 Feb 2022 16:47:35 +0000
Subject: OpenJDK 8u332-b01 EA Released
Message-ID: <YgvZJwG4zmTfCtyw@hex.discworld.ac.uk>

I've made available an early access source bundle for 8u332, based on
the tag jdk8u332-b01:

https://openjdk-sources.osci.io/openjdk8/openjdk8u332-b01-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u332-b01-ea.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint =3D CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

0e8179e07e8fbcd9b818545fc7543a9085b4c6c8253570758c80aa0471d159ca  openjdk8u332-b01-ea.tar.xz
4d3cf3c953dfcb5de5f5ebc69d4e63ebb864602642d3dffc9647f0d930df2055  openjdk8u332-b01-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u332-b01-ea.sha256

The tarball was built on RHEL 6 (x86, x86_64) and RHEL 7 (aarch64,
ppc, ppc64, ppc64le, s390x, x86, x86_64)

Changes in 8u332-b01:
  - JDK-8033980: Xerces Update: datatype XMLGregorianCalendarImpl and DurationImpl
  - JDK-8035437: Xerces Update: xml/serialize/DOMSerializerImpl
  - JDK-8035577: Xerces Update: impl/xpath/regex/RangeToken.java
  - JDK-8162572: Update License Header for all JAXP sources
  - JDK-8167014: jdeps: Missing message: warn.skipped.entry
  - JDK-8198411: [TEST_BUG] Two java2d tests are unstable in mach5
  - JDK-8202822: Add .git to .hgignore
  - JDK-8205540: test/hotspot/jtreg/vmTestbase/nsk/jdb/trace/trace001/trace001.java fails with Debuggee did not exit after 15 <cont> commands
  - JDK-8218682: [TEST_BUG] DashOffset fails in mach5
  - JDK-8225690: Multiple AttachListener threads can be created
  - JDK-8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"
  - JDK-8227815: Minimal VM: set_state is not a member of AttachListener
  - JDK-8240633: Memory leaks in the implementations of FileChooserUI
  - JDK-8241768: git needs .gitattributes
  - JDK-8247766: [aarch64] guarantee(val < (1U << nbits)) failed: Field too big for insn.
  - JDK-8253147: The javax/swing/JPopupMenu/7154841/bug7154841.java fail on big screens
  - JDK-8253353: Crash in C2: guarantee(n != NULL) failed: No Node
  - JDK-8266749: AArch64: Backtracing broken on PAC enabled systems
  - JDK-8270290: NTLM authentication fails if HEAD request is used
  - JDK-8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE
  - JDK-8279077: JFR crashes on Linux ppc due to missing crash protector in signal handler

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Tue Feb 15 16:50:23 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 15 Feb 2022 16:50:23 +0000
Subject: OpenJDK 8u332-b02 EA Released
Message-ID: <YgvZz4bS6LyKQ2sT@hex.discworld.ac.uk>

I've made available an early access source bundle for 8u332, based on
the tag jdk8u332-b02:

https://openjdk-sources.osci.io/openjdk8/openjdk8u332-b02-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u332-b02-ea.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint: CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

7ea1c6106a91fc994bfe282d254edd9e367575bada0baf757833e32e2713babc  openjdk8u332-b02-ea.tar.xz
78325bfb219270745390226a99721dfea0355a0719d4997a56800831c56347bb  openjdk8u332-b02-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u332-b02-ea.sha256

The tarball was built on RHEL 6 (x86, x86_64) and RHEL 7 (aarch64,
ppc, ppc64, ppc64le, s390x, x86, x86_64)

Changes in 8u332-b02:
  - JDK-8141508: java.lang.invoke.LambdaConversionException: Invalid receiver type
  - JDK-8209178: Proxied HttpsURLConnection doesn't send BODY when retrying POST request
  - JDK-8273229: Update OS detection code to recognize Windows Server 2022
  - JDK-8273341: Update Siphash to version 1.0
  - JDK-8273575: memory leak in appendBootClassPath(), paths must be deallocated

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From t.glaser at tarent.de  Tue Feb 15 18:02:44 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Tue, 15 Feb 2022 19:02:44 +0100 (CET)
Subject: OpenJDK 8u322 Released
In-Reply-To: <YgvQ3UKQr3zwGcf+@hex.discworld.ac.uk>
References: <Yfc2G1rGTYwN5/Fg@hex.discworld.ac.uk>
 <35ec318a-b1fd-67fb-dfd7-ca54f71fc3f@tarent.de>
 <YgvQ3UKQr3zwGcf+@hex.discworld.ac.uk>
Message-ID: <6f4d4978-4657-b8c-cab5-a64d8d5ae38@tarent.de>

On Tue, 15 Feb 2022, Andrew Hughes wrote:

> Any recommendations? I have hkp://hkps.pool.sks-keyservers.net in my
> config but a refresh with that seems to fail.

That never worked for me. Right now, pgp.uni-mainz.de is the
one that has worked for the most amount of time.

Thanks,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://www.tarent.de/newsletter
??? header encryption!
                        ****************************************************

From alexey at azul.com  Wed Feb 16 06:55:16 2022
From: alexey at azul.com (Alexey Bakhtin)
Date: Wed, 16 Feb 2022 06:55:16 +0000
Subject: [8u] RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance
Message-ID: <59A42534-25B0-43DD-98DD-1CE6E035F646@azul.com>

Hello all,

Could you please review a backport of AlgorithmConstraints:checkAlgorithm performance enhancement to JDK8u

JBS: https://bugs.openjdk.java.net/browse/JDK-8268427
Webrev: https://cr.openjdk.java.net/~abakhtin/8268427/webrev.v0/
11u patch: https://github.com/openjdk/jdk11u-dev/commit/4e324294d2940aa7ebaf51723fd4bc5178442b15

11u patch applies clean except of the following:
1) JDK8u does not have JDK-8215281: "Use String.isEmpty() when applicable in java.base? [1] enhancement, so the AbstractAlgorithmConstraints.java is not applied clean. Trivial merge around "algorithm.length() == 0? line of code.
2) Original code contains micro-benchmark which is not supported by JDK8. Benchmark is converted to the manual test

JDK8u results before patch:
Algorithm   Nanos
SSLv3       8.889
DES       102.397
NULL      176.476
TLS1.3    642.859

JDK8u results after patch:
Algorithm   Nanos
SSLv3      53.205
DES        36.405
NULL       26.642
TLS1.3    168.395

JDK11u results for reference:
Algorithm   Nanos
SSLv3      48.563
DES        32.336
NULL       22.696
TLS1.3    194.921

No regression in the sun/security tests.

Regards
Alexey

[1] - https://bugs.openjdk.java.net/browse/JDK-8215281

From yan at azul.com  Thu Feb 17 14:21:57 2022
From: yan at azul.com (Yuri Nesterenko)
Date: Thu, 17 Feb 2022 17:21:57 +0300
Subject: [8u] RFR: JDK-8231507: Update Apache Santuario (XML Signature) to
 version 2.1.4
In-Reply-To: <fe7ffd1e-89e7-f53c-5338-83ce8ec206d5@azul.com>
References: <fe7ffd1e-89e7-f53c-5338-83ce8ec206d5@azul.com>
Message-ID: <e8f2e57a-7193-742f-2196-fd2166db22f6@azul.com>

LGTM,

Thank you for the port!
--yan

On 01.02.2022 14:21, Dmitry Cherepanov wrote:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8231507
> Webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8231507/webrev.01/
> 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8727ed99cb0c
> 
> The patch for 11u applies cleanly to 8u with path shuffling except the following two places
> ?- XMLDSigRI.java,? context changed due to JDK-8130181 isn't present in 8u
> ?- santuario.md, updated version in THIRD_PARTY_README files
> 
> Verified with jdk_security tests.
> 
> Thanks
> 
> Dmitry
> 

From dcherepanov at azul.com  Thu Feb 17 16:32:03 2022
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Thu, 17 Feb 2022 19:32:03 +0300
Subject: [8u] RFR: JDK-8231507: Update Apache Santuario (XML Signature) to
 version 2.1.4
In-Reply-To: <e8f2e57a-7193-742f-2196-fd2166db22f6@azul.com>
References: <fe7ffd1e-89e7-f53c-5338-83ce8ec206d5@azul.com>
 <e8f2e57a-7193-742f-2196-fd2166db22f6@azul.com>
Message-ID: <c51b0179-18db-d766-631a-638251aa9321@azul.com>

Thanks Yuri, tagged for approval.

Dmitry

On 17.02.2022 17:21, Yuri Nesterenko wrote:
> LGTM,
>
> Thank you for the port!
> --yan
>
> On 01.02.2022 14:21, Dmitry Cherepanov wrote:
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8231507
>> Webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8231507/webrev.01/
>> 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8727ed99cb0c
>>
>> The patch for 11u applies cleanly to 8u with path shuffling except the following two places
>>  ?- XMLDSigRI.java,? context changed due to JDK-8130181 isn't present in 8u
>>  ?- santuario.md, updated version in THIRD_PARTY_README files
>>
>> Verified with jdk_security tests.
>>
>> Thanks
>>
>> Dmitry
>>

From bart at bedrijfzondernaam.nl  Thu Feb 17 21:58:36 2022
From: bart at bedrijfzondernaam.nl (Bart Overkamp)
Date: Thu, 17 Feb 2022 22:58:36 +0100
Subject: OpenJDK 8u322 Released
Message-ID: <8B6BD7B1-C821-4395-8D9F-19216035761F@bedrijfzondernaam.nl>

Dear reader,

I?m planning to cross-build for Apple?s arm64, the poor thing is running without Rosetta so the last resort would be to compile from source, right?
Well, first off the bootstrap JVM is missing.. There goes that. Second: My Linux cross-building machine is telling me:

First, lying:
boiert at navi:~/pruts/jdk8u322-ga$ bash ./configure --openjdk-target=arm64-apple-macos
...
checking build system type... x86_64-unknown-linux-gnu
checking host system type... Invalid configuration `arm64-apple-macos': machine `arm64-apple' not recognized
configure: error: /bin/bash /home/boiert/pruts/jdk8u322-ga/common/autoconf/build-aux/config.sub arm64-apple-macos failed

Then, truthfully:
boiert at navi:~/pruts/jdk8u322-ga$ bash ./configure --openjdk-target=arm64-unknown-mac
...
checking build system type... x86_64-unknown-linux-gnu
checking host system type... arm64-apple-macos
checking target system type... arm64-apple-macos
checking openjdk-build os-cpu... linux-x86_64
configure: error: unsupported operating system macos

What to do?
Any pointers or a willing volunteer?

Thank you!
- Bart

From aph-open at littlepinkcloud.com  Fri Feb 18 15:17:12 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Fri, 18 Feb 2022 15:17:12 +0000
Subject: OpenJDK 8u322 Released
Message-ID: <2a0570a8-a41d-11dc-0b93-09b361b53ab4@littlepinkcloud.com>

[From Bart Overkamp <bart at bedrijfzondernaam.nl>]

Dear reader,

I?m planning to cross-build for Apple?s arm64, the poor thing is running without Rosetta so the last resort would be to compile from source, right?
Well, first off the bootstrap JVM is missing.. There goes that. Second: My Linux cross-building machine is telling me:

First, lying:
boiert at navi:~/pruts/jdk8u322-ga$ bash ./configure --openjdk-target=arm64-apple-macos
...
checking build system type... x86_64-unknown-linux-gnu
checking host system type... Invalid configuration `arm64-apple-macos': machine `arm64-apple' not recognized
configure: error: /bin/bash /home/boiert/pruts/jdk8u322-ga/common/autoconf/build-aux/config.sub arm64-apple-macos failed

Then, truthfully:
boiert at navi:~/pruts/jdk8u322-ga$ bash ./configure --openjdk-target=arm64-unknown-mac
...
checking build system type... x86_64-unknown-linux-gnu
checking host system type... arm64-apple-macos
checking target system type... arm64-apple-macos
checking openjdk-build os-cpu... linux-x86_64
configure: error: unsupported operating system macos

What to do?
Any pointers or a willing volunteer?

Thank you!
- Bart

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph-open at littlepinkcloud.com  Fri Feb 18 15:22:43 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Fri, 18 Feb 2022 15:22:43 +0000
Subject: OpenJDK 8u322 Released
In-Reply-To: <2a0570a8-a41d-11dc-0b93-09b361b53ab4@littlepinkcloud.com>
References: <2a0570a8-a41d-11dc-0b93-09b361b53ab4@littlepinkcloud.com>
Message-ID: <76452725-4fbb-6953-645b-ddb0728cf743@littlepinkcloud.com>

On 2/18/22 15:17, Andrew Haley wrote:
> What to do?
> Any pointers or a willing volunteer?

A couple of people have M1 ports, but it's not in the official JDK 8u repo.
We perhaps should create an M1 source tree in the JDK 8u space for
people who want it, and consolidate everyone's downstream patches there.

What's your use case? I've sort-of taken the view that Rosetta is basically
good enough, and 8 is a pretty old JDK release. There was a reported bug
with signal handling in an older version of Rosetta, but it's fixed now.
So what's up? Is Rosetta really not good enough for 8u?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From tianshuang.me at qq.com  Sat Feb 19 06:11:06 2022
From: tianshuang.me at qq.com (=?ISO-8859-1?B?UG9pc29u?=)
Date: Sat, 19 Feb 2022 14:11:06 +0800
Subject: Is it possible that the if block in the perfInit() method is executed
 multiple times?
Message-ID: <tencent_CC8F985FF068EE2A026983A103485F940805@qq.com>

When using JDK 8 on Linux, the following code:&nbsp;https://github.com/openjdk/jdk8u/blob/jdk8u332-b02/jdk/src/solaris/native/sun/management/LinuxOperatingSystem.c#L204-L227


When multiple threads call sun.management.OperatingSystemImpl#getProcessCpuLoad concurrently, whether the if block in the perfInit() method may be executed multiple times, although I don't know if it will affect the return value of the getProcessCpuLoad0() method, but it seems that this problem does exist, because there is no lock when getProcessCpuLoad0() is called.


Reference:&nbsp;https://www.quora.com/Why-use-of-local-static-variable-makes-C-code-not-thread-safe

From zzambers at redhat.com  Mon Feb 21 22:41:18 2022
From: zzambers at redhat.com (=?UTF-8?B?WmRlbsSbayDFvWFtYmVyc2vDvQ==?=)
Date: Mon, 21 Feb 2022 23:41:18 +0100
Subject: RFR: 8279669: test/jdk/com/sun/jdi/TestScaffold.java uses wrong
 condition
Message-ID: <be906b55-2d17-c7e4-aff1-a57c259d54fe@redhat.com>

Hi,
please review this backport:

JDK Bug: https://bugs.openjdk.java.net/browse/JDK-8279669
Webrev (monojdk8u-dev): 
https://zzambers.github.io/www/webrevs/8279669/webrev.00/

This fixes: test/com/sun/jdi/RedefineCrossEvent.java test.

I manually ran all tests in test/com/sun/jdi and they passed for me with 
this patch applied.
I'll probably also require someone to push on my behalf.

-- 
Zden?k ?ambersk?
OpenJDK QE
Red Hat


From hedongbo at huawei.com  Wed Feb 23 06:33:54 2022
From: hedongbo at huawei.com (hedongbo)
Date: Wed, 23 Feb 2022 06:33:54 +0000
Subject: [8u] PRF:8207011 :Remove uses of the register storage class specifier
Message-ID: <6fb6fc5e30ab4adfa9820d25ba634872@huawei.com>

Hi,

Please review the backport of JDK-8207011 to 8u.
Bug: https://bugs.openjdk.java.net/browse/JDK-8207011
Original commit: https://git.openjdk.java.net/jdk11u-dev/commit/98fb4f5e18a58727f51e00e3c08c0f5eac6748ec
8u webrev: http://cr.openjdk.java.net/~dongbohe/8207011/webrev.01/

This patch fixes build failure with gcc 11. Patch doesn't apply cleanly, because JDK-8188813[1], JDK-8204301[2], JDK-8041415 [3], and JDK-8186089[4] does not exist in 8.
+ JDK-8188813 added register in orderAccess_aix_ppc.inline.hpp, orderAccess_linux_ppc.inline.hpp, orderAccess_linux_s390.inline.hpp,
and JDK-8204301 renamed these files to orderAccess_aix_ppc.inline.hpp, orderAccess_aix_ppc.hpp, orderAccess_linux_s390.hpp.
+ JDK-8041415 changed uint32 to uint32_t.
+ JDK-8186089 moved arena from allocation.cpp to arena.cpp.

Before patch:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jiangshunningy/install/libexec/gcc/aarch64-unknown-linux-gnu/11.2.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/jiangshunningy/install --enable-languages=c,c++,fortran,go
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (GCC)

$ bash configure
$ make images
/home/jiangshunningy/hedongbo/jdk8u-dev/hotspot/src/share/vm/adlc/dict2.cpp:286:17: error: ISO C++17 does not allow 'register' storage class specifier [-Werror=register]
  286 |   register char c, k = 0;
      |                 ^
/home/jiangshunningy/hedongbo/jdk8u-dev/hotspot/src/share/vm/adlc/dict2.cpp:286:20: error: ISO C++17 does not allow 'register' storage class specifier [-Werror=register]
  286 |   register char c, k = 0;
      |                    ^
/home/jiangshunningy/hedongbo/jdk8u-dev/hotspot/src/share/vm/adlc/dict2.cpp:287:16: error: ISO C++17 does not allow 'register' storage class specifier [-Werror=register]
  287 |   register int sum = 0;
      |                ^~~
/home/jiangshunningy/hedongbo/jdk8u-dev/hotspot/src/share/vm/adlc/dict2.cpp:288:24: error: ISO C++17 does not allow 'register' storage class specifier [-Werror=register]
  288 |   register const char *s = (const char *)t;
      |                        ^
...

After patch:
Build succeeded.

[1] https://bugs.openjdk.java.net/browse/JDK-8188813
[2] https://bugs.openjdk.java.net/browse/JDK-8204301
[3] https://bugs.openjdk.java.net/browse/JDK-8041415
[4] https://bugs.openjdk.java.net/browse/JDK-8186089

Thanks,
hedongbo

From gnu.andrew at redhat.com  Mon Feb 28 05:17:55 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 28 Feb 2022 05:17:55 +0000
Subject: [IMPORTANT] monojdk8u-dev now CLOSED FOR PUSHES for rampdown of
 8u332 and 8u-dev transition to GitHub
Message-ID: <YhxbA6mxlfIStbzC@hex.discworld.ac.uk>

Hi all,

We are now ramping down for the release of OpenJDK 8u332 in April
2022.

jdk8u/monojdk8u-dev is now obsolete. Future development on
8u342, the planned July 2022 release, will take place on
GitHub using SKARA, as with later JDK releases [0].  Please
wait for a further notification as to when
https://github.com/openjdk/jdk8u-dev is live and open
for pull requests.

Note that pushes to the new GitHub jdk8u-dev will still
require a jdk8u-fix-yes.

The jdk8u/monojdk8u Mercurial repository is the place for critical
fixes for 8u332 during rampdown. This will transition fully to GitHub
after the release of 8u332, though a read-only mirror is currently
available at https://github.com/openjdk/jdk8u

[0] https://bugs.openjdk.java.net/browse/SKARA-1260

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222