From duke at openjdk.java.net Mon May 2 01:09:12 2022 From: duke at openjdk.java.net (Mark Powers) Date: Mon, 2 May 2022 01:09:12 GMT Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v3] In-Reply-To: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com> References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com> Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8285263 Minor cleanup could be done in java.security > > JDK-8273046 is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: > > open/src/java.base/share/classes/java/security Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - third iteration - Merge - Merge - second iteration - Merge - Merge - first iteration ------------- Changes: https://git.openjdk.java.net/jdk/pull/8319/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8319&range=02 Stats: 639 lines in 96 files changed: 25 ins; 140 del; 474 mod Patch: https://git.openjdk.java.net/jdk/pull/8319.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8319/head:pull/8319 PR: https://git.openjdk.java.net/jdk/pull/8319 From peter.firmstone at zeus.net.au Mon May 2 01:33:51 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 2 May 2022 11:33:51 +1000 Subject: Timeframe for JEP-411 completely removing SecurityManager APIs In-Reply-To: References: Message-ID: <71edaa17-418a-9852-4898-c0657b90d919@zeus.net.au> Our software was never designed to run without SM enabled.? We will need to instrument the Java API's with some access controls, this will be reliant on the removal of finalizers, or the option to disable them. In our case deserialization is decided by the permission granted to the authenticated remote user.?? Deserialization also has a number of different categories based on risk. ? For example explicit permission is required to deserialize a MarshalledObject, in this case the MarshalledObject is only used for equals comparison, the MarshalledObject is never itself unmarshalled, checked by code audit before granting this permission.? The ability to class load remote code dynamically is also determined by permission. Our software attempts to set the security manager if it hasn't been set. We realise that this is no longer the recommended way to secure Java software, however our software will be insecure without SM until we can replace its functionality. The problem is, OpenJDK is telling us that this is not the best way to secure Java, that there are better alternatives, however without SM our software will be insecure, until we are able to redesign it, unentangling our dependency on SM isn't a simple problem to solve. I guess I'm just trying to say we need more time, the process of extricating SM for security will take years, if we can leave SM as it is in deprecated form for a number of years, that would be greatly appreciated. Regards, Peter. On 27/04/2022 3:38 am, Sean Mullan wrote: > > > On 4/26/22 1:06 PM, Scott Stark wrote: >> By "migration feature" I'm talking about being able to retain the >> type of library code where one has a conditional call to an >> AccessController::doPrivileged(...) method that is only done when >> System.getSecurityManager() is not null. Not having to remove this >> code in all dependent libraries for a given Jakarta EE application >> server product in order to run on Java SE 21 is seen as necessary to >> navigate supporting application servers over a range of Java SE >> versions. The general consensus was that having to deal with Java SE >> 11, 17 and 21 would only be possible if this SecurityManager related >> code could remain as is, even if the only executed path would be >> for?System.getSecurityManager() == null. We can deal with a gradual >> degradation of the SecurityManager behavior, but it was unclear if >> Java SE 21 was looking for a complete removal of the APIs the >> libraries use. > > Yes, we understand these concerns. We recognize the compatibility > issues and the importance for code using the SM APIs to continue to > work as if an SM has not been enabled. This is the motivation behind > the language in the JEP that discusses a gradual degradation and > phasing out of the SM APIs until the compatibility risk is low enough > that removal is acceptable. > > Also, you mention SE 21, but as of yet there is not yet a targeted > release for the SM removal. There will likely be a JEP for the removal > of the SM and this will need to go through several phases of the JEP > process before it can be targeted to a specific release. > >> I'm sure many of the Jakarta EE platform dev members have code >> repositories to offer for scanning to aide in determining when the >> SecurityManager dependencies have been removed. If there is a avenue >> for that information, please let me know. > > Thanks for that offer. I don't have an avenue for that information > yet, but I will see if we can start creating a list of significant > SM-enabled libraries and other projects that we can monitor over time. > > --Sean > >> Thanks, >> Scott >> >> On Apr 26, 2022 at 11:09:22 AM, Sean Mullan > > wrote: >>> Hello Scott, >>> >>> On 4/25/22 2:25 PM, Scott Stark wrote: >>>> Hello, >>>> >>>> I'm Scott Stark of Red Hat, and a member of the Jakarta EE platform >>>> dev >>>> group (EEPD). I'm currently coordinating the Jakarta EE 10 release >>>> that >>>> is targeting June of this year (2022). The removal of the >>>> SecurityManager as described in JEP-411 has been a topic for the >>>> EEPD on >>>> may calls this year. Recent discussions make it clear that any >>>> SecurityManager alternative would need to be taken up by the EEPD, and >>>> such an effort is going to be a non-trivial undertaking, and may >>>> not be >>>> addressed at all. >>>> >>>> A general concern among vendors in the EEPD is the timeframe for the >>>> code that bridges between the JVM running with and without a >>>> SecurityManager instance needing to be updated. Such code is the >>>> subject >>>> of this JEP-411 paragraph: >>>> >>>> "In feature releases after Java 18, we will degrade other Security >>>> Manager APIs so that they remain in place but with limited or no >>>> functionality. For example, we may revise >>>> AccessController::doPrivileged >>>> simply to run the given action, or revise System::getSecurityManager >>>> always to return null. This will allow libraries that support the >>>> Security Manager and were compiled against previous Java releases to >>>> continue to work without change or even recompilation. We expect to >>>> remove the APIs once the compatibility risk of doing so declines to an >>>> acceptable level." >>>> >>>> Of particular interest is the timeframe for "remove the APIs once the >>>> compatibility risk of doing so declines to an acceptable level". >>>> >>>> Vendors in EEPD would like to see Java SE 21 ship with a migration >>>> feature along the lines of the proposed >>>> "AccessController::doPrivileged >>>> simply to run the given action, or revise System::getSecurityManager >>>> always to return null" behaviors. >>> >>> Can you clarify what you mean by "a migration feature" and also provide >>> some background as to why vendors in EEPD would like to see this? Do >>> you >>> mean something like a system property that enables the degraded >>> behavior >>> as described above? >>> >>>> Is there some metric for tracking "when the compatibility risk of >>>> doing >>>> so declines to an acceptable level."? I believe the EEPD vendors would >>>> like readiness of their projects and upstream dependencies to >>>> somehow be >>>> included in any such tracking. >>> >>> So, first we do not yet have a proposed target date for when we would >>> like to remove support for the Security Manager (SM) from the JDK. By >>> removing support, I mean that the JDK would no longer include a SM >>> implementation. However, I don't anticipate that any SM specific APIs >>> would be degraded *prior* to removing SM support from the JDK. >>> >>> Some APIs will likely be degraded as described above at the same >>> time we >>> remove support for the SM from the JDK. >>> >>> As for when the APIs will actually be removed, this will most likely be >>> a longer period, possibly several JDK releases. We recognize that many >>> libraries and applications will need time to adapt to the changes and >>> remove dependencies on the APIs. We have tools that check open source >>> repositories for API dependencies and are able to provide us with data >>> that helps assess the compatibility risk. However, I can't give you a >>> timeframe for API removal yet. >>> >>> HTH, >>> Sean From xuelei at openjdk.java.net Mon May 2 05:01:21 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 2 May 2022 05:01:21 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v3] In-Reply-To: References: Message-ID: > Please review the update to remove finalizer method in the SunJSSE provider implementation. It is one of the efforts to clean up the use of finalizer method in JDK. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: comment about remove finalize() method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8065/files - new: https://git.openjdk.java.net/jdk/pull/8065/files/ccfc42da..c90e25a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8065&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8065&range=01-02 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8065/head:pull/8065 PR: https://git.openjdk.java.net/jdk/pull/8065 From xuelei at openjdk.java.net Mon May 2 05:01:21 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 2 May 2022 05:01:21 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2] In-Reply-To: References: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> Message-ID: On Wed, 27 Apr 2022 06:55:42 GMT, Xue-Lei Andrew Fan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision: >> >> - typo blank linke correction >> - revise the update > > ping ... > @XueleiFan, would you please add a note to the bug itself with the end-result, and a quick note in the place of the finalizer a quick summary of what we decided. Sure. Notes were added in JBS and the patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From xuelei at openjdk.java.net Mon May 2 05:01:22 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 2 May 2022 05:01:22 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v3] In-Reply-To: References: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> Message-ID: On Sat, 30 Apr 2022 03:46:23 GMT, Bradford Wetmore wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> comment about remove finalize() method > > src/java.base/share/classes/sun/security/ssl/BaseSSLSocketImpl.java line 265: > >> 263: } >> 264: >> 265: /** > > Can you please add a quick couple lines here with the technical rationale for removing it, so we don't forget down the road. > > i.e. > > There used to be a finalize() here, but decided that was not > needed. If users don't properly close the socket... > > The native resources are handled by the Socket Cleaner. It may be not common to comment on non-existing method. Maybe, the class description could be a place to add this note. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From arjan.tijms at gmail.com Mon May 2 07:24:59 2022 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 2 May 2022 09:24:59 +0200 Subject: Timeframe for JEP-411 completely removing SecurityManager APIs In-Reply-To: <71edaa17-418a-9852-4898-c0657b90d919@zeus.net.au> References: <71edaa17-418a-9852-4898-c0657b90d919@zeus.net.au> Message-ID: Hi, On Monday, May 2, 2022, Peter Firmstone wrote: I guess I'm just trying to say we need more time, the process of > extricating SM for security will take years, if we can leave SM as it is in > deprecated form for a number of years, that would be greatly appreciated. Just wondering, but would it not be an option to just keep using the last LTS that has the SM? That may well enable you to keep using the SM for something like 10 years? Kind regards, Arjan Tijms > > Regards, > > Peter. > > On 27/04/2022 3:38 am, Sean Mullan wrote: > >> >> >> On 4/26/22 1:06 PM, Scott Stark wrote: >> >>> By "migration feature" I'm talking about being able to retain the type >>> of library code where one has a conditional call to an >>> AccessController::doPrivileged(...) method that is only done when >>> System.getSecurityManager() is not null. Not having to remove this code in >>> all dependent libraries for a given Jakarta EE application server product >>> in order to run on Java SE 21 is seen as necessary to navigate supporting >>> application servers over a range of Java SE versions. The general consensus >>> was that having to deal with Java SE 11, 17 and 21 would only be possible >>> if this SecurityManager related code could remain as is, even if the only >>> executed path would be for System.getSecurityManager() == null. We can >>> deal with a gradual degradation of the SecurityManager behavior, but it was >>> unclear if Java SE 21 was looking for a complete removal of the APIs the >>> libraries use. >>> >> >> Yes, we understand these concerns. We recognize the compatibility issues >> and the importance for code using the SM APIs to continue to work as if an >> SM has not been enabled. This is the motivation behind the language in the >> JEP that discusses a gradual degradation and phasing out of the SM APIs >> until the compatibility risk is low enough that removal is acceptable. >> >> Also, you mention SE 21, but as of yet there is not yet a targeted >> release for the SM removal. There will likely be a JEP for the removal of >> the SM and this will need to go through several phases of the JEP process >> before it can be targeted to a specific release. >> >> I'm sure many of the Jakarta EE platform dev members have code >>> repositories to offer for scanning to aide in determining when the >>> SecurityManager dependencies have been removed. If there is a avenue for >>> that information, please let me know. >>> >> >> Thanks for that offer. I don't have an avenue for that information yet, >> but I will see if we can start creating a list of significant SM-enabled >> libraries and other projects that we can monitor over time. >> >> --Sean >> >> Thanks, >>> Scott >>> >>> On Apr 26, 2022 at 11:09:22 AM, Sean Mullan >> > wrote: >>> >>>> Hello Scott, >>>> >>>> On 4/25/22 2:25 PM, Scott Stark wrote: >>>> >>>>> Hello, >>>>> >>>>> I'm Scott Stark of Red Hat, and a member of the Jakarta EE platform dev >>>>> group (EEPD). I'm currently coordinating the Jakarta EE 10 release that >>>>> is targeting June of this year (2022). The removal of the >>>>> SecurityManager as described in JEP-411 has been a topic for the EEPD >>>>> on >>>>> may calls this year. Recent discussions make it clear that any >>>>> SecurityManager alternative would need to be taken up by the EEPD, and >>>>> such an effort is going to be a non-trivial undertaking, and may not be >>>>> addressed at all. >>>>> >>>>> A general concern among vendors in the EEPD is the timeframe for the >>>>> code that bridges between the JVM running with and without a >>>>> SecurityManager instance needing to be updated. Such code is the >>>>> subject >>>>> of this JEP-411 paragraph: >>>>> >>>>> "In feature releases after Java 18, we will degrade other Security >>>>> Manager APIs so that they remain in place but with limited or no >>>>> functionality. For example, we may revise >>>>> AccessController::doPrivileged >>>>> simply to run the given action, or revise System::getSecurityManager >>>>> always to return null. This will allow libraries that support the >>>>> Security Manager and were compiled against previous Java releases to >>>>> continue to work without change or even recompilation. We expect to >>>>> remove the APIs once the compatibility risk of doing so declines to an >>>>> acceptable level." >>>>> >>>>> Of particular interest is the timeframe for "remove the APIs once the >>>>> compatibility risk of doing so declines to an acceptable level". >>>>> >>>>> Vendors in EEPD would like to see Java SE 21 ship with a migration >>>>> feature along the lines of the proposed "AccessController::doPrivilege >>>>> d >>>>> simply to run the given action, or revise System::getSecurityManager >>>>> always to return null" behaviors. >>>>> >>>> >>>> Can you clarify what you mean by "a migration feature" and also provide >>>> some background as to why vendors in EEPD would like to see this? Do you >>>> mean something like a system property that enables the degraded behavior >>>> as described above? >>>> >>>> Is there some metric for tracking "when the compatibility risk of doing >>>>> so declines to an acceptable level."? I believe the EEPD vendors would >>>>> like readiness of their projects and upstream dependencies to somehow >>>>> be >>>>> included in any such tracking. >>>>> >>>> >>>> So, first we do not yet have a proposed target date for when we would >>>> like to remove support for the Security Manager (SM) from the JDK. By >>>> removing support, I mean that the JDK would no longer include a SM >>>> implementation. However, I don't anticipate that any SM specific APIs >>>> would be degraded *prior* to removing SM support from the JDK. >>>> >>>> Some APIs will likely be degraded as described above at the same time we >>>> remove support for the SM from the JDK. >>>> >>>> As for when the APIs will actually be removed, this will most likely be >>>> a longer period, possibly several JDK releases. We recognize that many >>>> libraries and applications will need time to adapt to the changes and >>>> remove dependencies on the APIs. We have tools that check open source >>>> repositories for API dependencies and are able to provide us with data >>>> that helps assess the compatibility risk. However, I can't give you a >>>> timeframe for API removal yet. >>>> >>>> HTH, >>>> Sean >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Mon May 2 08:30:34 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 2 May 2022 18:30:34 +1000 Subject: Timeframe for JEP-411 completely removing SecurityManager APIs In-Reply-To: References: <71edaa17-418a-9852-4898-c0657b90d919@zeus.net.au> Message-ID: <364cd9aa-a345-b5ca-8c92-989802c28895@zeus.net.au> Hi Arjan, Java 8 is supported until 2030, and 17 to 2029, we would be unable to continue testing against new Java releases. https://bugs.openjdk.java.net/browse/JDK-8272340 With this choice, there will be incompatible Java versions we must prevent our software from running on, until it becomes possible to support a later version. It also means that someone who wants to use new Java API's on a Java version we don't support may be forced to migrate away from using our software.?? It also means that we will be unable to take advantage of new Java API's which may put us at a significant disadvantage. Regards, Peter. On 2/05/2022 5:24 pm, arjan tijms wrote: > Hi, > > On Monday, May 2, 2022, Peter Firmstone > wrote: > > I guess I'm just trying to say we need more time, the process of > extricating SM for security will take years, if we can leave SM as > it is in deprecated form for a number of years, that would be > greatly appreciated. > > > Just wondering, but would it not be an option to just keep using the > last LTS that has the SM? That may well enable you to keep using the > SM for something like 10 years? > > Kind regards, > Arjan Tijms > > > > Regards, > > Peter. > > On 27/04/2022 3:38 am, Sean Mullan wrote: > > > > On 4/26/22 1:06 PM, Scott Stark wrote: > > By "migration feature" I'm talking about being able to > retain the type of library code where one has a > conditional call to an AccessController::doPrivileged(...) > method that is only done when System.getSecurityManager() > is not null. Not having to remove this code in all > dependent libraries for a given Jakarta EE application > server product in order to run on Java SE 21 is seen as > necessary to navigate supporting application servers over > a range of Java SE versions. The general consensus was > that having to deal with Java SE 11, 17 and 21 would only > be possible if this SecurityManager related code could > remain as is, even if the only executed path would be > for?System.getSecurityManager() == null. We can deal with > a gradual degradation of the SecurityManager behavior, but > it was unclear if Java SE 21 was looking for a complete > removal of the APIs the libraries use. > > > Yes, we understand these concerns. We recognize the > compatibility issues and the importance for code using the SM > APIs to continue to work as if an SM has not been enabled. > This is the motivation behind the language in the JEP that > discusses a gradual degradation and phasing out of the SM APIs > until the compatibility risk is low enough that removal is > acceptable. > > Also, you mention SE 21, but as of yet there is not yet a > targeted release for the SM removal. There will likely be a > JEP for the removal of the SM and this will need to go through > several phases of the JEP process before it can be targeted to > a specific release. > > I'm sure many of the Jakarta EE platform dev members have > code repositories to offer for scanning to aide in > determining when the SecurityManager dependencies have > been removed. If there is a avenue for that information, > please let me know. > > > Thanks for that offer. I don't have an avenue for that > information yet, but I will see if we can start creating a > list of significant SM-enabled libraries and other projects > that we can monitor over time. > > --Sean > > Thanks, > Scott > > On Apr 26, 2022 at 11:09:22 AM, Sean Mullan > > > wrote: > > Hello Scott, > > On 4/25/22 2:25 PM, Scott Stark wrote: > > Hello, > > I'm Scott Stark of Red Hat, and a member of the > Jakarta EE platform dev > group (EEPD). I'm currently coordinating the > Jakarta EE 10 release that > is targeting June of this year (2022). The removal > of the > SecurityManager as described in JEP-411 has been a > topic for the EEPD on > may calls this year. Recent discussions make it > clear that any > SecurityManager alternative would need to be taken > up by the EEPD, and > such an effort is going to be a non-trivial > undertaking, and may not be > addressed at all. > > A general concern among vendors in the EEPD is the > timeframe for the > code that bridges between the JVM running with and > without a > SecurityManager instance needing to be updated. > Such code is the subject > of this JEP-411 paragraph: > > "In feature releases after Java 18, we will > degrade other Security > Manager APIs so that they remain in place but with > limited or no > functionality. For example, we may revise > AccessController::doPrivileged > simply to run the given action, or revise > System::getSecurityManager > always to return null. This will allow libraries > that support the > Security Manager and were compiled against > previous Java releases to > continue to work without change or even > recompilation. We expect to > remove the APIs once the compatibility risk of > doing so declines to an > acceptable level." > > Of particular interest is the timeframe for > "remove the APIs once the > compatibility risk of doing so declines to an > acceptable level". > > Vendors in EEPD would like to see Java SE 21 ship > with a migration > feature along the lines of the proposed > "AccessController::doPrivileged > simply to run the given action, or revise > System::getSecurityManager > always to return null" behaviors. > > > Can you clarify what you mean by "a migration feature" > and also provide > some background as to why vendors in EEPD would like > to see this? Do you > mean something like a system property that enables the > degraded behavior > as described above? > > Is there some metric for tracking "when the > compatibility risk of doing > so declines to an acceptable level."? I believe > the EEPD vendors would > like readiness of their projects and upstream > dependencies to somehow be > included in any such tracking. > > > So, first we do not yet have a proposed target date > for when we would > like to remove support for the Security Manager (SM) > from the JDK. By > removing support, I mean that the JDK would no longer > include a SM > implementation. However, I don't anticipate that any > SM specific APIs > would be degraded *prior* to removing SM support from > the JDK. > > Some APIs will likely be degraded as described above > at the same time we > remove support for the SM from the JDK. > > As for when the APIs will actually be removed, this > will most likely be > a longer period, possibly several JDK releases. We > recognize that many > libraries and applications will need time to adapt to > the changes and > remove dependencies on the APIs. We have tools that > check open source > repositories for API dependencies and are able to > provide us with data > that helps assess the compatibility risk. However, I > can't give you a > timeframe for API removal yet. > > HTH, > Sean > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mullan at openjdk.java.net Mon May 2 13:26:49 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 2 May 2022 13:26:49 GMT Subject: RFR: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file [v2] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 21:49:32 GMT, Weijun Wang wrote: >> We added a new system property back in https://bugs.openjdk.java.net/browse/JDK-8153005 but it's better to describe it in the `java.security` file as well. >> >> Please review the text. I especially added the last sentence so that people won't set `-Dkeystore.pkcs12.legacy=false`. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > clearer text Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8452 From weijun at openjdk.java.net Mon May 2 14:06:43 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 2 May 2022 14:06:43 GMT Subject: Integrated: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 14:35:54 GMT, Weijun Wang wrote: > We added a new system property back in https://bugs.openjdk.java.net/browse/JDK-8153005 but it's better to describe it in the `java.security` file as well. > > Please review the text. I especially added the last sentence so that people won't set `-Dkeystore.pkcs12.legacy=false`. This pull request has now been integrated. Changeset: cfcba1fc Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4 Stats: 24 lines in 1 file changed: 20 ins; 0 del; 4 mod 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/8452 From xueleifan at tencent.com Mon May 2 15:12:14 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Mon, 2 May 2022 15:12:14 +0000 Subject: Interesting in DTLS 1.3 Message-ID: <15CAF7B8-A506-4105-91DE-8B6D65A5E6D5@Tencent.Com> Hi, The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 (DTLS 1.3) has been published on April 2022. The specification describes the most current version of the DTLS protocol as a delta from TLS 1.3 and obsoletes DTLS 1.2. In JDK, the Java specifications for DTLS 1.0 and DTLS 1.2 are defined and implemented. For DTLS 1.3, there may be three different choices for JDK. The 1st one is doing nothing, and JDK will not support DTLS 1.3 in the future. The 2nd one is define the specification in JDK, but without the implementation. Third party?s provider could have the implementation if this feature is required in some circumstances. The 3rd one, as DTLS 1.0 and DTLS 1.2, is to have an implementation in JDK. Are you using DTLS protocols in your applications? Is anyone interested in have DTLS 1.3 in JDK? Which option is best for you? Thanks, Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun at openjdk.java.net Mon May 2 15:17:48 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 2 May 2022 15:17:48 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v13] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 18:32:31 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the java.security.jgss module. It is one of the efforts to clean up the use of finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > add sleep back LGTM ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8136 From xuelei at openjdk.java.net Mon May 2 15:27:39 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 2 May 2022 15:27:39 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v14] In-Reply-To: References: Message-ID: > Please review the update to remove finalizer method in the java.security.jgss module. It is one of the efforts to clean up the use of finalizer method in JDK. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: add intermittent test keyword ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8136/files - new: https://git.openjdk.java.net/jdk/pull/8136/files/d554c724..e933d404 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=12-13 Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8136.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8136/head:pull/8136 PR: https://git.openjdk.java.net/jdk/pull/8136 From xueleifan at tencent.com Mon May 2 15:31:50 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Mon, 2 May 2022 15:31:50 +0000 Subject: Interesting in TLS Ticket Requests Message-ID: <6C0B636F-1E03-4548-9832-BA8E210F271D@Tencent.Com> Hi, A new standard, RFC 9149 TLS Ticket Requests, was published on April 2022. Is anyone interested in have it implemented in JDK? As described in RFC 8446/TLS 1.3, TLS servers vend clients an arbitrary number of session tickets for session resumption. However, the number may be not what clients desired. For security reason, session ticket can be used only one time. If the client desired number and server supplied number does not match, the performance impact could be significant. Currently, in JDK, the server vends only one session ticket for each handshaking. However, clients can open parallel TLS connections to the same server for HTTP, or they can race TLS connections across different network interfaces. In such circumstances, one session ticket is hardly to be good for TLS connections performance. But, without an explicit desired number requested from the client, it is hard to know what is the best number of session tickets that the server should vend to clients. The issues could be addressed with RFC 9149, TLS Ticket Requests. Are you interested to have the TLS Ticket Requests feature in JDK? Please let me know your ideas and concerns. Thanks, Xuelei From mullan at openjdk.java.net Mon May 2 15:41:44 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 2 May 2022 15:41:44 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v5] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 19:42:27 GMT, Hai-May Chao wrote: >> Please review these changes to add DES/3DES/MD5 to `jdk.security.legacyAlgorithms` security property, and to add the legacy algorithm constraint checking to `keytool` commands that are associated with secret key entries stored in the keystore. These `keytool` commands are -genseckey, -importpass, -list, and -importkeystore. As a result, `keytool` will be able to generate warnings when it detects that the secret key based algorithms and PBE based Mac and cipher algorithms are weak. Also removes the "This algorithm will be disabled in a future update.? from the existing warnings for the asymmetric keys/certificates. >> Will also file a CSR. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Updated spec in java.security Changes requested by mullan (Reviewer). src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2196: > 2194: > 2195: try { > 2196: SecretKey secKey = (SecretKey) keyStore.getKey(alias, storePass); This means any secret key entries that are protected by a different password than `storePass` will throw an `UnrecoverableKeyException` and we will not be able to check the constraints. For PKCS12 this is not an issue since `storePass` and `keyPass` have to be the same. But for other keystores like JCEKS it might be a problem. However, I note this is not really a new issue as details about secret key entries other than the fact they exist as entries are not listed, presumably because we may not have the right password. I would recommend adding a comment explaining this. For a future RFE, it might be useful to enhance `keytool -list -alias` to have a `-keypass` option so that additional information for entries protected by a different password than `storePass` could be listed, such as their algorithm and key size. src/java.base/share/classes/sun/security/tools/keytool/Main.java line 5039: > 5037: private void checkWeakConstraint(String label, String algName, > 5038: ConstraintsParameters cp) { > 5039: // Do not check disabled algorithms for symmetric key based algorithms for now If this method is intended only to be called for symmetric keys, you should change the type of `cp` to `SecretKeyConstraintsParameters`. src/java.base/share/classes/sun/security/tools/keytool/Main.java line 5248: > 5246: private static class SecretKeyConstraintsParameters implements ConstraintsParameters { > 5247: private final Key key; > 5248: public SecretKeyConstraintsParameters(Key key) { This ctor could just be private. src/java.base/share/classes/sun/security/tools/keytool/Main.java line 5259: > 5257: @Override > 5258: public Set getKeys() { > 5259: return null; You should return `Set.of(key)` here. This allows the constraints to also check the key size, if that is also restricted. I would suggest adding a test where `jdk.security.legacyAlgorithms` includes a constraint for "AES < 256" to see if `keytool` warns about it when generating an AES key of 128 bits. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From wetmore at openjdk.java.net Mon May 2 16:49:51 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Mon, 2 May 2022 16:49:51 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v3] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 05:01:21 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the SunJSSE provider implementation. It is one of the efforts to clean up the use of finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > comment about remove finalize() method src/java.base/share/classes/sun/security/ssl/BaseSSLSocketImpl.java line 44: > 42: * overridden in SSLSocketImpl. > 43: * > 44: * There used to be a finalize() implementation, but decided that was Since you haven't pushed yet, maybe: There used to be a finalize() implementation that sent close_notify's, but decided that was not needed. An application should close its sockets and not let them get garbage collected without closing them. The underlying native resources are handled by the Socket Cleaner. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From weijun at openjdk.java.net Mon May 2 17:58:05 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 2 May 2022 17:58:05 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v5] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 19:42:27 GMT, Hai-May Chao wrote: >> Please review these changes to add DES/3DES/MD5 to `jdk.security.legacyAlgorithms` security property, and to add the legacy algorithm constraint checking to `keytool` commands that are associated with secret key entries stored in the keystore. These `keytool` commands are -genseckey, -importpass, -list, and -importkeystore. As a result, `keytool` will be able to generate warnings when it detects that the secret key based algorithms and PBE based Mac and cipher algorithms are weak. Also removes the "This algorithm will be disabled in a future update.? from the existing warnings for the asymmetric keys/certificates. >> Will also file a CSR. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Updated spec in java.security If one generates a secret key with `-keyalg des`, then the warning message also uses lowercase `des`. It probably should be standardized. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From xuelei at openjdk.java.net Mon May 2 17:59:05 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 2 May 2022 17:59:05 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v4] In-Reply-To: References: Message-ID: > Please review the update to remove finalizer method in the SunJSSE provider implementation. It is one of the efforts to clean up the use of finalizer method in JDK. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: update the note ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8065/files - new: https://git.openjdk.java.net/jdk/pull/8065/files/c90e25a1..6130f5e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8065&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8065&range=02-03 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8065/head:pull/8065 PR: https://git.openjdk.java.net/jdk/pull/8065 From xuelei at openjdk.java.net Mon May 2 17:59:08 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 2 May 2022 17:59:08 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v3] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 16:46:17 GMT, Bradford Wetmore wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> comment about remove finalize() method > > src/java.base/share/classes/sun/security/ssl/BaseSSLSocketImpl.java line 44: > >> 42: * overridden in SSLSocketImpl. >> 43: * >> 44: * There used to be a finalize() implementation, but decided that was > > Since you haven't pushed yet, maybe: > > There used to be a finalize() implementation that sent close_notify's, but decided that was not needed. Not closing properly is more properly an error condition that should be avoided. Applications should close sockets and not rely on garbage collection. > > The underlying native resources are handled by the Socket Cleaner. Thanks for the rewording. Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From wetmore at openjdk.java.net Mon May 2 17:59:09 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Mon, 2 May 2022 17:59:09 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v3] In-Reply-To: References: Message-ID: <6ekWrHqRR8yPmalTH2sGwUD2E1RNwRy6b2NKYr9lwnU=.1b1ecc3c-99c5-462f-ba61-665cb7c3a42c@github.com> On Mon, 2 May 2022 17:45:44 GMT, Xue-Lei Andrew Fan wrote: > Thanks for the rewording. Updated. I made one more tweak that reads better. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From valeriep at openjdk.java.net Mon May 2 18:21:48 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 2 May 2022 18:21:48 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 19:17:08 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update for getParameters() > > src/java.base/share/classes/javax/crypto/Cipher.java line 1056: > >> 1054: * parameters were not supplied and the underlying cipher implementation >> 1055: * can generate the parameter values, it will be returned. Otherwise, >> 1056: * {@code null} returned. > > Should this be "null is returned"? Yes, will fix. > src/java.base/share/classes/javax/crypto/Cipher.java line 1787: > >> 1785: * Ensures that Cipher is in a valid state for update() and doFinal() >> 1786: * calls - should be initialized and in ENCRYPT_MODE or DECRYPT_MODE. >> 1787: * @throws IllegalStateException if Cipher object is not in valid state > > "Cipher" in `{@code}`? Or make it lowercase. Ok, I will use lowercase. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From valeriep at openjdk.java.net Mon May 2 20:50:23 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 2 May 2022 20:50:23 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 19:23:18 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update for getParameters() > > src/java.base/share/classes/javax/crypto/CipherSpi.java line 449: > >> 447: * >> 448: *

Note that when a Cipher object is initialized, it loses all >> 449: * previously-acquired state. In other words, initializing a Cipher is > > Two `{@code Cipher}` above. Yes, I will look through the whole class (and CipherSpi.java too) regarding the Cipher vs cipher thing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From valeriep at openjdk.java.net Mon May 2 20:55:31 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 2 May 2022 20:55:31 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v3] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 15:18:34 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update for getParameters() > > src/java.base/share/classes/javax/crypto/Cipher.java line 1055: > >> 1053: * values used by the underlying cipher implementation. If the required >> 1054: * parameters were not supplied and the underlying cipher implementation >> 1055: * can generate the parameter values, it will be returned. Otherwise, > > "it will be returned" sounds a bit awkward here. I would change this to "the generated parameter values will be returned". Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From valeriep at openjdk.java.net Mon May 2 21:15:40 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 2 May 2022 21:15:40 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v3] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 15:23:47 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update for getParameters() > > src/java.base/share/classes/javax/crypto/Cipher.java line 1053: > >> 1051: *

The returned parameters may be the same that were used to initialize >> 1052: * this cipher, or may contain additional default or random parameter >> 1053: * values used by the underlying cipher implementation. If the required > > The PR for https://github.com/openjdk/jdk/pull/8396/ has one difference in this sentence in that it says "... values used by the underlying signature implementation _if the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}_." Should this also be consistent? > > Also, I don't think you need to repeat "underlying signature " again above, you could just say: ... values used by the underlying signature implementation _if the implementation supports returning the parameters as {@code AlgorithmParameters}_." Signature class has that sentence is due to the peculiar case of EdDSA signature impl where its parameter spec does not correlate to an ASN.1 structure. Since there is no such case for current cipher impls (as far as I know), that's why I have not added it to Cipher class. Ok, how about `If the required parameters were not supplied and can be generated by the cipher, the generated parameters will be returned.`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From weijun at openjdk.java.net Mon May 2 21:16:49 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 2 May 2022 21:16:49 GMT Subject: RFR: 8286024: PKCS12 keystore shows "DES/CBC" as the algorithm of a DES SecretKeyEntry Message-ID: <4N_Lg4q76uM0AFTgCajP2nPwWJcPOvTOohXam2s_4B4=.b419d411-8f2a-4d97-93e1-bb9a8801ea8c@github.com> PKCS12 stores the object identifier of a SecretKey along with it, and when retrieved, translate the object identifier to an algorithm name. Unfortunately, inside `KnownOIDs.java`, "DES" is [only registered as](https://github.com/wangweij/jdk/blob/7a6cbef157b67bb4fb877617f2a23228aade9a5d/src/java.base/share/classes/sun/security/util/KnownOIDs.java#L368-L368) an alias of another name "DES/CBC". We should modify it to "DES" before returning the secret key. ------------- Commit messages: - remove exe bits - fix Changes: https://git.openjdk.java.net/jdk/pull/8505/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8505&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286024 Stats: 53 lines in 2 files changed: 52 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8505.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8505/head:pull/8505 PR: https://git.openjdk.java.net/jdk/pull/8505 From valeriep at openjdk.java.net Mon May 2 21:17:43 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 2 May 2022 21:17:43 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: References: <77iS1t15rXz0DnqsXKuRifJPbAYGLlJOTnqRt1cdKcE=.11167daf-c2ba-48d3-b14a-26a0914c554a@github.com> Message-ID: On Thu, 28 Apr 2022 23:28:39 GMT, Weijun Wang wrote: >> The impl does not need to generate parameter values, but rather cannot convert the supplied parameter values into AlgorithmParameter objects. By parameter values, I mean the components of the parameters. > > Then what does "cannot generate parameter values" mean? Any example? An example is RSASSA-PSS, i.e. it requires the caller to explicitly state which message digest to use, etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From valeriep at openjdk.java.net Mon May 2 21:46:20 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 2 May 2022 21:46:20 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: References: <7qogGHJ9jGPj6K6qqYVFnDfSUcSqJNB0jLifgJshstY=.be9bb286-dbce-446c-9684-dfa77ec2d0a4@github.com> <6YhRhen4o8Kg5pwhGxLF__535eB9ggQ57I6m6wu6oo4=.b4d0d99f-6d06-4ce7-8986-6470bae6a6f0@github.com> <7tFALuKc9QcTFYSzxokreBbeA3X5BpWIxqd mHoXjzNM=.c1ab3294-2edc-481e-a0e1-cf2e2731881a@github.com> Message-ID: On Fri, 29 Apr 2022 04:27:36 GMT, Xue-Lei Andrew Fan wrote: >> What kind of additional sentence do you have in mind? > >> What kind of additional sentence do you have in mind? > > It may be fine to put it into the state for 'null" returned value. For example: > > > The returned parameters may be the same that were used to initialize > this signature, or may contain additional default or random parameter > values used by the underlying signature implementation, or null if the > underlying signature implementation does not support returning the > parameters as {@code AlgorithmParameters}. > > > > The null return conditional in the following sentence may be able to combine together. > > > The returned parameters may be the same that were used to initialize > this signature, or may contain additional default or random parameter > values used by the underlying signature implementation. {@code null} > may be returned if the underlying signature implementation does not > support returning the parameters as {@code AlgorithmParameters}, or How about the case when no parameters are given? Say A is the user-supplied values, B is the provider specific default or random values, your suggestion has A, A+B, and null. Isn't the sentence about B needed (no A and provider can generate the parameters)? ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From valeriep at openjdk.java.net Mon May 2 22:07:22 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 2 May 2022 22:07:22 GMT Subject: RFR: 8286024: PKCS12 keystore shows "DES/CBC" as the algorithm of a DES SecretKeyEntry In-Reply-To: <4N_Lg4q76uM0AFTgCajP2nPwWJcPOvTOohXam2s_4B4=.b419d411-8f2a-4d97-93e1-bb9a8801ea8c@github.com> References: <4N_Lg4q76uM0AFTgCajP2nPwWJcPOvTOohXam2s_4B4=.b419d411-8f2a-4d97-93e1-bb9a8801ea8c@github.com> Message-ID: On Mon, 2 May 2022 17:41:52 GMT, Weijun Wang wrote: > PKCS12 stores the object identifier of a SecretKey along with it, and when retrieved, translate the object identifier to an algorithm name. Unfortunately, inside `KnownOIDs.java`, "DES" is [only registered as](https://github.com/wangweij/jdk/blob/7a6cbef157b67bb4fb877617f2a23228aade9a5d/src/java.base/share/classes/sun/security/util/KnownOIDs.java#L368-L368) an alias of another name "DES/CBC". We should modify it to "DES" before returning the secret key. Looks fine. Thanks. ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8505 From bchristi at openjdk.java.net Mon May 2 22:38:26 2022 From: bchristi at openjdk.java.net (Brent Christian) Date: Mon, 2 May 2022 22:38:26 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v14] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 15:27:39 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the java.security.jgss module. It is one of the efforts to clean up the use of finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > add intermittent test keyword Hi. Sorry, I should have brought this up earlier, but there is a jtreg test library to help with ensuring the GC runs, `test/lib/jdk/test/lib/util/ForceGC.java`. You might consider replacing the test code that runs/checks the GC with `ForceGC.await()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From duke at openjdk.java.net Mon May 2 22:39:09 2022 From: duke at openjdk.java.net (Mark Powers) Date: Mon, 2 May 2022 22:39:09 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v4] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8284688 > > [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: > > open/src/java.security.jgss/share/classes/javax/security > open/src/java.security.jgss/share/classes/org/ietf > open/src/java.security.jgss/share/classes/sun/security Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - sixth iteration - Merge - fifth iteration - Merge - fourth iteration - third iteration - Merge - Merge - Merge - second iteration - ... and 1 more: https://git.openjdk.java.net/jdk/compare/64225e19...5ce46ffb ------------- Changes: https://git.openjdk.java.net/jdk/pull/7746/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7746&range=03 Stats: 927 lines in 73 files changed: 88 ins; 193 del; 646 mod Patch: https://git.openjdk.java.net/jdk/pull/7746.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7746/head:pull/7746 PR: https://git.openjdk.java.net/jdk/pull/7746 From weijun at openjdk.java.net Mon May 2 22:41:37 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 2 May 2022 22:41:37 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v5] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 19:42:27 GMT, Hai-May Chao wrote: >> Please review these changes to add DES/3DES/MD5 to `jdk.security.legacyAlgorithms` security property, and to add the legacy algorithm constraint checking to `keytool` commands that are associated with secret key entries stored in the keystore. These `keytool` commands are -genseckey, -importpass, -list, and -importkeystore. As a result, `keytool` will be able to generate warnings when it detects that the secret key based algorithms and PBE based Mac and cipher algorithms are weak. Also removes the "This algorithm will be disabled in a future update.? from the existing warnings for the asymmetric keys/certificates. >> Will also file a CSR. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Updated spec in java.security test/jdk/sun/security/tools/keytool/WeakSecretKeyTest.java line 66: > 64: .shouldContain("Warning") > 65: .shouldMatch(" uses the DESede algorithm.*considered a security risk") > 66: .shouldMatch(" uses the DES/CBC algorithm.*considered a security risk") Please update "DES/CBC" to "DES". I've just fixed it with https://github.com/openjdk/jdk/commit/50a4df87c87febdf5fa8561b7d0d21b8d6623943. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From weijun at openjdk.java.net Mon May 2 22:41:40 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 2 May 2022 22:41:40 GMT Subject: Integrated: 8286024: PKCS12 keystore shows "DES/CBC" as the algorithm of a DES SecretKeyEntry In-Reply-To: <4N_Lg4q76uM0AFTgCajP2nPwWJcPOvTOohXam2s_4B4=.b419d411-8f2a-4d97-93e1-bb9a8801ea8c@github.com> References: <4N_Lg4q76uM0AFTgCajP2nPwWJcPOvTOohXam2s_4B4=.b419d411-8f2a-4d97-93e1-bb9a8801ea8c@github.com> Message-ID: On Mon, 2 May 2022 17:41:52 GMT, Weijun Wang wrote: > PKCS12 stores the object identifier of a SecretKey along with it, and when retrieved, translate the object identifier to an algorithm name. Unfortunately, inside `KnownOIDs.java`, "DES" is [only registered as](https://github.com/wangweij/jdk/blob/7a6cbef157b67bb4fb877617f2a23228aade9a5d/src/java.base/share/classes/sun/security/util/KnownOIDs.java#L368-L368) an alias of another name "DES/CBC". We should modify it to "DES" before returning the secret key. This pull request has now been integrated. Changeset: 50a4df87 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/50a4df87c87febdf5fa8561b7d0d21b8d6623943 Stats: 53 lines in 2 files changed: 52 ins; 0 del; 1 mod 8286024: PKCS12 keystore shows "DES/CBC" as the algorithm of a DES SecretKeyEntry Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/8505 From hchao at openjdk.java.net Mon May 2 22:54:24 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Mon, 2 May 2022 22:54:24 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v5] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 22:38:18 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated spec in java.security > > test/jdk/sun/security/tools/keytool/WeakSecretKeyTest.java line 66: > >> 64: .shouldContain("Warning") >> 65: .shouldMatch(" uses the DESede algorithm.*considered a security risk") >> 66: .shouldMatch(" uses the DES/CBC algorithm.*considered a security risk") > > Please update "DES/CBC" to "DES". I've just fixed it with https://github.com/openjdk/jdk/commit/50a4df87c87febdf5fa8561b7d0d21b8d6623943. Ok, thanks for the heads-up. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From valeriep at openjdk.java.net Mon May 2 23:22:18 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 2 May 2022 23:22:18 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v4] In-Reply-To: References: Message-ID: > Anyone can help review this javadoc update? The main change is the wording for the method javadoc of Cipher.getParameters()/CipherSpi.engineGetParameters(). The original wording is somewhat restrictive and request is to broaden this to accommodate more scenarios such as when null can be returned. > The rest are minor things like add {@code } to class name and null, and remove redundant ".". > > Will file CSR after the review is close to being wrapped up. > Thanks~ Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: update to address review feedback and minor javadoc cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8117/files - new: https://git.openjdk.java.net/jdk/pull/8117/files/baae26fe..77e8fa0d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8117&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8117&range=02-03 Stats: 171 lines in 2 files changed: 1 ins; 0 del; 170 mod Patch: https://git.openjdk.java.net/jdk/pull/8117.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8117/head:pull/8117 PR: https://git.openjdk.java.net/jdk/pull/8117 From weijun at openjdk.java.net Tue May 3 00:20:24 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 3 May 2022 00:20:24 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: References: <77iS1t15rXz0DnqsXKuRifJPbAYGLlJOTnqRt1cdKcE=.11167daf-c2ba-48d3-b14a-26a0914c554a@github.com> Message-ID: On Mon, 2 May 2022 21:14:21 GMT, Valerie Peng wrote: >> Then what does "cannot generate parameter values" mean? Any example? > > An example is RSASSA-PSS, i.e. it requires the caller to explicitly state which message digest to use, etc. You listed 2 cases when null is returned: 1) not supplied. 2) cannot generate. My understanding is that the RSASSA-PSS case is 1), and the EdDSA case is 2). This is why I suggested an "or" relation between them. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From vitaly.provodin at jetbrains.com Tue May 3 00:56:19 2022 From: vitaly.provodin at jetbrains.com (Vitaly Provodin) Date: Tue, 3 May 2022 07:56:19 +0700 Subject: zlib before 1.2.12 allows memory corruption (CVE-2018-25032) In-Reply-To: References: <8EA8A007-5C47-46CF-B126-6C57DCDAB281@jetbrains.com> Message-ID: Volker, Bernd, thanks for the replies - they were really useful Vitaly > On 27 Apr 2022, at 14:59, Volker Simonis wrote: > > Hi Bernd, Vitaly, > > Amazon Corretto [1] also includes the fixes for CVE-2018-25032. This > is our statement: > > "Based upon our analysis, OpenJDK/Corretto is not affected by > CVE-2018-25032, because the zlib "memLevel" parameter is not settable > and is fixed at 8, and the usage of the Z_FIXED strategy is prevented. > With these settings there is no way to invoke the issue described in > the CVE and we only include this fix out of an abundance of caution." > > You're right that the vulnerability can also be exploited without the > Z_FIXED strategy, but in that case only with memLevel set to "1" (see > [2] for more details). > > Given all the currently available information, I don't think there's a > reason to worry because of CVE-2018-25032 in the context of Java. > > Best regards, > Volker > > [1] https://github.com/corretto/corretto-8/blob/release-8.332.08.1/CHANGELOG.md > [2] https://www.openwall.com/lists/oss-security/2022/03/28/1 > > On Wed, Apr 27, 2022 at 1:21 AM Bernd Eckenfels wrote: >> >> Hello Vitaly, >> >> (Personal answer not affiliated with OpenJDK members) >> >> I had also asked about this before, but there was no answer (which is however not surprising, since it is the policy of OpenJDK and Oracle to not comment on unfixed security issues). >> >> My hope was, that by reporting it before the April update, the (trivial?) zlib update would be merged, but it is still the old version according to the source files. So it depends on build parameters and exploitability of the weakness if you are still in danger (I guess:). >> >> BTW while I can understand to not publish unfixed problems, it does really not do the java users a favor to not comment on generally known/published problems, especially not for 2 quarters. >> >> There is however a ray of light on the horizon, I see CVE-2018-25032 fixed in the Azul April Release Notes and asume they provide the update out of band. (Probably only for Windows binaries, haven?t analysed them yet) >> >> They state: >>> Our analysis shows that Azul Zulu and OpenJDK are not affected by CVE-2018-25032. >>> In OpenJDK, the Zlib "memLevel" parameter is always set to 8 and can not be changed by a >>> Java code, and the Z_FIXED strategy is permanently disabled. The CVE does not apply to Azul >>> Zulu and OpenJDK with these settings. However, Azul decided to include the corresponding >>> patch to the Zlib library in Azul products just in case someone chooses to use Zlib from Azul >>> Zulu outside of Java applications. >> >> (I am not sure of the analysis is complete I think the z_fixed was not a strict requirement, but I could be wrong.) >> >> Hopefully the vulnerability group will share their finding in a few month. >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> ________________________________ >> Von: security-dev im Auftrag von Vitaly Provodin >> Gesendet: Thursday, April 21, 2022 2:06:57 AM >> An: security-dev at openjdk.java.net ; build-dev at openjdk.java.net >> Cc: Vitaly Provodin >> Betreff: zlib before 1.2.12 allows memory corruption (CVE-2018-25032) >> >> Hi all, >> >> Recently we (at JetBrains) were faced with the vulnerability issue CVE-2018-25032 (zlib before 1.2.12 allows memory corruption?) >> It is known that Linux, macOS builds uses system?s zlib but Windows - bundled one (by default). >> On Linux and macOS users can work around the issue by installing proper zlib on their systems. >> Are there any ideas for Windows? - the way building (under Cygwin!) with system zlib looks unworkable in case if Cygwin is not installed on user's machines. >> >> It looks like after implementing https://bugs.openjdk.java.net/browse/JDK-8249963 (which also discussed here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/067868.html) the resolution of such issues can be shifted to users but what can be done now? >> >> Thanks, >> Vitaly From weijun at openjdk.java.net Tue May 3 01:50:24 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 3 May 2022 01:50:24 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v4] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 22:39:09 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8284688 >> >> [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: >> >> open/src/java.security.jgss/share/classes/javax/security >> open/src/java.security.jgss/share/classes/org/ietf >> open/src/java.security.jgss/share/classes/sun/security > > Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - sixth iteration > - Merge > - fifth iteration > - Merge > - fourth iteration > - third iteration > - Merge > - Merge > - Merge > - second iteration > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/64225e19...5ce46ffb Many many thanks for this huge code change. No problem found. I have several comments and you're free to make your own decision. src/java.security.jgss/share/classes/org/ietf/jgss/GSSException.java line 333: > 331: public String getMajorString() { > 332: > 333: return Objects.requireNonNullElseGet(majorString, () -> messages[major - 1]); Isn't this too fancy? src/java.security.jgss/share/classes/sun/security/jgss/GSSHeader.java line 267: > 265: throw new IOException("DerInputStream.getLength(): lengthTag=" > 266: + tmp + ", " > 267: + "too big."); Combine the 2 lines above. src/java.security.jgss/share/classes/sun/security/jgss/krb5/SubjectComber.java line 154: > 152: while (iterator.hasNext()) { > 153: Object obj = iterator.next(); > 154: if (!(obj instanceof @SuppressWarnings("unchecked")KerberosTicket ticket)) { Does not look fluent to me. src/java.security.jgss/share/classes/sun/security/jgss/spnego/SpNegoContext.java line 876: > 874: > 875: // pass token > 876: tok = Objects.requireNonNullElseGet(token, () -> new byte[0]); Is this how `requireNonNullElseGet` is meant to be used? ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7746 From xuelei at openjdk.java.net Tue May 3 02:07:13 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 3 May 2022 02:07:13 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v5] In-Reply-To: References: Message-ID: > Please review the update to remove finalizer method in the SunJSSE provider implementation. It is one of the efforts to clean up the use of finalizer method in JDK. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: More note update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8065/files - new: https://git.openjdk.java.net/jdk/pull/8065/files/6130f5e6..8caf85af Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8065&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8065&range=03-04 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8065/head:pull/8065 PR: https://git.openjdk.java.net/jdk/pull/8065 From xuelei at openjdk.java.net Tue May 3 02:07:13 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 3 May 2022 02:07:13 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v3] In-Reply-To: <6ekWrHqRR8yPmalTH2sGwUD2E1RNwRy6b2NKYr9lwnU=.1b1ecc3c-99c5-462f-ba61-665cb7c3a42c@github.com> References: <6ekWrHqRR8yPmalTH2sGwUD2E1RNwRy6b2NKYr9lwnU=.1b1ecc3c-99c5-462f-ba61-665cb7c3a42c@github.com> Message-ID: On Mon, 2 May 2022 17:55:56 GMT, Bradford Wetmore wrote: >> Thanks for the rewording. Updated. > >> Thanks for the rewording. Updated. > > I made one more tweak that reads better. Yes, it looks better. Updated. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From xuelei at openjdk.java.net Tue May 3 02:23:23 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 3 May 2022 02:23:23 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v14] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 22:35:08 GMT, Brent Christian wrote: > Hi. Sorry, I should have brought this up earlier, but there is a jtreg test library to help with ensuring the GC runs, `test/lib/jdk/test/lib/util/ForceGC.java`. You might consider replacing the test code that runs/checks the GC with `ForceGC.await()`. It looks like a graceful GC utility. There are also some other test cases I committed that do no use ForceGC. I filed a [new bug](https://bugs.openjdk.java.net/browse/JDK-8286045), and will make the update all together. Thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From wetmore at openjdk.java.net Tue May 3 02:27:31 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 3 May 2022 02:27:31 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v3] In-Reply-To: References: <6ekWrHqRR8yPmalTH2sGwUD2E1RNwRy6b2NKYr9lwnU=.1b1ecc3c-99c5-462f-ba61-665cb7c3a42c@github.com> Message-ID: On Tue, 3 May 2022 02:02:58 GMT, Xue-Lei Andrew Fan wrote: >>> Thanks for the rewording. Updated. >> >> I made one more tweak that reads better. > > Yes, it looks better. Updated. Thanks! Looks good, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From dfuchs at openjdk.java.net Tue May 3 13:07:18 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 3 May 2022 13:07:18 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v5] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 02:07:13 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the SunJSSE provider implementation. It is one of the efforts to clean up the use of finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > More note update Given that this proposed change will change the behavior for SSLSocket (& SSLServerSocket?) I would also suggest to file a CSR before integrating. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From xuelei at openjdk.java.net Tue May 3 14:18:23 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 3 May 2022 14:18:23 GMT Subject: Integrated: 8284490: Remove finalizer method in java.security.jgss In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 04:10:55 GMT, Xue-Lei Andrew Fan wrote: > Please review the update to remove finalizer method in the java.security.jgss module. It is one of the efforts to clean up the use of finalizer method in JDK. This pull request has now been integrated. Changeset: ffca23a5 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/ffca23a5313855a6f9797ad6b342bb2e2cb1b49b Stats: 430 lines in 11 files changed: 393 ins; 12 del; 25 mod 8284490: Remove finalizer method in java.security.jgss Reviewed-by: rriggs, dfuchs, weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From duke at openjdk.java.net Tue May 3 14:44:12 2022 From: duke at openjdk.java.net (Mat Carter) Date: Tue, 3 May 2022 14:44:12 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 21:41:30 GMT, Mat Carter wrote: >> Same question. Does a new type name automagically add support for CNG? > > Correct, it does enable access to certificates and keys that require next (second) generation cryptographic providers, that were previously inaccessible. I've just realized the implication of this on existing applications and so I'm going to pause and run some test, especially around enumeration Correction: after looking at wincrypt.h, the documentation [1] and running tests, I can confirm that: 1) this change has no functional impact (i.e. results are unchanged) 2) HCRYPTPROV and HCRYPTPROV_OR_NCRYPT_KEY_HANDLE are both the same type (ULONG_PTR) and so are interchangeable (with the former supporting legacy applications) 3) There is only one function for CryptAcquireCertificatePrivateKey, not two differentiated by this parameter type change 4) support for CNG keys, which was originally thought to be added with this change, has always been true due to the existing use of the flag CRYPT_ACQUIRE_ALLOW_NCRYPT_KEY_FLAG I think this change should stay as it more correctly matches the prototype and the use of CRYPT_ACQUIRE_ALLOW_NCRYPT_KEY_FLAG [1] https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptacquirecertificateprivatekey ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From hchao at openjdk.java.net Tue May 3 14:54:05 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 3 May 2022 14:54:05 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v6] In-Reply-To: References: Message-ID: <7DIMYcZwPWJV-oOzfiP70gLFxf5A6CM8DNouAsjcfP0=.3f623026-be79-4d6c-946e-366ea59d98c0@github.com> > Please review these changes to add DES/3DES/MD5 to `jdk.security.legacyAlgorithms` security property, and to add the legacy algorithm constraint checking to `keytool` commands that are associated with secret key entries stored in the keystore. These `keytool` commands are -genseckey, -importpass, -list, and -importkeystore. As a result, `keytool` will be able to generate warnings when it detects that the secret key based algorithms and PBE based Mac and cipher algorithms are weak. Also removes the "This algorithm will be disabled in a future update.? from the existing warnings for the asymmetric keys/certificates. > Will also file a CSR. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Update per review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8300/files - new: https://git.openjdk.java.net/jdk/pull/8300/files/ac92a5f7..2fa72aa8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=04-05 Stats: 50 lines in 3 files changed: 35 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/8300.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8300/head:pull/8300 PR: https://git.openjdk.java.net/jdk/pull/8300 From hchao at openjdk.java.net Tue May 3 14:57:18 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 3 May 2022 14:57:18 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v5] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 15:08:17 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated spec in java.security > > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2196: > >> 2194: >> 2195: try { >> 2196: SecretKey secKey = (SecretKey) keyStore.getKey(alias, storePass); > > This means any secret key entries that are protected by a different password than `storePass` will throw an `UnrecoverableKeyException` and we will not be able to check the constraints. For PKCS12 this is not an issue since `storePass` and `keyPass` have to be the same. But for other keystores like JCEKS it might be a problem. However, I note this is not really a new issue as details about secret key entries other than the fact they exist as entries are not listed, presumably because we may not have the right password. > > I would recommend adding a comment explaining this. > > For a future RFE, it might be useful to enhance `keytool -list -alias` to have a `-keypass` option so that additional information for entries protected by a different password than `storePass` could be listed, such as their algorithm and key size. Comment added. > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 5039: > >> 5037: private void checkWeakConstraint(String label, String algName, >> 5038: ConstraintsParameters cp) { >> 5039: // Do not check disabled algorithms for symmetric key based algorithms for now > > If this method is intended only to be called for symmetric keys, you should change the type of `cp` to `SecretKeyConstraintsParameters`. Done. > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 5248: > >> 5246: private static class SecretKeyConstraintsParameters implements ConstraintsParameters { >> 5247: private final Key key; >> 5248: public SecretKeyConstraintsParameters(Key key) { > > This ctor could just be private. Done. > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 5259: > >> 5257: @Override >> 5258: public Set getKeys() { >> 5259: return null; > > You should return `Set.of(key)` here. This allows the constraints to also check the key size, if that is also restricted. I would suggest adding a test where `jdk.security.legacyAlgorithms` includes a constraint for "AES < 256" to see if `keytool` warns about it when generating an AES key of 128 bits. Fixed this method. Changed to check the key size (via passing checkKey=true). Added the suggested test to ensure that keytool will emit warning accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From weijun at openjdk.java.net Tue May 3 15:33:17 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 3 May 2022 15:33:17 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v6] In-Reply-To: <7DIMYcZwPWJV-oOzfiP70gLFxf5A6CM8DNouAsjcfP0=.3f623026-be79-4d6c-946e-366ea59d98c0@github.com> References: <7DIMYcZwPWJV-oOzfiP70gLFxf5A6CM8DNouAsjcfP0=.3f623026-be79-4d6c-946e-366ea59d98c0@github.com> Message-ID: On Tue, 3 May 2022 14:54:05 GMT, Hai-May Chao wrote: >> Please review these changes to add DES/3DES/MD5 to `jdk.security.legacyAlgorithms` security property, and to add the legacy algorithm constraint checking to `keytool` commands that are associated with secret key entries stored in the keystore. These `keytool` commands are -genseckey, -importpass, -list, and -importkeystore. As a result, `keytool` will be able to generate warnings when it detects that the secret key based algorithms and PBE based Mac and cipher algorithms are weak. Also removes the "This algorithm will be disabled in a future update.? from the existing warnings for the asymmetric keys/certificates. >> Will also file a CSR. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Update per review comments src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2530: > 2528: } > 2529: } > 2530: While `c == null` usually means this is a secret key entry, this is not guaranteed. How about we put the check on a secret key entry in its own `instanceof` check, then we can save a cast. Also, the `setEntry` is always called and it can be put outside any if/else block. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From xuelei at openjdk.java.net Tue May 3 15:37:13 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 3 May 2022 15:37:13 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v5] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 02:07:13 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the SunJSSE provider implementation. It is one of the efforts to clean up the use of finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > More note update CSR and release note requests are filed in JBS. May I have them reviewed? CSR: https://bugs.openjdk.java.net/browse/JDK-8286064 Release Note: https://bugs.openjdk.java.net/browse/JDK-8286065 ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From weijun at openjdk.java.net Tue May 3 16:08:20 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 3 May 2022 16:08:20 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v6] In-Reply-To: <7DIMYcZwPWJV-oOzfiP70gLFxf5A6CM8DNouAsjcfP0=.3f623026-be79-4d6c-946e-366ea59d98c0@github.com> References: <7DIMYcZwPWJV-oOzfiP70gLFxf5A6CM8DNouAsjcfP0=.3f623026-be79-4d6c-946e-366ea59d98c0@github.com> Message-ID: On Tue, 3 May 2022 14:54:05 GMT, Hai-May Chao wrote: >> Please review these changes to add DES/3DES/MD5 to `jdk.security.legacyAlgorithms` security property, and to add the legacy algorithm constraint checking to `keytool` commands that are associated with secret key entries stored in the keystore. These `keytool` commands are -genseckey, -importpass, -list, and -importkeystore. As a result, `keytool` will be able to generate warnings when it detects that the secret key based algorithms and PBE based Mac and cipher algorithms are weak. Also removes the "This algorithm will be disabled in a future update.? from the existing warnings for the asymmetric keys/certificates. >> Will also file a CSR. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Update per review comments I found a keytool bug. It prints out "PBEWithMD5AndDES" no matter what key algorithm is used in `keytool -importpass`. Together with the code change here, it means a warning will always be shown even if we choose a strong algorithm. https://bugs.openjdk.java.net/browse/JDK-8286069 filed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From weijun at openjdk.java.net Tue May 3 17:57:48 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 3 May 2022 17:57:48 GMT Subject: RFR: 8286069: keytool prints out wrong key algorithm for -importpass command Message-ID: <2MwFWuNl-aZXfxPjX5orhNyE5pGH1ceeN9qErOprQKo=.45d36953-a689-4330-bfe7-85fadbeb6833@github.com> Since `keytool -importpass` always uses `KeyFactory.getInstance("PBE")` to generate the secret key, and "PBE" is an alias of "PBEwithMD5andDES" inside the SunJCE security provider, its `getAlgorithm` is always `PBEwithMD5andDES`. This code change modifies it to "PBE". Note that I haven't chosen the `-keyalg` option value here because it is actually the algorithm used to protect the PBE secret key entry. It's a cipher algorithm instead of a key algorithm. ------------- Commit messages: - the fix Changes: https://git.openjdk.java.net/jdk/pull/8520/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8520&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286069 Stats: 109 lines in 2 files changed: 107 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8520.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8520/head:pull/8520 PR: https://git.openjdk.java.net/jdk/pull/8520 From mullan at openjdk.java.net Tue May 3 19:35:21 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 3 May 2022 19:35:21 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v14] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 02:20:23 GMT, Xue-Lei Andrew Fan wrote: >> Hi. Sorry, I should have brought this up earlier, but there is a jtreg test library to help with ensuring the GC runs, >> `test/lib/jdk/test/lib/util/ForceGC.java`. You might consider replacing the test code that runs/checks the GC with `ForceGC.await()`. > >> Hi. Sorry, I should have brought this up earlier, but there is a jtreg test library to help with ensuring the GC runs, `test/lib/jdk/test/lib/util/ForceGC.java`. You might consider replacing the test code that runs/checks the GC with `ForceGC.await()`. > > It looks like a graceful GC utility. There are also some other test cases I committed that do no use ForceGC. I filed a [new bug](https://bugs.openjdk.java.net/browse/JDK-8286045), and will make the update all together. Thank you. @XueleiFan Did you check to make sure someone ran Mach5 and the results were ok before integrating? ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From valeriep at openjdk.java.net Tue May 3 19:37:29 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 3 May 2022 19:37:29 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance Message-ID: This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. ------------- Commit messages: - Enhanced test with more decryption w/o parameters scenario. - 8002277: Refactor two PBE classes to simplify maintenance Changes: https://git.openjdk.java.net/jdk/pull/8521/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8002277 Stats: 542 lines in 3 files changed: 168 ins; 289 del; 85 mod Patch: https://git.openjdk.java.net/jdk/pull/8521.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8521/head:pull/8521 PR: https://git.openjdk.java.net/jdk/pull/8521 From mullan at openjdk.java.net Tue May 3 20:30:09 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 3 May 2022 20:30:09 GMT Subject: RFR: 8285380: Fix typos in security In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 16:10:54 GMT, Alan Bateman wrote: > > @AlanBateman So there is even more 3rd party code in there? :-( I tried to ignore fixes for all files that I could identify as 3rd party. It's actually a bit annoying that we have imported source code thrown around like this in the source tree, so there is no clear boundary between code we own and code we import from someone else... > > security-dev can say for sure but the only 3rd party code I see in this change is in the src/java.xml.crypto/share/classes/com/sun/org/apache tree (the package name gives a hint has it was it was re-packaged). The `src/java.xml.crypto/share/classes/org/jcp` tree is also 3rd party Apache code. However, I am ok with including the spelling fixes for the 3rd-party Apache code (this tree and the one Alan mentions above which you already reverted, but can put it back) with this PR. I am a Committer on the Apache Santuario project so I can push these spelling fixes (they should be non-controversial) to their code base and there won't be any conflicts when we merge up the JDK to the next Santuario release. ------------- PR: https://git.openjdk.java.net/jdk/pull/8340 From sean.mullan at oracle.com Tue May 3 21:14:17 2022 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 3 May 2022 17:14:17 -0400 Subject: javax.crypto.CryptoPolicyParser#isConsistent always returns 'true' In-Reply-To: References: Message-ID: <94f8a9af-03b5-7253-1096-1a144c5f75da@oracle.com> Hi Andrey, On 4/29/22 11:59 AM, Andrey Turbanov wrote: > Hello. > I found a suspicious code in CryptoPolicyParser method calls. > > Method 'isConsistent' is called only from a method > 'parsePermissionEntry'. It accepts the 'processedPermissions' > parameter from 'parsePermissionEntry'. > Method 'parsePermissionEntry' is called only from a method > 'parseGrantEntry'. It accepts the 'processedPermissions' parameter > from 'parseGrantEntry'. > Method 'parseGrantEntry' is called only from a method 'read' and > always with null value of parameter 'processedPermissions'. > > So, it seems in method 'isConsistent' value of parameter > 'processedPermissions' will always be 'null'. And the method will > always return true. > Is this the result of some refactoring? Or did I miss something? No, I don't think so. Good catch. It looks like a bug to me. Can you file a bug report? Thanks, Sean From hchao at openjdk.java.net Tue May 3 21:28:32 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 3 May 2022 21:28:32 GMT Subject: RFR: 8286069: keytool prints out wrong key algorithm for -importpass command In-Reply-To: <2MwFWuNl-aZXfxPjX5orhNyE5pGH1ceeN9qErOprQKo=.45d36953-a689-4330-bfe7-85fadbeb6833@github.com> References: <2MwFWuNl-aZXfxPjX5orhNyE5pGH1ceeN9qErOprQKo=.45d36953-a689-4330-bfe7-85fadbeb6833@github.com> Message-ID: On Tue, 3 May 2022 17:51:43 GMT, Weijun Wang wrote: > Since `keytool -importpass` always uses `KeyFactory.getInstance("PBE")` to generate the secret key, and "PBE" is an alias of "PBEwithMD5andDES" inside the SunJCE security provider, its `getAlgorithm` is always `PBEwithMD5andDES`. > > This code change modifies it to "PBE". > > Note that I haven't chosen the `-keyalg` option value here because it is actually the algorithm used to protect the PBE secret key entry. It's a cipher algorithm instead of a key algorithm. LGTM. ------------- Marked as reviewed by hchao (Committer). PR: https://git.openjdk.java.net/jdk/pull/8520 From duke at openjdk.java.net Tue May 3 22:52:49 2022 From: duke at openjdk.java.net (Mat Carter) Date: Tue, 3 May 2022 22:52:49 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v2] In-Reply-To: References: Message-ID: > On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. > > "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc > > No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode > > Tested on windows, passes tier1 and tier2 tests Mat Carter has updated the pull request incrementally with one additional commit since the last revision: replace string parameter with int and supporting constants ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8211/files - new: https://git.openjdk.java.net/jdk/pull/8211/files/86b5ced5..881bc600 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8211&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8211&range=00-01 Stats: 45 lines in 2 files changed: 21 ins; 7 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/8211.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8211/head:pull/8211 PR: https://git.openjdk.java.net/jdk/pull/8211 From xuelei at openjdk.java.net Tue May 3 23:07:42 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 3 May 2022 23:07:42 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v14] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 02:20:23 GMT, Xue-Lei Andrew Fan wrote: >> Hi. Sorry, I should have brought this up earlier, but there is a jtreg test library to help with ensuring the GC runs, >> `test/lib/jdk/test/lib/util/ForceGC.java`. You might consider replacing the test code that runs/checks the GC with `ForceGC.await()`. > >> Hi. Sorry, I should have brought this up earlier, but there is a jtreg test library to help with ensuring the GC runs, `test/lib/jdk/test/lib/util/ForceGC.java`. You might consider replacing the test code that runs/checks the GC with `ForceGC.await()`. > > It looks like a graceful GC utility. There are also some other test cases I committed that do no use ForceGC. I filed a [new bug](https://bugs.openjdk.java.net/browse/JDK-8286045), and will make the update all together. Thank you. > @XueleiFan Did you check to make sure someone ran Mach5 and the results were ok before integrating? If I'm right, Weijun made the test. Please let me know if there are mach5 testing failures. BTW, it would be nice if Mach5 testing could be supported to run in Github. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From xuelei at openjdk.java.net Tue May 3 23:14:29 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 3 May 2022 23:14:29 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v5] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 02:07:13 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the SunJSSE provider implementation. It is one of the efforts to clean up the use of finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > More note update Could someone in Oracle help to run the Mach5 testing for security and network components (or just tier1 and tier2), and let me know if this update cause any failures? ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From duke at openjdk.java.net Tue May 3 23:37:27 2022 From: duke at openjdk.java.net (Mat Carter) Date: Tue, 3 May 2022 23:37:27 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v2] In-Reply-To: References: <08kPGJRnG_Evtq3WCMH6nssW4Otk7AvaDHGWpTnBE1k=.e372fba4-2d0a-424d-975a-03335e0b1e34@github.com> Message-ID: <3YhRthCMOigGMV6gfyfGwOAx6Nmj-R7Am69UQEgEBYs=.6aef0b25-d6ad-4d51-a091-74a9554c283b@github.com> On Wed, 27 Apr 2022 21:47:15 GMT, Mat Carter wrote: >> Thanks for the feedback, I'm going to incorporate that into the PR > >> And also, is there a ReleaseString missing? > > Yes an error when I "patched" my repo, but based on the feedback there will no longer be a string to release :) Committed changes to use ints instead of strings ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Tue May 3 23:42:26 2022 From: duke at openjdk.java.net (Mat Carter) Date: Tue, 3 May 2022 23:42:26 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v2] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 22:52:49 GMT, Mat Carter wrote: >> On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. >> >> "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc >> >> No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode >> >> Tested on windows, passes tier1 and tier2 tests > > Mat Carter has updated the pull request incrementally with one additional commit since the last revision: > > replace string parameter with int and supporting constants I don't use this API much so I don't really have an opinion as a customer regarding the format of the strings used to identify the key stores. I'd be happy to review a separate PR but I think this falls outside the scope of this PR which specifically targets the inability to access local machine key stores (which a bug has been raised against). note: there's also a "Windows-PRNG" which isn't a key store but the native random number generator ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From wetmore at openjdk.java.net Wed May 4 00:52:31 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 4 May 2022 00:52:31 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v5] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 23:10:51 GMT, Xue-Lei Andrew Fan wrote: > Could someone in Oracle help to run the Mach5 testing for security and network components (or just tier1 and tier2), and let me know if this update causes any failures? Builds underway. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From wetmore at openjdk.java.net Wed May 4 01:00:28 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 4 May 2022 01:00:28 GMT Subject: RFR: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 19:04:26 GMT, zzambers wrote: > When testing compatibility of jdk TLS implementation with gnutls, I have found a problem. The problem is, that gnutls does not like use of user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() (used by socket.close() unless shutdownOutput was called explicitly) and considers it error. (For more details see: [1]) > > As I understand it, usage of user_canceled alert before close is workaround for an issue of not being able to cleanly initialize full (duplex) close of TLS-1.3 connection (other side is not required to immediately close the after receiving close_notify, unlike in earlier TLS versions). Some legacy programs could probably hang or something, expecting socket.close to perform immediate duplex close. Problem is this is not what user_canceled alert is intended for [2] and it is therefore undefined how the other side handles this. (JDK itself replies to close_notify preceded by user_canceled alert by immediately closing its output [3].) > > This fix disables this workaround when it is not necessary (connection is already half-closed by the other side). This way it fixes my case (gnutls client connected to jdk server initiates close) and it should be safe. (As removing workaround altogether could probably reintroduce issues for legacy apps... ) > > I also ran jdk_security tests locally, which passed for me. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473 > [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1 > [3] https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/java.base/share/classes/sun/security/ssl/Alert.java#L243 Thanks for the extra time to review this change. I'm still wondering if there is better pattern that doesn't use user_canceled, but that doesn't need to delay this fix from going in. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7664 From valeriep at openjdk.java.net Wed May 4 01:54:26 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 4 May 2022 01:54:26 GMT Subject: RFR: 8286069: keytool prints out wrong key algorithm for -importpass command In-Reply-To: <2MwFWuNl-aZXfxPjX5orhNyE5pGH1ceeN9qErOprQKo=.45d36953-a689-4330-bfe7-85fadbeb6833@github.com> References: <2MwFWuNl-aZXfxPjX5orhNyE5pGH1ceeN9qErOprQKo=.45d36953-a689-4330-bfe7-85fadbeb6833@github.com> Message-ID: <0jHQfCQET3FpMEOyPTlZksf28yWZGGYdcgRAAHXuaEI=.2ff32f20-1348-43e7-92ea-e27512b76750@github.com> On Tue, 3 May 2022 17:51:43 GMT, Weijun Wang wrote: > Since `keytool -importpass` always uses `KeyFactory.getInstance("PBE")` to generate the secret key, and "PBE" is an alias of "PBEwithMD5andDES" inside the SunJCE security provider, its `getAlgorithm` is always `PBEwithMD5andDES`. > > This code change modifies it to "PBE". > > Note that I haven't chosen the `-keyalg` option value here because it is actually the algorithm used to protect the PBE secret key entry. It's a cipher algorithm instead of a key algorithm. Marked as reviewed by valeriep (Reviewer). test/jdk/sun/security/pkcs12/ImportPassKeyAlg.java line 75: > 73: .shouldContain("Generated PBE secret key"); > 74: > 75: // The aid of a protected entry (at 110c010c01010c0 inside p12) is: nit: use "algorithm id" instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/8520 From weijun at openjdk.java.net Wed May 4 01:59:34 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 4 May 2022 01:59:34 GMT Subject: RFR: 8286069: keytool prints out wrong key algorithm for -importpass command In-Reply-To: <0jHQfCQET3FpMEOyPTlZksf28yWZGGYdcgRAAHXuaEI=.2ff32f20-1348-43e7-92ea-e27512b76750@github.com> References: <2MwFWuNl-aZXfxPjX5orhNyE5pGH1ceeN9qErOprQKo=.45d36953-a689-4330-bfe7-85fadbeb6833@github.com> <0jHQfCQET3FpMEOyPTlZksf28yWZGGYdcgRAAHXuaEI=.2ff32f20-1348-43e7-92ea-e27512b76750@github.com> Message-ID: On Wed, 4 May 2022 01:50:34 GMT, Valerie Peng wrote: >> Since `keytool -importpass` always uses `KeyFactory.getInstance("PBE")` to generate the secret key, and "PBE" is an alias of "PBEwithMD5andDES" inside the SunJCE security provider, its `getAlgorithm` is always `PBEwithMD5andDES`. >> >> This code change modifies it to "PBE". >> >> Note that I haven't chosen the `-keyalg` option value here because it is actually the algorithm used to protect the PBE secret key entry. It's a cipher algorithm instead of a key algorithm. > > test/jdk/sun/security/pkcs12/ImportPassKeyAlg.java line 75: > >> 73: .shouldContain("Generated PBE secret key"); >> 74: >> 75: // The aid of a protected entry (at 110c010c01010c0 inside p12) is: > > nit: use "algorithm id" instead. No problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/8520 From weijun at openjdk.java.net Wed May 4 03:01:22 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 4 May 2022 03:01:22 GMT Subject: RFR: 8286069: keytool prints out wrong key algorithm for -importpass command [v2] In-Reply-To: <2MwFWuNl-aZXfxPjX5orhNyE5pGH1ceeN9qErOprQKo=.45d36953-a689-4330-bfe7-85fadbeb6833@github.com> References: <2MwFWuNl-aZXfxPjX5orhNyE5pGH1ceeN9qErOprQKo=.45d36953-a689-4330-bfe7-85fadbeb6833@github.com> Message-ID: <6-mUjY_YRRoDw7D7YEtbZUHen_63D7xbMbTgh592CCs=.03e2c57d-daaa-4c3c-aa51-74c127ee33fe@github.com> > Since `keytool -importpass` always uses `KeyFactory.getInstance("PBE")` to generate the secret key, and "PBE" is an alias of "PBEwithMD5andDES" inside the SunJCE security provider, its `getAlgorithm` is always `PBEwithMD5andDES`. > > This code change modifies it to "PBE". > > Note that I haven't chosen the `-keyalg` option value here because it is actually the algorithm used to protect the PBE secret key entry. It's a cipher algorithm instead of a key algorithm. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: algorithm id ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8520/files - new: https://git.openjdk.java.net/jdk/pull/8520/files/e99bdc32..a45a500b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8520&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8520&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8520.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8520/head:pull/8520 PR: https://git.openjdk.java.net/jdk/pull/8520 From weijun at openjdk.java.net Wed May 4 03:01:23 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 4 May 2022 03:01:23 GMT Subject: Integrated: 8286069: keytool prints out wrong key algorithm for -importpass command In-Reply-To: <2MwFWuNl-aZXfxPjX5orhNyE5pGH1ceeN9qErOprQKo=.45d36953-a689-4330-bfe7-85fadbeb6833@github.com> References: <2MwFWuNl-aZXfxPjX5orhNyE5pGH1ceeN9qErOprQKo=.45d36953-a689-4330-bfe7-85fadbeb6833@github.com> Message-ID: On Tue, 3 May 2022 17:51:43 GMT, Weijun Wang wrote: > Since `keytool -importpass` always uses `KeyFactory.getInstance("PBE")` to generate the secret key, and "PBE" is an alias of "PBEwithMD5andDES" inside the SunJCE security provider, its `getAlgorithm` is always `PBEwithMD5andDES`. > > This code change modifies it to "PBE". > > Note that I haven't chosen the `-keyalg` option value here because it is actually the algorithm used to protect the PBE secret key entry. It's a cipher algorithm instead of a key algorithm. This pull request has now been integrated. Changeset: 075ce8a0 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/075ce8a0d0ab279049c81d5ce23fcee3711925e2 Stats: 109 lines in 2 files changed: 107 ins; 1 del; 1 mod 8286069: keytool prints out wrong key algorithm for -importpass command Reviewed-by: hchao, valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/8520 From weijun at openjdk.java.net Wed May 4 03:13:16 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 4 May 2022 03:13:16 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v2] In-Reply-To: References: Message-ID: <13zhEMVRR7gStjX_Ulny1Uk2-oS6OkvkDimbikbJ5pU=.0b43798d-9faf-47db-915c-19191372e34c@github.com> On Tue, 3 May 2022 22:52:49 GMT, Mat Carter wrote: >> On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. >> >> "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc >> >> No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode >> >> Tested on windows, passes tier1 and tier2 tests > > Mat Carter has updated the pull request incrementally with one additional commit since the last revision: > > replace string parameter with int and supporting constants src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKeyStore.java line 256: > 254: private final KeyStoreLocation storeLocation; > 255: > 256: CKeyStore(String storeName, KeyStoreLocation storeLocation) { Why not just an `int` here? The creation of a separate class `keyStoreLocation` seems not necessary. If you want code to be readable, just add `public static final int CURRENTUSER = 0`, etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From weijun at openjdk.java.net Wed May 4 03:22:37 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 4 May 2022 03:22:37 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v2] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 23:38:38 GMT, Mat Carter wrote: >> Mat Carter has updated the pull request incrementally with one additional commit since the last revision: >> >> replace string parameter with int and supporting constants > > I don't use this API much so I don't really have an opinion as a customer regarding the format of the strings used to identify the key stores. I'd be happy to review a separate PR but I think this falls outside the scope of this PR which specifically targets the inability to access local machine key stores (which a bug has been raised against). > > note: there's also a "Windows-PRNG" which isn't a key store but the native random number generator @macarte I've added my name as reviewer in the CSR. You can either propose it (if you expect some feedback from the CSR reviewers) or just finalize it (if you think the change is simple and obvious). ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From weijun at openjdk.java.net Wed May 4 03:22:38 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 4 May 2022 03:22:38 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v2] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 22:52:49 GMT, Mat Carter wrote: >> On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. >> >> "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc >> >> No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode >> >> Tested on windows, passes tier1 and tier2 tests > > Mat Carter has updated the pull request incrementally with one additional commit since the last revision: > > replace string parameter with int and supporting constants Also, please remove trailing spaces and create a new commit. Skara dislikes trailing spaces and TAB characters in source code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From xuelei at openjdk.java.net Wed May 4 04:20:15 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 4 May 2022 04:20:15 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: References: <7qogGHJ9jGPj6K6qqYVFnDfSUcSqJNB0jLifgJshstY=.be9bb286-dbce-446c-9684-dfa77ec2d0a4@github.com> <6YhRhen4o8Kg5pwhGxLF__535eB9ggQ57I6m6wu6oo4=.b4d0d99f-6d06-4ce7-8986-6470bae6a6f0@github.com> <7tFALuKc9QcTFYSzxokreBbeA3X5BpWIxqd mHoXjzNM=.c1ab3294-2edc-481e-a0e1-cf2e2731881a@github.com> Message-ID: On Mon, 2 May 2022 21:42:28 GMT, Valerie Peng wrote: >>> What kind of additional sentence do you have in mind? >> >> It may be fine to put it into the state for 'null" returned value. For example: >> >> >> The returned parameters may be the same that were used to initialize >> this signature, or may contain additional default or random parameter >> values used by the underlying signature implementation, or null if the >> underlying signature implementation does not support returning the >> parameters as {@code AlgorithmParameters}. >> >> >> >> The null return conditional in the following sentence may be able to combine together. >> >> >> The returned parameters may be the same that were used to initialize >> this signature, or may contain additional default or random parameter >> values used by the underlying signature implementation. {@code null} >> may be returned if the underlying signature implementation does not >> support returning the parameters as {@code AlgorithmParameters}, or > > How about the case when no parameters are given? Say A is the user-supplied values, B is the provider specific default or random values, your suggestion has A, A+B, and null. Isn't the sentence about B needed (no A and provider can generate the parameters)? I think this sentence covers case B, "... or may contain additional default or random parameter values used by the underlying signature implementation." ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From hchao at openjdk.java.net Wed May 4 05:49:20 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 4 May 2022 05:49:20 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v7] In-Reply-To: References: Message-ID: > Please review these changes to add DES/3DES/MD5 to `jdk.security.legacyAlgorithms` security property, and to add the legacy algorithm constraint checking to `keytool` commands that are associated with secret key entries stored in the keystore. These `keytool` commands are -genseckey, -importpass, -list, and -importkeystore. As a result, `keytool` will be able to generate warnings when it detects that the secret key based algorithms and PBE based Mac and cipher algorithms are weak. Also removes the "This algorithm will be disabled in a future update.? from the existing warnings for the asymmetric keys/certificates. > Will also file a CSR. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Revert changes to StorePasswords.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8300/files - new: https://git.openjdk.java.net/jdk/pull/8300/files/2fa72aa8..19afc42e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=05-06 Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8300.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8300/head:pull/8300 PR: https://git.openjdk.java.net/jdk/pull/8300 From hchao at openjdk.java.net Wed May 4 05:55:08 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 4 May 2022 05:55:08 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v8] In-Reply-To: References: Message-ID: > Please review these changes to add DES/3DES/MD5 to `jdk.security.legacyAlgorithms` security property, and to add the legacy algorithm constraint checking to `keytool` commands that are associated with secret key entries stored in the keystore. These `keytool` commands are -genseckey, -importpass, -list, and -importkeystore. As a result, `keytool` will be able to generate warnings when it detects that the secret key based algorithms and PBE based Mac and cipher algorithms are weak. Also removes the "This algorithm will be disabled in a future update.? from the existing warnings for the asymmetric keys/certificates. > Will also file a CSR. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Skip alg constraint check for PBE secret key entry ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8300/files - new: https://git.openjdk.java.net/jdk/pull/8300/files/19afc42e..664f116a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=06-07 Stats: 30 lines in 2 files changed: 13 ins; 13 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8300.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8300/head:pull/8300 PR: https://git.openjdk.java.net/jdk/pull/8300 From wetmore at openjdk.java.net Wed May 4 16:16:30 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 4 May 2022 16:16:30 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v5] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 02:07:13 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the SunJSSE provider implementation. It is one of the efforts to clean up the use of finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > More note update tier1/tier2 passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From wetmore at openjdk.java.net Wed May 4 16:20:33 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 4 May 2022 16:20:33 GMT Subject: RFR: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 19:04:26 GMT, zzambers wrote: > When testing compatibility of jdk TLS implementation with gnutls, I have found a problem. The problem is, that gnutls does not like use of user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() (used by socket.close() unless shutdownOutput was called explicitly) and considers it error. (For more details see: [1]) > > As I understand it, usage of user_canceled alert before close is workaround for an issue of not being able to cleanly initialize full (duplex) close of TLS-1.3 connection (other side is not required to immediately close the after receiving close_notify, unlike in earlier TLS versions). Some legacy programs could probably hang or something, expecting socket.close to perform immediate duplex close. Problem is this is not what user_canceled alert is intended for [2] and it is therefore undefined how the other side handles this. (JDK itself replies to close_notify preceded by user_canceled alert by immediately closing its output [3].) > > This fix disables this workaround when it is not necessary (connection is already half-closed by the other side). This way it fixes my case (gnutls client connected to jdk server initiates close) and it should be safe. (As removing workaround altogether could probably reintroduce issues for legacy apps... ) > > I also ran jdk_security tests locally, which passed for me. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473 > [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1 > [3] https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/java.base/share/classes/sun/security/ssl/Alert.java#L243 tier1/tier2 tests pass. Did not try infra or JCK yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/7664 From mullan at openjdk.java.net Wed May 4 16:36:34 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 4 May 2022 16:36:34 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v8] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 05:55:08 GMT, Hai-May Chao wrote: >> Please review these changes to add DES/3DES/MD5 to `jdk.security.legacyAlgorithms` security property, and to add the legacy algorithm constraint checking to `keytool` commands that are associated with secret key entries stored in the keystore. These `keytool` commands are -genseckey, -importpass, -list, and -importkeystore. As a result, `keytool` will be able to generate warnings when it detects that the secret key based algorithms and PBE based Mac and cipher algorithms are weak. Also removes the "This algorithm will be disabled in a future update.? from the existing warnings for the asymmetric keys/certificates. >> Will also file a CSR. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Skip alg constraint check for PBE secret key entry Changes requested by mullan (Reviewer). src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2208: > 2206: * is not really a new issue as details about secret key entries > 2207: * other than the fact they exist as entries are not listed , > 2208: * presumably because we may not have the right password. I would leave out this last sentence as that was more of an editorial comment by me. In the first sentence, I would add at the end "... and we will not be able to check the constraints because we do not have the keyPass for this operation." src/java.base/share/classes/sun/security/tools/keytool/Main.java line 5286: > 5284: @Override > 5285: public Set getKeys() { > 5286: return (key == null) ? Set.of() : Set.of(key); key should never be null, so you don't need to check for this. test/jdk/sun/security/tools/keytool/WeakSecretKeyTest.java line 92: > 90: .shouldContain("Warning") > 91: .shouldMatch("The generated secret key uses a 128-bit AES key.*considered a security risk") > 92: .shouldHaveExitValue(0); Nice - thanks for adding this test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From duke at openjdk.java.net Wed May 4 16:54:37 2022 From: duke at openjdk.java.net (Mat Carter) Date: Wed, 4 May 2022 16:54:37 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v2] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 03:18:43 GMT, Weijun Wang wrote: >> Mat Carter has updated the pull request incrementally with one additional commit since the last revision: >> >> replace string parameter with int and supporting constants > > Also, please remove trailing spaces and create a new commit. Skara dislikes trailing spaces and TAB characters in source code. @wangweij - I believe the change to be simple enough I'll go ahead and finalize it. However, I've proposed updates to the documentation, how are these actioned, i.e. what steps are required of me? ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From weijun at openjdk.java.net Wed May 4 16:59:30 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 4 May 2022 16:59:30 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v2] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 03:18:43 GMT, Weijun Wang wrote: >> Mat Carter has updated the pull request incrementally with one additional commit since the last revision: >> >> replace string parameter with int and supporting constants > > Also, please remove trailing spaces and create a new commit. Skara dislikes trailing spaces and TAB characters in source code. > @wangweij - I believe the change to be simple enough I'll go ahead and finalize it. However, I've proposed updates to the documentation, how are these actioned, i.e. what steps are required of me? I filed a doc task at https://bugs.openjdk.java.net/browse/JDK-8286141. It will be picked up by the doc team. We will also need to write a release note. If you have any recommended text, you can write here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From xuelei at openjdk.java.net Wed May 4 17:34:19 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 4 May 2022 17:34:19 GMT Subject: RFR: 8285516: clearPassword should be called in a finally try block [v2] In-Reply-To: <22ryS4pQVqt8m-mifHIFZ8Xc-lzy6__LHaTt_nc14Qw=.61cd0e95-459c-4748-8fac-90e1e82e4ff2@github.com> References: <22ryS4pQVqt8m-mifHIFZ8Xc-lzy6__LHaTt_nc14Qw=.61cd0e95-459c-4748-8fac-90e1e82e4ff2@github.com> Message-ID: On Mon, 25 Apr 2022 14:23:17 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> Could I have the simple update reviewed? >> >> In the PKCS12 key store implementation, the PBEKeySpec.clearPassword() should be called in a finally try block. Otherwise, the password cleanup could be interrupted by exceptions. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > an extra whitespace added Could someone in Oracle help to run Mach5 testing (tier1 and tier2), just in case unexpected failure happens? ------------- PR: https://git.openjdk.java.net/jdk/pull/8377 From weijun at openjdk.java.net Wed May 4 17:38:22 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 4 May 2022 17:38:22 GMT Subject: RFR: 8285516: clearPassword should be called in a finally try block [v2] In-Reply-To: <22ryS4pQVqt8m-mifHIFZ8Xc-lzy6__LHaTt_nc14Qw=.61cd0e95-459c-4748-8fac-90e1e82e4ff2@github.com> References: <22ryS4pQVqt8m-mifHIFZ8Xc-lzy6__LHaTt_nc14Qw=.61cd0e95-459c-4748-8fac-90e1e82e4ff2@github.com> Message-ID: On Mon, 25 Apr 2022 14:23:17 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> Could I have the simple update reviewed? >> >> In the PKCS12 key store implementation, the PBEKeySpec.clearPassword() should be called in a finally try block. Otherwise, the password cleanup could be interrupted by exceptions. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > an extra whitespace added Please merge your PR with master and I can run it for you. ------------- PR: https://git.openjdk.java.net/jdk/pull/8377 From wetmore at openjdk.java.net Wed May 4 19:25:25 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 4 May 2022 19:25:25 GMT Subject: RFR: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary In-Reply-To: References: Message-ID: <8oFhFTQIZRCxLAQ4wFEgGyjl0zO2F0IhAh2m5m1O2Ho=.b0eb3018-f8f8-44f4-9661-26daae7b1d56@github.com> On Wed, 2 Mar 2022 19:04:26 GMT, zzambers wrote: > When testing compatibility of jdk TLS implementation with gnutls, I have found a problem. The problem is, that gnutls does not like use of user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() (used by socket.close() unless shutdownOutput was called explicitly) and considers it error. (For more details see: [1]) > > As I understand it, usage of user_canceled alert before close is workaround for an issue of not being able to cleanly initialize full (duplex) close of TLS-1.3 connection (other side is not required to immediately close the after receiving close_notify, unlike in earlier TLS versions). Some legacy programs could probably hang or something, expecting socket.close to perform immediate duplex close. Problem is this is not what user_canceled alert is intended for [2] and it is therefore undefined how the other side handles this. (JDK itself replies to close_notify preceded by user_canceled alert by immediately closing its output [3].) > > This fix disables this workaround when it is not necessary (connection is already half-closed by the other side). This way it fixes my case (gnutls client connected to jdk server initiates close) and it should be safe. (As removing workaround altogether could probably reintroduce issues for legacy apps... ) > > I also ran jdk_security tests locally, which passed for me. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473 > [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1 > [3] https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/java.base/share/classes/sun/security/ssl/Alert.java#L243 Infra + JCK passed. Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7664 From wetmore at openjdk.java.net Wed May 4 19:25:28 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 4 May 2022 19:25:28 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v5] In-Reply-To: References: Message-ID: <7Ovn5bywyh0dw0esfEUtPKdRf4ui5jsVVcsT_3BOZ2c=.f0586d08-edbb-44bc-912c-73d778768b15@github.com> On Tue, 3 May 2022 02:07:13 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the SunJSSE provider implementation. It is one of the efforts to clean up the use of finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > More note update linux-x64 Infra + JCK passed. Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From hchao at openjdk.java.net Wed May 4 19:57:30 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 4 May 2022 19:57:30 GMT Subject: RFR: 8285516: clearPassword should be called in a finally try block [v2] In-Reply-To: <22ryS4pQVqt8m-mifHIFZ8Xc-lzy6__LHaTt_nc14Qw=.61cd0e95-459c-4748-8fac-90e1e82e4ff2@github.com> References: <22ryS4pQVqt8m-mifHIFZ8Xc-lzy6__LHaTt_nc14Qw=.61cd0e95-459c-4748-8fac-90e1e82e4ff2@github.com> Message-ID: On Mon, 25 Apr 2022 14:23:17 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> Could I have the simple update reviewed? >> >> In the PKCS12 key store implementation, the PBEKeySpec.clearPassword() should be called in a finally try block. Otherwise, the password cleanup could be interrupted by exceptions. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > an extra whitespace added Marked as reviewed by hchao (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8377 From hchao at openjdk.java.net Wed May 4 20:16:12 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 4 May 2022 20:16:12 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v9] In-Reply-To: References: Message-ID: > Please review these changes to add DES/3DES/MD5 to `jdk.security.legacyAlgorithms` security property, and to add the legacy algorithm constraint checking to `keytool` commands that are associated with secret key entries stored in the keystore. These `keytool` commands are -genseckey, -importpass, -list, and -importkeystore. As a result, `keytool` will be able to generate warnings when it detects that the secret key based algorithms and PBE based Mac and cipher algorithms are weak. Also removes the "This algorithm will be disabled in a future update.? from the existing warnings for the asymmetric keys/certificates. > Will also file a CSR. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Updated comment and getKeys() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8300/files - new: https://git.openjdk.java.net/jdk/pull/8300/files/664f116a..a77ed4f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=07-08 Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8300.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8300/head:pull/8300 PR: https://git.openjdk.java.net/jdk/pull/8300 From hchao at openjdk.java.net Wed May 4 20:16:16 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 4 May 2022 20:16:16 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v8] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:29:09 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Skip alg constraint check for PBE secret key entry > > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2208: > >> 2206: * is not really a new issue as details about secret key entries >> 2207: * other than the fact they exist as entries are not listed , >> 2208: * presumably because we may not have the right password. > > I would leave out this last sentence as that was more of an editorial comment by me. In the first sentence, I would add at the end "... and we will not be able to check the constraints because we do not have the keyPass for this operation." Comment updated. > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 5286: > >> 5284: @Override >> 5285: public Set getKeys() { >> 5286: return (key == null) ? Set.of() : Set.of(key); > > key should never be null, so you don't need to check for this. Removed the extra check. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From hchao at openjdk.java.net Wed May 4 20:20:53 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 4 May 2022 20:20:53 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v5] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 14:54:21 GMT, Hai-May Chao wrote: >> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2196: >> >>> 2194: >>> 2195: try { >>> 2196: SecretKey secKey = (SecretKey) keyStore.getKey(alias, storePass); >> >> This means any secret key entries that are protected by a different password than `storePass` will throw an `UnrecoverableKeyException` and we will not be able to check the constraints. For PKCS12 this is not an issue since `storePass` and `keyPass` have to be the same. But for other keystores like JCEKS it might be a problem. However, I note this is not really a new issue as details about secret key entries other than the fact they exist as entries are not listed, presumably because we may not have the right password. >> >> I would recommend adding a comment explaining this. >> >> For a future RFE, it might be useful to enhance `keytool -list -alias` to have a `-keypass` option so that additional information for entries protected by a different password than `storePass` could be listed, such as their algorithm and key size. > > Comment added. Filed RFE JDK-8286031 as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From mullan at openjdk.java.net Wed May 4 20:24:24 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 4 May 2022 20:24:24 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v9] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 20:16:12 GMT, Hai-May Chao wrote: >> Please review these changes to add DES/3DES/MD5 to `jdk.security.legacyAlgorithms` security property, and to add the legacy algorithm constraint checking to `keytool` commands that are associated with secret key entries stored in the keystore. These `keytool` commands are -genseckey, -importpass, -list, and -importkeystore. As a result, `keytool` will be able to generate warnings when it detects that the secret key based algorithms and PBE based Mac and cipher algorithms are weak. Also removes the "This algorithm will be disabled in a future update.? from the existing warnings for the asymmetric keys/certificates. >> Will also file a CSR. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Updated comment and getKeys() I think there is still one outstanding comment from Max, but the fix looks good for me now. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8300 From duke at openjdk.java.net Wed May 4 20:32:30 2022 From: duke at openjdk.java.net (Mat Carter) Date: Wed, 4 May 2022 20:32:30 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v3] In-Reply-To: References: Message-ID: > On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. > > "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc > > No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode > > Tested on windows, passes tier1 and tier2 tests Mat Carter has updated the pull request incrementally with one additional commit since the last revision: Removed whitespace and simply passing ints between java and C++ ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8211/files - new: https://git.openjdk.java.net/jdk/pull/8211/files/881bc600..5b3d4115 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8211&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8211&range=01-02 Stats: 24 lines in 1 file changed: 0 ins; 13 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8211.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8211/head:pull/8211 PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Wed May 4 20:32:33 2022 From: duke at openjdk.java.net (Mat Carter) Date: Wed, 4 May 2022 20:32:33 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v2] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 22:52:49 GMT, Mat Carter wrote: >> On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. >> >> "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc >> >> No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode >> >> Tested on windows, passes tier1 and tier2 tests > > Mat Carter has updated the pull request incrementally with one additional commit since the last revision: > > replace string parameter with int and supporting constants Found an issue with my editor where whitespace was not being rendered :( - will check the diff in future ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Wed May 4 20:32:35 2022 From: duke at openjdk.java.net (Mat Carter) Date: Wed, 4 May 2022 20:32:35 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v2] In-Reply-To: <13zhEMVRR7gStjX_Ulny1Uk2-oS6OkvkDimbikbJ5pU=.0b43798d-9faf-47db-915c-19191372e34c@github.com> References: <13zhEMVRR7gStjX_Ulny1Uk2-oS6OkvkDimbikbJ5pU=.0b43798d-9faf-47db-915c-19191372e34c@github.com> Message-ID: On Wed, 4 May 2022 03:10:10 GMT, Weijun Wang wrote: >> Mat Carter has updated the pull request incrementally with one additional commit since the last revision: >> >> replace string parameter with int and supporting constants > > src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKeyStore.java line 256: > >> 254: private final KeyStoreLocation storeLocation; >> 255: >> 256: CKeyStore(String storeName, KeyStoreLocation storeLocation) { > > Why not just an `int` here? The creation of a separate class `keyStoreLocation` seems not necessary. If you want code to be readable, just add `public static final int CURRENTUSER = 0`, etc. I was using type safety to remove the chance of non-expected values being passed to the C function. Implemented your recommendation as its a simple contract between two files ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From weijun at openjdk.java.net Wed May 4 20:32:50 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 4 May 2022 20:32:50 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v9] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 20:16:12 GMT, Hai-May Chao wrote: >> Please review these changes to add DES/3DES/MD5 to `jdk.security.legacyAlgorithms` security property, and to add the legacy algorithm constraint checking to `keytool` commands that are associated with secret key entries stored in the keystore. These `keytool` commands are -genseckey, -importpass, -list, and -importkeystore. As a result, `keytool` will be able to generate warnings when it detects that the secret key based algorithms and PBE based Mac and cipher algorithms are weak. Also removes the "This algorithm will be disabled in a future update.? from the existing warnings for the asymmetric keys/certificates. >> Will also file a CSR. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Updated comment and getKeys() Marked as reviewed by weijun (Reviewer). Most of my comments are all resolved. The cast to `SecretKey` one is not a real issue and I'm OK with it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From hchao at openjdk.java.net Wed May 4 20:35:31 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 4 May 2022 20:35:31 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v9] In-Reply-To: <--RreEtE_-XirwMoMwnFEDV1XXioQ2az1WnJvIlxNvg=.bb9fe8a4-1ff1-47d1-b131-550baa34842c@github.com> References: <--RreEtE_-XirwMoMwnFEDV1XXioQ2az1WnJvIlxNvg=.bb9fe8a4-1ff1-47d1-b131-550baa34842c@github.com> Message-ID: On Thu, 28 Apr 2022 13:47:05 GMT, Sean Mullan wrote: >> Changes requested by mullan (Reviewer). > >> @seanjmullan Since we use symmetric keys to encrypt entries and add integrity check, should this enhancement cover them as well? For example, if a PKCS12 keystore is created with `-J-Dkeystore.pkcs12.legacy=true`, should the algorithms used be warned? BTW, in legacy mode, we use PBEWithSHA1AndRC2_40 when encrypting keys. Should the security property include "RC2" as well? >> >> Not sure if it's doable, because those are PKCS12-specific codes. `keytool` is not able to see them. > > Right, I think this would require knowledge of what keystore type is being used and parsing the PKCS12 encoded bytes which seems beyond the scope of this RFE. Also, those algorithms are disabled by default, so in some sense the user is making a decision to use them by enabling the system property and therefore are taking the risk themselves. @seanjmullan @wangweij Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From hchao at openjdk.java.net Wed May 4 20:37:53 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 4 May 2022 20:37:53 GMT Subject: Integrated: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 16:08:28 GMT, Hai-May Chao wrote: > Please review these changes to add DES/3DES/MD5 to `jdk.security.legacyAlgorithms` security property, and to add the legacy algorithm constraint checking to `keytool` commands that are associated with secret key entries stored in the keystore. These `keytool` commands are -genseckey, -importpass, -list, and -importkeystore. As a result, `keytool` will be able to generate warnings when it detects that the secret key based algorithms and PBE based Mac and cipher algorithms are weak. Also removes the "This algorithm will be disabled in a future update.? from the existing warnings for the asymmetric keys/certificates. > Will also file a CSR. This pull request has now been integrated. Changeset: 09e6ee96 Author: Hai-May Chao URL: https://git.openjdk.java.net/jdk/commit/09e6ee96bd448838491e5e8634a898e248f1c44e Stats: 362 lines in 6 files changed: 277 ins; 2 del; 83 mod 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms Reviewed-by: mullan, weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From valeriep at openjdk.java.net Thu May 5 00:06:19 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 5 May 2022 00:06:19 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: References: <77iS1t15rXz0DnqsXKuRifJPbAYGLlJOTnqRt1cdKcE=.11167daf-c2ba-48d3-b14a-26a0914c554a@github.com> Message-ID: On Tue, 3 May 2022 00:17:11 GMT, Weijun Wang wrote: >> An example is RSASSA-PSS, i.e. it requires the caller to explicitly state which message digest to use, etc. > > You listed 2 cases when null is returned: 1) not supplied. 2) cannot generate. My understanding is that the RSASSA-PSS case is 1), and the EdDSA case is 2). This is why I suggested an "or" relation between them. For EdDSA, it's really the case of the signature impl cannot convert the supplied parameter values to "AlgorithmParameters" object. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From xuelei at openjdk.java.net Thu May 5 06:02:14 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 5 May 2022 06:02:14 GMT Subject: RFR: 8285516: clearPassword should be called in a finally try block [v3] In-Reply-To: References: Message-ID: > Hi, > > Could I have the simple update reviewed? > > In the PKCS12 key store implementation, the PBEKeySpec.clearPassword() should be called in a finally try block. Otherwise, the password cleanup could be interrupted by exceptions. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge - an extra whitespace added - 8285516: clearPassword should be called in a finally try block ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8377/files - new: https://git.openjdk.java.net/jdk/pull/8377/files/99079d30..1df828df Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8377&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8377&range=01-02 Stats: 32346 lines in 832 files changed: 22171 ins; 4511 del; 5664 mod Patch: https://git.openjdk.java.net/jdk/pull/8377.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8377/head:pull/8377 PR: https://git.openjdk.java.net/jdk/pull/8377 From xuelei at openjdk.java.net Thu May 5 06:02:14 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 5 May 2022 06:02:14 GMT Subject: RFR: 8285516: clearPassword should be called in a finally try block [v2] In-Reply-To: References: <22ryS4pQVqt8m-mifHIFZ8Xc-lzy6__LHaTt_nc14Qw=.61cd0e95-459c-4748-8fac-90e1e82e4ff2@github.com> Message-ID: On Wed, 4 May 2022 17:35:13 GMT, Weijun Wang wrote: > Please merge your PR with master and I can run it for you. Merged. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/8377 From duke at openjdk.java.net Thu May 5 10:00:19 2022 From: duke at openjdk.java.net (zzambers) Date: Thu, 5 May 2022 10:00:19 GMT Subject: RFR: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary In-Reply-To: <8oFhFTQIZRCxLAQ4wFEgGyjl0zO2F0IhAh2m5m1O2Ho=.b0eb3018-f8f8-44f4-9661-26daae7b1d56@github.com> References: <8oFhFTQIZRCxLAQ4wFEgGyjl0zO2F0IhAh2m5m1O2Ho=.b0eb3018-f8f8-44f4-9661-26daae7b1d56@github.com> Message-ID: On Wed, 4 May 2022 19:22:05 GMT, Bradford Wetmore wrote: >> When testing compatibility of jdk TLS implementation with gnutls, I have found a problem. The problem is, that gnutls does not like use of user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() (used by socket.close() unless shutdownOutput was called explicitly) and considers it error. (For more details see: [1]) >> >> As I understand it, usage of user_canceled alert before close is workaround for an issue of not being able to cleanly initialize full (duplex) close of TLS-1.3 connection (other side is not required to immediately close the after receiving close_notify, unlike in earlier TLS versions). Some legacy programs could probably hang or something, expecting socket.close to perform immediate duplex close. Problem is this is not what user_canceled alert is intended for [2] and it is therefore undefined how the other side handles this. (JDK itself replies to close_notify preceded by user_canceled alert by immediately closing its output [3].) >> >> This fix disables this workaround when it is not necessary (connection is already half-closed by the other side). This way it fixes my case (gnutls client connected to jdk server initiates close) and it should be safe. (As removing workaround altogether could probably reintroduce issues for legacy apps... ) >> >> I also ran jdk_security tests locally, which passed for me. >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473 >> [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1 >> [3] https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/java.base/share/classes/sun/security/ssl/Alert.java#L243 > > Infra + JCK passed. Looks good. @bradfordwetmore Thank you ------------- PR: https://git.openjdk.java.net/jdk/pull/7664 From duke at openjdk.java.net Thu May 5 12:17:27 2022 From: duke at openjdk.java.net (zzambers) Date: Thu, 5 May 2022 12:17:27 GMT Subject: Integrated: 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 19:04:26 GMT, zzambers wrote: > When testing compatibility of jdk TLS implementation with gnutls, I have found a problem. The problem is, that gnutls does not like use of user_canceled alert when closing TLS-1.3 connection from duplexCloseOutput() (used by socket.close() unless shutdownOutput was called explicitly) and considers it error. (For more details see: [1]) > > As I understand it, usage of user_canceled alert before close is workaround for an issue of not being able to cleanly initialize full (duplex) close of TLS-1.3 connection (other side is not required to immediately close the after receiving close_notify, unlike in earlier TLS versions). Some legacy programs could probably hang or something, expecting socket.close to perform immediate duplex close. Problem is this is not what user_canceled alert is intended for [2] and it is therefore undefined how the other side handles this. (JDK itself replies to close_notify preceded by user_canceled alert by immediately closing its output [3].) > > This fix disables this workaround when it is not necessary (connection is already half-closed by the other side). This way it fixes my case (gnutls client connected to jdk server initiates close) and it should be safe. (As removing workaround altogether could probably reintroduce issues for legacy apps... ) > > I also ran jdk_security tests locally, which passed for me. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1918473 > [2] https://datatracker.ietf.org/doc/html/rfc8446#section-6.1 > [3] https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/java.base/share/classes/sun/security/ssl/Alert.java#L243 This pull request has now been integrated. Changeset: 7e88ff8a Author: Zdenek Zambersky Committer: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/7e88ff8a82cefa2a20acc9d5a9e42858d60fe3a3 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8282600: SSLSocketImpl should not use user_canceled workaround when not necessary Reviewed-by: xuelei, wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/7664 From weijun at openjdk.java.net Thu May 5 14:08:23 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 5 May 2022 14:08:23 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v3] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 20:32:30 GMT, Mat Carter wrote: >> On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. >> >> "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc >> >> No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode >> >> Tested on windows, passes tier1 and tier2 tests > > Mat Carter has updated the pull request incrementally with one additional commit since the last revision: > > Removed whitespace and simply passing ints between java and C++ src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKeyStore.java line 860: > 858: > 859: /** > 860: * Load keys and/or certificates from keystore into Collection. Take this chance to modify `Load` to `Loads`. src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKeyStore.java line 866: > 864: */ > 865: private native void loadKeysOrCertificateChains(String name, > 866: int location) throws KeyStoreException; We usually indent 8 spaces in a continuation line. ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From weijun at openjdk.java.net Thu May 5 14:26:27 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 5 May 2022 14:26:27 GMT Subject: RFR: 8285516: clearPassword should be called in a finally try block [v3] In-Reply-To: References: Message-ID: <9vy9MZOQP4AI9q6J7sFlnJ43rJqitMUv26g7wLlalFk=.d529a71e-95e9-4915-ab9b-f40f8de69463@github.com> On Thu, 5 May 2022 06:02:14 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> Could I have the simple update reviewed? >> >> In the PKCS12 key store implementation, the PBEKeySpec.clearPassword() should be called in a finally try block. Otherwise, the password cleanup could be interrupted by exceptions. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge > - an extra whitespace added > - 8285516: clearPassword should be called in a finally try block Running now... ------------- PR: https://git.openjdk.java.net/jdk/pull/8377 From weijun at openjdk.java.net Thu May 5 14:35:18 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 5 May 2022 14:35:18 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v3] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 20:32:30 GMT, Mat Carter wrote: >> On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. >> >> "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc >> >> No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode >> >> Tested on windows, passes tier1 and tier2 tests > > Mat Carter has updated the pull request incrementally with one additional commit since the last revision: > > Removed whitespace and simply passing ints between java and C++ I'd like to contribute a test. Please modify it as much as you like. You can put it inside `test/jdk/sun/security/mscapi/`. /* * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ import jdk.test.lib.Asserts; import jdk.test.lib.SecurityTools; import java.security.KeyStore; import java.util.Collections; import java.util.List; import java.util.Locale; /* * @test * @bug 6782021 * @requires os.family == "windows" * @library /test/lib * @summary More keystore types */ public class AllTypes { public static void main(String[] args) throws Exception { var nm = test("windows-my"); var nr = test("windows-root"); var nmu = test("windows-my-currentuser"); var nru = test("windows-root-currentuser"); var nmm = test("windows-my-localmachine"); var nrm = test("windows-root-localmachine"); Asserts.assertEQ(nm, nmu); Asserts.assertEQ(nr, nru); } private static List test(String type) throws Exception { var stdType = "Windows-" + type.substring(8).toUpperCase(Locale.ROOT); SecurityTools.keytool("-storetype " + type + " -list") .shouldHaveExitValue(0) .shouldContain("Keystore provider: SunMSCAPI") .shouldContain("Keystore type: " + stdType); KeyStore ks = KeyStore.getInstance(type); ks.load(null, null); var content = Collections.list(ks.aliases()); Collections.sort(content); return content; } } ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Thu May 5 16:39:18 2022 From: duke at openjdk.java.net (Mat Carter) Date: Thu, 5 May 2022 16:39:18 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v3] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 14:32:14 GMT, Weijun Wang wrote: >> Mat Carter has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed whitespace and simply passing ints between java and C++ > > I'd like to contribute a test. Please modify it as much as you like. You can put it inside `test/jdk/sun/security/mscapi/`. > > /* > * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License version 2 only, as > * published by the Free Software Foundation. > * > * This code is distributed in the hope that it will be useful, but WITHOUT > * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > * version 2 for more details (a copy is included in the LICENSE file that > * accompanied this code). > * > * You should have received a copy of the GNU General Public License version > * 2 along with this work; if not, write to the Free Software Foundation, > * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > * > * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > * or visit www.oracle.com if you need additional information or have any > * questions. > */ > > import jdk.test.lib.Asserts; > import jdk.test.lib.SecurityTools; > > import java.security.KeyStore; > import java.util.Collections; > import java.util.List; > import java.util.Locale; > > /* > * @test > * @bug 6782021 > * @requires os.family == "windows" > * @library /test/lib > * @summary More keystore types > */ > public class AllTypes { > public static void main(String[] args) throws Exception { > var nm = test("windows-my"); > var nr = test("windows-root"); > var nmu = test("windows-my-currentuser"); > var nru = test("windows-root-currentuser"); > var nmm = test("windows-my-localmachine"); > var nrm = test("windows-root-localmachine"); > Asserts.assertEQ(nm, nmu); > Asserts.assertEQ(nr, nru); > } > > private static List test(String type) throws Exception { > var stdType = "Windows-" + type.substring(8).toUpperCase(Locale.ROOT); > SecurityTools.keytool("-storetype " + type + " -list") > .shouldHaveExitValue(0) > .shouldContain("Keystore provider: SunMSCAPI") > .shouldContain("Keystore type: " + stdType); > KeyStore ks = KeyStore.getInstance(type); > ks.load(null, null); > var content = Collections.list(ks.aliases()); > Collections.sort(content); > return content; > } > } @wangweij - regarding the two tests for localmachine, these will throw a KeyStore exception "Access denied" if the test is not run as admin, is there anyway in the test to make that a requirement? If so we could split into two tests, one in admin that does all and one in non-admin that does the currentuser tests ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From weijun at openjdk.java.net Thu May 5 17:21:39 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 5 May 2022 17:21:39 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v3] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 20:32:30 GMT, Mat Carter wrote: >> On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. >> >> "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc >> >> No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode >> >> Tested on windows, passes tier1 and tier2 tests > > Mat Carter has updated the pull request incrementally with one additional commit since the last revision: > > Removed whitespace and simply passing ints between java and C++ Oops, I didn't realized that. Yes, you can divide it to 2 tests. The one needs admin privilege can be tagged `@run main/manual Test`. It probably won't get a lot of chance to run. ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From weijun at openjdk.java.net Thu May 5 19:25:13 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 5 May 2022 19:25:13 GMT Subject: RFR: 8285516: clearPassword should be called in a finally try block [v3] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 06:02:14 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> Could I have the simple update reviewed? >> >> In the PKCS12 key store implementation, the PBEKeySpec.clearPassword() should be called in a finally try block. Otherwise, the password cleanup could be interrupted by exceptions. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge > - an extra whitespace added > - 8285516: clearPassword should be called in a finally try block Tests run fine. No unexpected failure. ------------- PR: https://git.openjdk.java.net/jdk/pull/8377 From valeriep at openjdk.java.net Thu May 5 19:38:06 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 5 May 2022 19:38:06 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v2] In-Reply-To: References: Message-ID: > This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: update copyright year for PBES2Core.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8521/files - new: https://git.openjdk.java.net/jdk/pull/8521/files/3cc07c98..1a2b3f90 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8521.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8521/head:pull/8521 PR: https://git.openjdk.java.net/jdk/pull/8521 From dfuchs at openjdk.java.net Thu May 5 19:47:36 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 5 May 2022 19:47:36 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently Message-ID: Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java` A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit. The fix comprises several cleanup - in particular: - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`) ------------- Commit messages: - 8286194: ExecutorShutdown test fails intermittently Changes: https://git.openjdk.java.net/jdk/pull/8562/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8562&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286194 Stats: 135 lines in 7 files changed: 107 ins; 3 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/8562.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8562/head:pull/8562 PR: https://git.openjdk.java.net/jdk/pull/8562 From mullan at openjdk.java.net Thu May 5 20:28:06 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 5 May 2022 20:28:06 GMT Subject: RFR: 8285516: clearPassword should be called in a finally try block [v3] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 06:02:14 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> Could I have the simple update reviewed? >> >> In the PKCS12 key store implementation, the PBEKeySpec.clearPassword() should be called in a finally try block. Otherwise, the password cleanup could be interrupted by exceptions. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge > - an extra whitespace added > - 8285516: clearPassword should be called in a finally try block Even though this looks like a very low risk change, I would advise not integrating until next week as the Loom integration into 19 is planned for this weekend and it would be better to have as few disruptions as possible. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8377 From duke at openjdk.java.net Thu May 5 20:28:57 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 5 May 2022 20:28:57 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v4] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 01:19:20 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: >> >> - sixth iteration >> - Merge >> - fifth iteration >> - Merge >> - fourth iteration >> - third iteration >> - Merge >> - Merge >> - Merge >> - second iteration >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/64225e19...5ce46ffb > > src/java.security.jgss/share/classes/org/ietf/jgss/GSSException.java line 333: > >> 331: public String getMajorString() { >> 332: >> 333: return Objects.requireNonNullElseGet(majorString, () -> messages[major - 1]); > > Isn't this too fancy? Inside JDK this method is only used once in `java.time`. The method name has a `requireNonNull` inside so my understanding is that the object is mostly not null and the else case is just a fallback (maybe in an exceptional case?) At least in this class, most `GSSExceptions` are created without a major string. It's been around since JDK 9. I like the functionality, but I hate the name. It returns the first argument if non-null, otherwise it runs the lambda expression. I'll keep the change if you don't mind - one less thing for IntelliJ to nag about. Thanks for taking time to review this! I've accepted two of your suggestions and will be pushing an update shortly. > src/java.security.jgss/share/classes/sun/security/jgss/GSSHeader.java line 267: > >> 265: throw new IOException("DerInputStream.getLength(): lengthTag=" >> 266: + tmp + ", " >> 267: + "too big."); > > Combine the 2 lines above. Fixed. > src/java.security.jgss/share/classes/sun/security/jgss/krb5/SubjectComber.java line 154: > >> 152: while (iterator.hasNext()) { >> 153: Object obj = iterator.next(); >> 154: if (!(obj instanceof @SuppressWarnings("unchecked")KerberosTicket ticket)) { > > Does not look fluent to me. Maybe add a new line after the annotation? Added a new line. > src/java.security.jgss/share/classes/sun/security/jgss/spnego/SpNegoContext.java line 876: > >> 874: >> 875: // pass token >> 876: tok = Objects.requireNonNullElseGet(token, () -> new byte[0]); > > Is this how `requireNonNullElseGet` is meant to be used? I think so - return the token, or if the token is null, return an empty byte array. ------------- PR: https://git.openjdk.java.net/jdk/pull/7746 From mullan at openjdk.java.net Thu May 5 20:48:58 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 5 May 2022 20:48:58 GMT Subject: RFR: 8212136: Remove finalizer implementation in SSLSocketImpl [v5] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 02:07:13 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the SunJSSE provider implementation. It is one of the efforts to clean up the use of finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > More note update Even though this doesn't appear to be a big change, I would advise not integrating until next week as the Loom integration into 19 is planned for this weekend and it would be better to have as few disruptions as possible. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From duke at openjdk.java.net Thu May 5 21:05:40 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 5 May 2022 21:05:40 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v5] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8284688 > > [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: > > open/src/java.security.jgss/share/classes/javax/security > open/src/java.security.jgss/share/classes/org/ietf > open/src/java.security.jgss/share/classes/sun/security Mark Powers has updated the pull request incrementally with one additional commit since the last revision: Max comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7746/files - new: https://git.openjdk.java.net/jdk/pull/7746/files/5ce46ffb..15769b15 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7746&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7746&range=03-04 Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7746.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7746/head:pull/7746 PR: https://git.openjdk.java.net/jdk/pull/7746 From weijun at openjdk.java.net Thu May 5 21:16:04 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 5 May 2022 21:16:04 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v5] In-Reply-To: References: Message-ID: <0C6sLSUYcsOh6n5J72pSzyeELb7qVNZrDnN_0yG1SpY=.93f4f003-598f-4b0b-8009-59ac9abf112d@github.com> On Thu, 5 May 2022 21:05:40 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8284688 >> >> [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: >> >> open/src/java.security.jgss/share/classes/javax/security >> open/src/java.security.jgss/share/classes/org/ietf >> open/src/java.security.jgss/share/classes/sun/security > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > Max comments OK. But let's wait until next week so loom can be integrated smoothly. I doubt loom will touch any of the files here but this commit is still quite big. ------------- PR: https://git.openjdk.java.net/jdk/pull/7746 From valeriep at openjdk.java.net Thu May 5 22:08:04 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 5 May 2022 22:08:04 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: References: <7qogGHJ9jGPj6K6qqYVFnDfSUcSqJNB0jLifgJshstY=.be9bb286-dbce-446c-9684-dfa77ec2d0a4@github.com> <6YhRhen4o8Kg5pwhGxLF__535eB9ggQ57I6m6wu6oo4=.b4d0d99f-6d06-4ce7-8986-6470bae6a6f0@github.com> <7tFALuKc9QcTFYSzxokreBbeA3X5BpWIxqd mHoXjzNM=.c1ab3294-2edc-481e-a0e1-cf2e2731881a@github.com> Message-ID: On Wed, 4 May 2022 04:16:42 GMT, Xue-Lei Andrew Fan wrote: >> How about the case when no parameters are given? Say A is the user-supplied values, B is the provider specific default or random values, your suggestion has A, A+B, and null. Isn't the sentence about B needed (no A and provider can generate the parameters)? > > I think this sentence covers case B, "... or may contain additional default or random parameter > values used by the underlying signature implementation." Sean's comment on the other PR regarding Cipher.getParameters implies otherwise, i.e. `A few comments: I don't think this new text covers the case where the cipher is not initialized with any parameters, but the provider returns parameters. I tried to think of how to say that all in one sentence, but I think it is best to have two sentences covering each case, ex: "If this cipher was not initialized with parameters, the returned parameters may be null or may be ..." "If this cipher was initialized with parameters, the returned parameters may be the same or may be ..."` ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From valeriep at openjdk.java.net Thu May 5 22:08:05 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 5 May 2022 22:08:05 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: References: <7qogGHJ9jGPj6K6qqYVFnDfSUcSqJNB0jLifgJshstY=.be9bb286-dbce-446c-9684-dfa77ec2d0a4@github.com> <6YhRhen4o8Kg5pwhGxLF__535eB9ggQ57I6m6wu6oo4=.b4d0d99f-6d06-4ce7-8986-6470bae6a6f0@github.com> <7tFALuKc9QcTFYSzxokreBbeA3X5BpWIxqd mHoXjzNM=.c1ab3294-2edc-481e-a0e1-cf2e2731881a@github.com> Message-ID: On Thu, 5 May 2022 22:03:16 GMT, Valerie Peng wrote: >> I think this sentence covers case B, "... or may contain additional default or random parameter >> values used by the underlying signature implementation." > > Sean's comment on the other PR regarding Cipher.getParameters implies otherwise, i.e. `A few comments: > > I don't think this new text covers the case where the cipher is not initialized with any parameters, but the provider returns parameters. I tried to think of how to say that all in one sentence, but I think it is best to have two sentences covering each case, ex: "If this cipher was not initialized with parameters, the returned parameters may be null or may be ..." "If this cipher was initialized with parameters, the returned parameters may be the same or may be ..."` He later agrees that two sentences are probably too lengthy, so we ended up exploring other wording choices. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From wetmore at openjdk.java.net Thu May 5 22:55:49 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 5 May 2022 22:55:49 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v5] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 21:05:40 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8284688 >> >> [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: >> >> open/src/java.security.jgss/share/classes/javax/security >> open/src/java.security.jgss/share/classes/org/ietf >> open/src/java.security.jgss/share/classes/sun/security > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > Max comments Do the various IBM files need a copyright date update? ------------- PR: https://git.openjdk.java.net/jdk/pull/7746 From duke at openjdk.java.net Thu May 5 23:27:50 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 5 May 2022 23:27:50 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v5] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 21:05:40 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8284688 >> >> [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: >> >> open/src/java.security.jgss/share/classes/javax/security >> open/src/java.security.jgss/share/classes/org/ietf >> open/src/java.security.jgss/share/classes/sun/security > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > Max comments The IBM files say this at the top: DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER ------------- PR: https://git.openjdk.java.net/jdk/pull/7746 From wetmore at openjdk.java.net Thu May 5 23:51:50 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 5 May 2022 23:51:50 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v5] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 23:24:12 GMT, Mark Powers wrote: > The IBM files say this at the top: DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER That's the standard copyright notice. Let's check with Oracle's copyright person... ------------- PR: https://git.openjdk.java.net/jdk/pull/7746 From valeriep at openjdk.java.net Fri May 6 00:16:43 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 6 May 2022 00:16:43 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v3] In-Reply-To: References: Message-ID: <7UvFqlKqvFMvQ6u2oTzL0U0iLjIYJ_MeaZEXgQxTTBI=.acc4353f-2f44-4e35-b348-6cf2369d324b@github.com> > This is to update the method javadoc of java.security.Signature.getParameters() with the missing `@throws UnsupportedOperationException`. In addition, the wording on the returned parameters are updated to match those in Cipher and CipherSpi classes. > > CSR will be filed later. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Sync'ed w/ the wording in the other Cipher.getParameters() PR. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8396/files - new: https://git.openjdk.java.net/jdk/pull/8396/files/9be3644d..41e76e6e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=01-02 Stats: 11 lines in 2 files changed: 0 ins; 3 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8396/head:pull/8396 PR: https://git.openjdk.java.net/jdk/pull/8396 From jpai at openjdk.java.net Fri May 6 04:53:47 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 6 May 2022 04:53:47 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently In-Reply-To: References: Message-ID: <6ApqelKgO3qPJoybD75jQuR7md9pWrCfaRCbWCDK2sc=.41547359-b4dc-4620-ae3e-c03f8bd8f045@github.com> On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs wrote: > Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java` > > A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit. > > The fix comprises several cleanup - in particular: > > - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed > - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed > - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called > - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary > - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`) src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1039: > 1037: e.abort(selectorClosedException()); > 1038: } else { > 1039: selector.wakeup(); Hello Daniel, before this PR, except for the `wakeupSelector()` method on `SelectorManager`, all other methods which were operating on the `selector` field were `synchronized` on the `SelectorManager` instance. After this PR, that continues to be true except for this specific line where the operation on the `selector` field is outside of a `synchronized` block. Would that be OK? ------------- PR: https://git.openjdk.java.net/jdk/pull/8562 From jpai at openjdk.java.net Fri May 6 05:00:47 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 6 May 2022 05:00:47 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently In-Reply-To: References: Message-ID: <3Lw9SiX3u5vbZ1dgYN3cVNszotMqKI7105pDsYviWDU=.c0a9b634-cddc-45b1-b637-b69b4b7aff32@github.com> On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs wrote: > Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java` > > A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit. > > The fix comprises several cleanup - in particular: > > - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed > - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed > - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called > - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary > - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`) src/java.net.http/share/classes/jdk/internal/net/http/common/SSLFlowDelegate.java line 784: > 782: > 783: while (Utils.synchronizedRemaining(writeList) > 0 || hsTriggered() || needWrap()) { > 784: if (scheduler.isStopped()) return; If the `scheduler` is stopped then would this task instance be ever called again? If it won't be called again, then do you think we should perhaps drain the queued `writeList` to reduce any memory resource accumulation till the next GC cycle? ------------- PR: https://git.openjdk.java.net/jdk/pull/8562 From jpai at openjdk.java.net Fri May 6 05:19:50 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 6 May 2022 05:19:50 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently In-Reply-To: References: Message-ID: On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs wrote: > Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java` > > A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit. > > The fix comprises several cleanup - in particular: > > - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed > - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed > - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called > - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary > - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`) src/java.net.http/share/classes/jdk/internal/net/http/common/SubscriberWrapper.java line 347: > 345: > 346: void upstreamWindowUpdate() { > 347: if (pushScheduler.isStopped()) return; A similar question here. It looks to me that the contract with a `SequentialScheduler` is that the runnable task itself (or someone with access to the scheduler), is responsible for invoking the `runOrSchedule` method so that a next invocation of the task happens. When such a scheduler instance is already stopped, then the call to `runOrSchedule` is kind of a noop, with no next execution of the task taking place. In cases like here, where the task detects that the scheduler has already stopped, do you think the tasks should do some cleanup work like clearing up the `outputQ` of `ByteBuffers`? The question really isn't directly related to the PR, but I have been reviewing some unrelated test failures where a large number of HttpClient instances get created, so in that context, I was wondering if there's anything we could do to help reduce any potential memory usage. ------------- PR: https://git.openjdk.java.net/jdk/pull/8562 From jpai at openjdk.java.net Fri May 6 05:25:55 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 6 May 2022 05:25:55 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently In-Reply-To: References: Message-ID: On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs wrote: > Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java` > > A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit. > > The fix comprises several cleanup - in particular: > > - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed > - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed > - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called > - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary > - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`) test/jdk/java/net/httpclient/ReferenceTracker.java line 95: > 93: } > 94: > 95: private static String toString(ThreadInfo info) { Should we perhaps add a comment to this method explaining why we are duplicating the implementation of `ThreadInfo#toString()` here? I can't find in commit logs or the documentation of the `ThreadInfo` class on why its `toString()` implementation just outputs only 8 stacktrace elements. Do you think we should remove that restriction or document it in a separate issue? ------------- PR: https://git.openjdk.java.net/jdk/pull/8562 From dfuchs at openjdk.java.net Fri May 6 09:18:48 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 6 May 2022 09:18:48 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently In-Reply-To: <6ApqelKgO3qPJoybD75jQuR7md9pWrCfaRCbWCDK2sc=.41547359-b4dc-4620-ae3e-c03f8bd8f045@github.com> References: <6ApqelKgO3qPJoybD75jQuR7md9pWrCfaRCbWCDK2sc=.41547359-b4dc-4620-ae3e-c03f8bd8f045@github.com> Message-ID: On Fri, 6 May 2022 04:49:53 GMT, Jaikiran Pai wrote: >> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java` >> >> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit. >> >> The fix comprises several cleanup - in particular: >> >> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed >> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed >> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called >> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary >> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`) > > src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1039: > >> 1037: e.abort(selectorClosedException()); >> 1038: } else { >> 1039: selector.wakeup(); > > Hello Daniel, before this PR, except for the `wakeupSelector()` method on `SelectorManager`, all other methods which were operating on the `selector` field were `synchronized` on the `SelectorManager` instance. After this PR, that continues to be true except for this specific line where the operation on the `selector` field is outside of a `synchronized` block. Would that be OK? And this is what (or at least a part of what) was causing the issue. We need to add the event to the `registrations` list within a synchronized block because that's a plain ArrayList whose access is controlled by synchronizing on `this`. However the event should not be invoked within the synchronized and block, and if you look at the calling method (eventUpdated) you will see that this is what we are doing there too (raising the event without synchronizing). ------------- PR: https://git.openjdk.java.net/jdk/pull/8562 From dfuchs at openjdk.java.net Fri May 6 09:27:46 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 6 May 2022 09:27:46 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently In-Reply-To: <3Lw9SiX3u5vbZ1dgYN3cVNszotMqKI7105pDsYviWDU=.c0a9b634-cddc-45b1-b637-b69b4b7aff32@github.com> References: <3Lw9SiX3u5vbZ1dgYN3cVNszotMqKI7105pDsYviWDU=.c0a9b634-cddc-45b1-b637-b69b4b7aff32@github.com> Message-ID: On Fri, 6 May 2022 04:57:00 GMT, Jaikiran Pai wrote: >> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java` >> >> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit. >> >> The fix comprises several cleanup - in particular: >> >> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed >> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed >> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called >> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary >> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`) > > src/java.net.http/share/classes/jdk/internal/net/http/common/SSLFlowDelegate.java line 784: > >> 782: >> 783: while (Utils.synchronizedRemaining(writeList) > 0 || hsTriggered() || needWrap()) { >> 784: if (scheduler.isStopped()) return; > > If the `scheduler` is stopped then would this task instance be ever called again? If it won't be called again, then do you think we should perhaps drain the queued `writeList` to reduce any memory resource accumulation till the next GC cycle? if the scheduler is closed the connection is being stopped and will be shortly eligible for garbage collection, so I wouldn't bother with trying to clear the queue. > test/jdk/java/net/httpclient/ReferenceTracker.java line 95: > >> 93: } >> 94: >> 95: private static String toString(ThreadInfo info) { > > Should we perhaps add a comment to this method explaining why we are duplicating the implementation of `ThreadInfo#toString()` here? > > I can't find in commit logs or the documentation of the `ThreadInfo` class on why its `toString()` implementation just outputs only 8 stacktrace elements. Do you think we should remove that restriction or document it in a separate issue? Good idea to add a comment. I have also wondered if we should add a new method to ThreadInfo that would take a "maxdepth" integer. I don't know why the output is limited to 8 element. Maybe we should log an enhancement request and let the maintainers of ThreadInfo decide if they want to remove the limitation or provide a new method, or do nothing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8562 From dfuchs at openjdk.java.net Fri May 6 09:38:38 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 6 May 2022 09:38:38 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v2] In-Reply-To: References: Message-ID: > Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java` > > A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit. > > The fix comprises several cleanup - in particular: > > - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed > - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed > - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called > - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary > - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`) Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: Added a comment to ReferenceTracker.java as suggested in the review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8562/files - new: https://git.openjdk.java.net/jdk/pull/8562/files/0a674cef..ce8ad93d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8562&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8562&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8562.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8562/head:pull/8562 PR: https://git.openjdk.java.net/jdk/pull/8562 From jpai at openjdk.java.net Fri May 6 09:46:49 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 6 May 2022 09:46:49 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v2] In-Reply-To: References: Message-ID: <6EY0ZcPkoG2pbgwWnhqLyanBq8k-bBdZ04v23UfxwzQ=.1de41265-fb62-4f58-a3bb-076e738bb5f3@github.com> On Fri, 6 May 2022 09:38:38 GMT, Daniel Fuchs wrote: >> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java` >> >> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit. >> >> The fix comprises several cleanup - in particular: >> >> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed >> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed >> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called >> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary >> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`) > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > Added a comment to ReferenceTracker.java as suggested in the review The updated PR with the `ThreadInfo.toString()` comment, looks good to me. ------------- Marked as reviewed by jpai (Committer). PR: https://git.openjdk.java.net/jdk/pull/8562 From jpai at openjdk.java.net Fri May 6 09:46:50 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 6 May 2022 09:46:50 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v2] In-Reply-To: References: <6ApqelKgO3qPJoybD75jQuR7md9pWrCfaRCbWCDK2sc=.41547359-b4dc-4620-ae3e-c03f8bd8f045@github.com> Message-ID: On Fri, 6 May 2022 09:14:53 GMT, Daniel Fuchs wrote: >> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1039: >> >>> 1037: e.abort(selectorClosedException()); >>> 1038: } else { >>> 1039: selector.wakeup(); >> >> Hello Daniel, before this PR, except for the `wakeupSelector()` method on `SelectorManager`, all other methods which were operating on the `selector` field were `synchronized` on the `SelectorManager` instance. After this PR, that continues to be true except for this specific line where the operation on the `selector` field is outside of a `synchronized` block. Would that be OK? > > And this is what (or at least a part of what) was causing the issue. We need to add the event to the `registrations` list within a synchronized block because that's a plain ArrayList whose access is controlled by synchronizing on `this`. However the event should not be invoked within the synchronized and block, and if you look at the calling method (eventUpdated) you will see that this is what we are doing there too (raising the event without synchronizing). Thank you for that explanation. I understand this change better now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8562 From dfuchs at openjdk.java.net Fri May 6 09:46:50 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 6 May 2022 09:46:50 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v2] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 05:16:15 GMT, Jaikiran Pai wrote: >> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: >> >> Added a comment to ReferenceTracker.java as suggested in the review > > src/java.net.http/share/classes/jdk/internal/net/http/common/SubscriberWrapper.java line 347: > >> 345: >> 346: void upstreamWindowUpdate() { >> 347: if (pushScheduler.isStopped()) return; > > A similar question here. It looks to me that the contract with a `SequentialScheduler` is that the runnable task itself (or someone with access to the scheduler), is responsible for invoking the `runOrSchedule` method so that a next invocation of the task happens. When such a scheduler instance is already stopped, then the call to `runOrSchedule` is kind of a noop, with no next execution of the task taking place. In cases like here, where the task detects that the scheduler has already stopped, do you think the tasks should do some cleanup work like clearing up the `outputQ` of `ByteBuffers`? > > The question really isn't directly related to the PR, but I have been reviewing some unrelated test failures where a large number of HttpClient instances get created, so in that context, I was wondering if there's anything we could do to help reduce any potential memory usage. What happens here is a bit more subtle: if we don't return, the code is going to request more data from upstream, even though that data won't be processed, and that will fill up the queue, and potentially cause more data to be wrapped by the SSLEngine and sent down stream. I have observed that some activity was still ongoing in the SSLTube/SSLFlowDelegate after the underlying TCP channel had been closed, when there's no chance that this data will be ever sent, and the logs I was observing showed that returning at this point was effectively stopping that useless activity early. The fact that the channel is bidirectional and that the implementation is fully asynchronous means that several tasks may be executing in background threads at the time the TCP connection is closed. If the effect of these task is to simply request, process and submit data that will be later ignored (or cause more exceptions to be relayed) - then we should stop them early. ------------- PR: https://git.openjdk.java.net/jdk/pull/8562 From duke at openjdk.java.net Fri May 6 17:38:24 2022 From: duke at openjdk.java.net (Mark Powers) Date: Fri, 6 May 2022 17:38:24 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v6] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8284688 > > [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: > > open/src/java.security.jgss/share/classes/javax/security > open/src/java.security.jgss/share/classes/org/ietf > open/src/java.security.jgss/share/classes/sun/security Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge - Brad comments - Max comments - sixth iteration - Merge - fifth iteration - Merge - fourth iteration - third iteration - Merge - ... and 4 more: https://git.openjdk.java.net/jdk/compare/1277f5d8...520695f9 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7746/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7746&range=05 Stats: 932 lines in 73 files changed: 96 ins; 195 del; 641 mod Patch: https://git.openjdk.java.net/jdk/pull/7746.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7746/head:pull/7746 PR: https://git.openjdk.java.net/jdk/pull/7746 From duke at openjdk.java.net Fri May 6 17:38:24 2022 From: duke at openjdk.java.net (Mark Powers) Date: Fri, 6 May 2022 17:38:24 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v5] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 21:05:40 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8284688 >> >> [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: >> >> open/src/java.security.jgss/share/classes/javax/security >> open/src/java.security.jgss/share/classes/org/ietf >> open/src/java.security.jgss/share/classes/sun/security > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > Max comments Brad contacted Oracle's copyright person, and yes, we do need an Oracle copyright. Thanks for noticing this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7746 From duke at openjdk.java.net Fri May 6 17:54:09 2022 From: duke at openjdk.java.net (Mark Powers) Date: Fri, 6 May 2022 17:54:09 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults Message-ID: JDK-6725221 Standardize obtaining boolean properties with defaults ------------- Commit messages: - Merge - first iteration Changes: https://git.openjdk.java.net/jdk/pull/8559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8559&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6725221 Stats: 27 lines in 10 files changed: 1 ins; 4 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/8559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8559/head:pull/8559 PR: https://git.openjdk.java.net/jdk/pull/8559 From alanb at openjdk.java.net Fri May 6 17:59:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 6 May 2022 17:59:50 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: References: Message-ID: <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com> On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote: > JDK-6725221 Standardize obtaining boolean properties with defaults src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777: > 775: if (!printStackPropertiesSet && VM.initLevel() >= 1) { > 776: printStackWhenAccessFails = GetBooleanAction. > 777: privilegedGetProperty("sun.reflect.debugModuleAccessChecks"); Running with `-Dsun.reflect.debugModuleAccessChecks` should set printStackWhenAccessFails to true, not false. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From prr at openjdk.java.net Fri May 6 18:29:44 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 6 May 2022 18:29:44 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: References: Message-ID: On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote: > JDK-6725221 Standardize obtaining boolean properties with defaults The xtoolkit change is fine. I've not looked at anything else You'll clearly need multiple reviewers for this one. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8559 From wetmore at openjdk.java.net Sat May 7 00:08:45 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Sat, 7 May 2022 00:08:45 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: References: Message-ID: On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote: > JDK-6725221 Standardize obtaining boolean properties with defaults Sorry for the confusion. The original intent of this bug 14 years ago was to standardize the seclibs code where simple getProperty calls were needed in the context of an AccessController, without having to provide the doProvided calls. i.e. GetBooleanAction.privilegedGetProperty(). This was not intended not other parts of the JDK. For example: ChannelImpl.java provides a getBooleanProperty() method, which is very similar to GetBooleanAction. I noticed other places in the security where this was being done. Some of the classes like Debug have been rewritten (SSLLogger), so the issue does not appear to exist there any logger. The certpath code is working with Security.getProperty(), so that was a red herring. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From jjg at openjdk.java.net Sat May 7 01:10:14 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sat, 7 May 2022 01:10:14 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` Message-ID: Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. ------------- Commit messages: - JDK-8286348: incorrect use of `@serial` Changes: https://git.openjdk.java.net/jdk/pull/8586/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8586&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286348 Stats: 13 lines in 13 files changed: 0 ins; 13 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8586.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8586/head:pull/8586 PR: https://git.openjdk.java.net/jdk/pull/8586 From iris at openjdk.java.net Sat May 7 01:35:42 2022 From: iris at openjdk.java.net (Iris Clark) Date: Sat, 7 May 2022 01:35:42 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` In-Reply-To: References: Message-ID: <_QHTrTTzgqDutXsASdnudMpPvx8ruKtR7xUvlMqf6a4=.28645e0b-0b22-46aa-9e56-5b6572229dad@github.com> On Sat, 7 May 2022 01:04:03 GMT, Jonathan Gibbons wrote: > Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. > > There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. > > Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From dfuchs at openjdk.java.net Sat May 7 11:46:37 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Sat, 7 May 2022 11:46:37 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v3] In-Reply-To: References: Message-ID: > Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java` > > A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit. > > The fix comprises several cleanup - in particular: > > - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed > - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed > - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called > - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary > - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`) Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into ExecutorShutdown-intermittent-8286194 - Added a comment to ReferenceTracker.java as suggested in the review - 8286194: ExecutorShutdown test fails intermittently ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8562/files - new: https://git.openjdk.java.net/jdk/pull/8562/files/ce8ad93d..12bf40b0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8562&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8562&range=01-02 Stats: 102369 lines in 1228 files changed: 93484 ins; 3845 del; 5040 mod Patch: https://git.openjdk.java.net/jdk/pull/8562.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8562/head:pull/8562 PR: https://git.openjdk.java.net/jdk/pull/8562 From prr at openjdk.java.net Sun May 8 02:22:41 2022 From: prr at openjdk.java.net (Phil Race) Date: Sun, 8 May 2022 02:22:41 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` In-Reply-To: References: Message-ID: On Sat, 7 May 2022 01:04:03 GMT, Jonathan Gibbons wrote: > Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. > > There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. > > Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. Jon, all of the changes in java.desktop are already underway in https://github.com/openjdk/jdk/pull/8432/files and have been approved and even have an approved CSR .. just waiting for @alisenchung to type /integrate .. ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From prr at openjdk.java.net Sun May 8 02:25:50 2022 From: prr at openjdk.java.net (Phil Race) Date: Sun, 8 May 2022 02:25:50 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: References: Message-ID: On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote: > JDK-6725221 Standardize obtaining boolean properties with defaults I did wonder why it has security-libs as the sub-category and if the intent was not what we see here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From alanb at openjdk.java.net Sun May 8 05:18:49 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 8 May 2022 05:18:49 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: References: Message-ID: On Sun, 8 May 2022 02:22:08 GMT, Phil Race wrote: > I did wonder why it has security-libs as the sub-category and if the intent was not what we see here. I suspect the JBS issue was initially created to to look at the usages of getProperty in the security code but it has been extended. The issue is that it changes the meaning of the empty value case in at least two places so each one will require careful attention. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From jjg at openjdk.java.net Mon May 9 01:02:46 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 9 May 2022 01:02:46 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` In-Reply-To: References: Message-ID: <6Y-lOuoOL1sErefHH6psl-ADUySYCnXi5v1XqceO_Vo=.5b6bb529-e3e3-42f9-a318-16b11bc803cd@github.com> On Sun, 8 May 2022 02:19:09 GMT, Phil Race wrote: > Jon, all of the changes in java.desktop are already underway in https://github.com/openjdk/jdk/pull/8432/files and > have been approved and even have an approved CSR .. just waiting for @alisenchung to type /integrate .. Thanks for the heads up; I'll merge with Alisen's changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From duke at openjdk.java.net Mon May 9 12:19:49 2022 From: duke at openjdk.java.net (limck599) Date: Mon, 9 May 2022 12:19:49 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` In-Reply-To: References: Message-ID: On Sat, 7 May 2022 01:04:03 GMT, Jonathan Gibbons wrote: > Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. > > There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. > > Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. Marked as reviewed by limck599 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From weijun at openjdk.java.net Mon May 9 13:49:00 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 9 May 2022 13:49:00 GMT Subject: RFR: 8285743: Ensure each IntegerPolynomial object is only created once [v2] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 22:57:20 GMT, Weijun Wang wrote: >> All `IntegerPolynimial`s are singletons now. Also, hand-coded implementations for Ed25519 and Ed448 are removed. They were not used since `FieldGen` starts generating classes for them. >> >> No new regression test. This is a clean-up. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > move singleton back into impl and make constructor private make/jdk/src/classes/build/tools/intpoly/FieldGen.java line 837: > 835: // c[i + j] += 2 * a[i] * a[j] > 836: // } > 837: // } The comment was in the hand-coded curve25519 code. Moved here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8476 From weijun at openjdk.java.net Mon May 9 14:12:59 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 9 May 2022 14:12:59 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 19:38:06 GMT, Valerie Peng wrote: >> This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > update copyright year for PBES2Core.java Is it possible to rewrite `PKCS12PBECipherCore.java` so that the implementation inside is `CipherCore` instead of `CipherSpi`? I'd rather create a `CipherSpi` child inside this package as the base for all implementations that does nothing more but simply is able to expose all those `engineXYZ` methods to other classes in the same package. Sigh. src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java line 229: > 227: if (key instanceof javax.crypto.interfaces.PBEKey pbeKey) { > 228: salt = check(pbeKey.getSalt()); // may be null > 229: iCount = check(pbeKey.getIterationCount()); // may be 0 It seems the return value is never 0. src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 183: > 181: "for PBEWithSHA1And" + algo); > 182: } > 183: } How about using switch/case or at least put the `if` in same indentation level? src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 214: > 212: > 213: void implInit(int opmode, Key key, AlgorithmParameterSpec params, > 214: SecureRandom random, CipherSpi cipher) Why rename `cipherImpl` to `cipher`? I think `cipher` is usually a `Cipher` object and `cipherImpl` is a good name for a `CipherSpi` object. src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 215: > 213: void implInit(int opmode, Key key, AlgorithmParameterSpec params, > 214: SecureRandom random, CipherSpi cipher) > 215: throws InvalidKeyException, InvalidAlgorithmParameterException { Indent the line above. src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 314: > 312: } else if (cipher instanceof DESedeCipher tripleDes) { > 313: tripleDes.engineInit(opmode, cipherKey, ivSpec, random); > 314: } else { Can we combine the 2 if above? What else type can it be? ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From xuelei at openjdk.java.net Mon May 9 14:18:01 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 9 May 2022 14:18:01 GMT Subject: Integrated: 8212136: Remove finalizer implementation in SSLSocketImpl In-Reply-To: References: Message-ID: On Thu, 31 Mar 2022 20:15:35 GMT, Xue-Lei Andrew Fan wrote: > Please review the update to remove finalizer method in the SunJSSE provider implementation. It is one of the efforts to clean up the use of finalizer method in JDK. This pull request has now been integrated. Changeset: 034f20fe Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/034f20fe86babb63bf178251a732ac004297cc2d Stats: 39 lines in 1 file changed: 7 ins; 31 del; 1 mod 8212136: Remove finalizer implementation in SSLSocketImpl Reviewed-by: wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From xuelei at openjdk.java.net Mon May 9 14:18:47 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 9 May 2022 14:18:47 GMT Subject: Integrated: 8285516: clearPassword should be called in a finally try block In-Reply-To: References: Message-ID: On Sun, 24 Apr 2022 05:13:36 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > Could I have the simple update reviewed? > > In the PKCS12 key store implementation, the PBEKeySpec.clearPassword() should be called in a finally try block. Otherwise, the password cleanup could be interrupted by exceptions. > > Thanks, > Xuelei This pull request has now been integrated. Changeset: 36e4df9d Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/36e4df9d66134ef160bbba0e59d0e3dbb183ba4b Stats: 6 lines in 1 file changed: 2 ins; 2 del; 2 mod 8285516: clearPassword should be called in a finally try block Reviewed-by: mullan, hchao ------------- PR: https://git.openjdk.java.net/jdk/pull/8377 From xuelei at openjdk.java.net Mon May 9 15:06:49 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 9 May 2022 15:06:49 GMT Subject: RFR: 8285743: Ensure each IntegerPolynomial object is only created once [v2] In-Reply-To: References: Message-ID: <_0kGMQsYcXM-Pe93l_Fpt5h8p4yWB8z3xKL_Bys6IvM=.f3ffdb2b-d621-431f-a568-d9f2e763d7fe@github.com> On Fri, 29 Apr 2022 22:57:20 GMT, Weijun Wang wrote: >> All `IntegerPolynimial`s are singletons now. Also, hand-coded implementations for Ed25519 and Ed448 are removed. They were not used since `FieldGen` starts generating classes for them. >> >> No new regression test. This is a clean-up. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > move singleton back into impl and make constructor private It looks good and safe cleanup to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8476 From ascarpino at openjdk.java.net Mon May 9 16:48:49 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 9 May 2022 16:48:49 GMT Subject: RFR: 8285743: Ensure each IntegerPolynomial object is only created once [v2] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 22:57:20 GMT, Weijun Wang wrote: >> All `IntegerPolynimial`s are singletons now. Also, hand-coded implementations for Ed25519 and Ed448 are removed. They were not used since `FieldGen` starts generating classes for them. >> >> No new regression test. This is a clean-up. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > move singleton back into impl and make constructor private I'm good with this change ------------- Marked as reviewed by ascarpino (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8476 From weijun at openjdk.java.net Mon May 9 17:22:55 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 9 May 2022 17:22:55 GMT Subject: Integrated: 8285743: Ensure each IntegerPolynomial object is only created once In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 22:30:04 GMT, Weijun Wang wrote: > All `IntegerPolynimial`s are singletons now. Also, hand-coded implementations for Ed25519 and Ed448 are removed. They were not used since `FieldGen` starts generating classes for them. > > No new regression test. This is a clean-up. This pull request has now been integrated. Changeset: 397d095f Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/397d095f661e9d9c98b8254fb7867dc87047b0b8 Stats: 507 lines in 10 files changed: 16 ins; 465 del; 26 mod 8285743: Ensure each IntegerPolynomial object is only created once Reviewed-by: xuelei, ascarpino ------------- PR: https://git.openjdk.java.net/jdk/pull/8476 From jjg at openjdk.java.net Mon May 9 18:14:35 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 9 May 2022 18:14:35 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` [v2] In-Reply-To: References: Message-ID: > Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. > > There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. > > Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge with upstream/master - JDK-8286348: incorrect use of `@serial` ------------- Changes: https://git.openjdk.java.net/jdk/pull/8586/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8586&range=01 Stats: 11 lines in 11 files changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8586.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8586/head:pull/8586 PR: https://git.openjdk.java.net/jdk/pull/8586 From valeriep at openjdk.java.net Mon May 9 18:28:04 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 9 May 2022 18:28:04 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v5] In-Reply-To: References: Message-ID: > Anyone can help review this javadoc update? The main change is the wording for the method javadoc of Cipher.getParameters()/CipherSpi.engineGetParameters(). The original wording is somewhat restrictive and request is to broaden this to accommodate more scenarios such as when null can be returned. > The rest are minor things like add {@code } to class name and null, and remove redundant ".". > > Will file CSR after the review is close to being wrapped up. > Thanks~ Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8209038 - update to address review feedback and minor javadoc cleanup - Update for getParameters() - Update w/ review feedbacks - 8209038: Clarify the javadoc of Cipher.getParameters() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8117/files - new: https://git.openjdk.java.net/jdk/pull/8117/files/77e8fa0d..f9727edf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8117&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8117&range=03-04 Stats: 313143 lines in 4579 files changed: 242497 ins; 21053 del; 49593 mod Patch: https://git.openjdk.java.net/jdk/pull/8117.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8117/head:pull/8117 PR: https://git.openjdk.java.net/jdk/pull/8117 From valeriep at openjdk.java.net Mon May 9 18:45:05 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 9 May 2022 18:45:05 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v4] In-Reply-To: References: Message-ID: > This is to update the method javadoc of java.security.Signature.getParameters() with the missing `@throws UnsupportedOperationException`. In addition, the wording on the returned parameters are updated to match those in Cipher and CipherSpi classes. > > CSR will be filed later. > > Thanks, > Valerie Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8253176 - Sync'ed w/ the wording in the other Cipher.getParameters() PR. - Undo un-intentional changes. - 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8396/files - new: https://git.openjdk.java.net/jdk/pull/8396/files/41e76e6e..660adeeb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=02-03 Stats: 135411 lines in 2025 files changed: 115484 ins; 9117 del; 10810 mod Patch: https://git.openjdk.java.net/jdk/pull/8396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8396/head:pull/8396 PR: https://git.openjdk.java.net/jdk/pull/8396 From prr at openjdk.java.net Mon May 9 18:46:54 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:46:54 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` [v2] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 18:14:35 GMT, Jonathan Gibbons wrote: >> Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. >> >> There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. >> >> Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. > > Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge with upstream/master > - JDK-8286348: incorrect use of `@serial` Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From jjg at openjdk.java.net Mon May 9 20:19:45 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 9 May 2022 20:19:45 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` [v3] In-Reply-To: References: Message-ID: <_j4p9lLYLNTExFqEbx6Uwwwohdj7PY9nfOIh10fWQ60=.d5d107a5-6565-4fa9-abec-fe806e4d35ab@github.com> > Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. > > There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. > > Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Fix whitespace (blank lines) after merge ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8586/files - new: https://git.openjdk.java.net/jdk/pull/8586/files/d1920183..8684b44b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8586&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8586&range=01-02 Stats: 10 lines in 10 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8586.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8586/head:pull/8586 PR: https://git.openjdk.java.net/jdk/pull/8586 From djelinski at openjdk.java.net Mon May 9 20:22:37 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 9 May 2022 20:22:37 GMT Subject: RFR: 8286433: Cache certificates decoded from TLS session tickets Message-ID: <6zuDRK0GQOkGXEtOmQrutFPUikMR-5aO02hp8Pl9Q4k=.0225a452-6a3f-47d5-9471-cd4ee82afc37@github.com> When a TLS server resumes a session from a stateless session ticket, it populates the `SSLSessionImpl`'s `localCerts` and `peerCerts` fields with certificates deserialized from the session ticket. These certificates are often the same across a large number of tickets. This patch implements a certificate cache lookup for these certificates. This enables us to avoid deserializing the same certificates repeatedly, and saves memory by reusing the same certificate objects. ------------- Commit messages: - Cache received certificates Changes: https://git.openjdk.java.net/jdk/pull/8608/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8608&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286433 Stats: 26 lines in 2 files changed: 13 ins; 8 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8608.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8608/head:pull/8608 PR: https://git.openjdk.java.net/jdk/pull/8608 From djelinski at openjdk.java.net Mon May 9 20:22:37 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 9 May 2022 20:22:37 GMT Subject: RFR: 8286433: Cache certificates decoded from TLS session tickets In-Reply-To: <6zuDRK0GQOkGXEtOmQrutFPUikMR-5aO02hp8Pl9Q4k=.0225a452-6a3f-47d5-9471-cd4ee82afc37@github.com> References: <6zuDRK0GQOkGXEtOmQrutFPUikMR-5aO02hp8Pl9Q4k=.0225a452-6a3f-47d5-9471-cd4ee82afc37@github.com> Message-ID: On Mon, 9 May 2022 19:38:36 GMT, Daniel Jeli?ski wrote: > When a TLS server resumes a session from a stateless session ticket, it populates the `SSLSessionImpl`'s `localCerts` and `peerCerts` fields with certificates deserialized from the session ticket. These certificates are often the same across a large number of tickets. > > This patch implements a certificate cache lookup for these certificates. This enables us to avoid deserializing the same certificates repeatedly, and saves memory by reusing the same certificate objects. Performance results: Before: Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake true TLSv1.2 thrpt 5 10425.534 ? 785.613 ops/s SSLHandshake.doHandshake true TLS thrpt 5 673.131 ? 24.857 ops/s after: Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake true TLSv1.2 thrpt 5 11882.724 ? 106.444 ops/s SSLHandshake.doHandshake true TLS thrpt 5 717.195 ? 210.658 ops/s The benchmark shows a nice improvement in throughput on session resumption; it uses the same `localCerts` on all sessions, and `peerCerts` are empty. The performance of full handshakes (not shown) didn't change, which is expected because full handshakes do not use the changed code. GC profiling results: Before: Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake:?gc.alloc.rate.norm true TLSv1.2 thrpt 15 173868.322 ? 1554.251 B/op SSLHandshake.doHandshake:?gc.alloc.rate.norm true TLS thrpt 15 404166.493 ? 1640.523 B/op After: Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake:?gc.alloc.rate.norm true TLSv1.2 thrpt 15 140972.286 ? 1782.103 B/op SSLHandshake.doHandshake:?gc.alloc.rate.norm true TLS thrpt 15 370317.660 ? 1846.107 B/op Memory allocation is reduced by ~30kB per handshake on session resumption. The allocation profile of full handshakes (not shown) didn't change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8608 From prr at openjdk.java.net Mon May 9 20:24:50 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 20:24:50 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` [v3] In-Reply-To: <_j4p9lLYLNTExFqEbx6Uwwwohdj7PY9nfOIh10fWQ60=.d5d107a5-6565-4fa9-abec-fe806e4d35ab@github.com> References: <_j4p9lLYLNTExFqEbx6Uwwwohdj7PY9nfOIh10fWQ60=.d5d107a5-6565-4fa9-abec-fe806e4d35ab@github.com> Message-ID: On Mon, 9 May 2022 20:19:45 GMT, Jonathan Gibbons wrote: >> Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. >> >> There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. >> >> Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespace (blank lines) after merge Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From jjg at openjdk.java.net Mon May 9 20:38:52 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 9 May 2022 20:38:52 GMT Subject: Integrated: JDK-8286348: incorrect use of `@serial` In-Reply-To: References: Message-ID: On Sat, 7 May 2022 01:04:03 GMT, Jonathan Gibbons wrote: > Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. > > There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. > > Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. This pull request has now been integrated. Changeset: 54e33082 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/54e33082105dcbcfc795839c954f6e63402edff1 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8286348: incorrect use of `@serial` Reviewed-by: iris, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From weijun at openjdk.java.net Mon May 9 21:52:19 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 9 May 2022 21:52:19 GMT Subject: RFR: 8286428: AlgorithmId should understand PBES2 Message-ID: <4gme7URJVgzZQCxSXT68oLO6xmuo9bYbX1xnEc_z3-s=.1e1771b6-2bab-4788-8fea-24e6f4f32387@github.com> `AlgorithmId.getName` is updated for PBES2 algorithm identifiers so it directly returns the standard algorithm defined by Java (Ex: `PBEWithHmacSHA256AndAES_256`), instead of a simple "PBES2". Please note I specifically update the javadoc for this method to clarify that this name is meant to be a name that's recognized by various `getInstance()` methods. This is how we are actually using this method. After this change, the `javax.crypto.EncryptedPrivateKeyInfo` API automatically works with PBES2 encrypted data. As the spec of its `getAlgName()` methods says, "Standard name is returned". This is shown by the newly include regression test. Existing security-related tests run fine. ------------- Commit messages: - typo - the fix Changes: https://git.openjdk.java.net/jdk/pull/8615/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8615&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286428 Stats: 149 lines in 3 files changed: 118 ins; 16 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8615/head:pull/8615 PR: https://git.openjdk.java.net/jdk/pull/8615 From valeriep at openjdk.java.net Mon May 9 23:26:49 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 9 May 2022 23:26:49 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v2] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 14:00:58 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright year for PBES2Core.java > > src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java line 229: > >> 227: if (key instanceof javax.crypto.interfaces.PBEKey pbeKey) { >> 228: salt = check(pbeKey.getSalt()); // may be null >> 229: iCount = check(pbeKey.getIterationCount()); // may be 0 > > It seems the return value is never 0. Oh, the comment about "may be 0" is meant toward the pbeKey.getInterationCount() call... Hmm, I will make it clearer. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From valeriep at openjdk.java.net Mon May 9 23:30:58 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 9 May 2022 23:30:58 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v3] In-Reply-To: References: Message-ID: <39L29jVHi67ZROEGeErtQRW2rqKsuJKQwx9UD50fvsM=.7e5f86e6-8264-4bcd-b727-f8a931e253bd@github.com> > This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8002277 - update copyright year for PBES2Core.java - Enhanced test with more decryption w/o parameters scenario. - 8002277: Refactor two PBE classes to simplify maintenance ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8521/files - new: https://git.openjdk.java.net/jdk/pull/8521/files/1a2b3f90..307d2765 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=01-02 Stats: 126825 lines in 1830 files changed: 108724 ins; 8599 del; 9502 mod Patch: https://git.openjdk.java.net/jdk/pull/8521.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8521/head:pull/8521 PR: https://git.openjdk.java.net/jdk/pull/8521 From valeriep at openjdk.java.net Mon May 9 23:40:03 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 9 May 2022 23:40:03 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v2] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 22:20:32 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright year for PBES2Core.java > > src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 183: > >> 181: "for PBEWithSHA1And" + algo); >> 182: } >> 183: } > > How about using switch/case or at least put the `if` in same indentation level? Yes, will use switch. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From valeriep at openjdk.java.net Mon May 9 23:44:50 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 9 May 2022 23:44:50 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v2] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 22:26:31 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright year for PBES2Core.java > > src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 214: > >> 212: >> 213: void implInit(int opmode, Key key, AlgorithmParameterSpec params, >> 214: SecureRandom random, CipherSpi cipher) > > Why rename `cipherImpl` to `cipher`? I think `cipher` is usually a `Cipher` object and `cipherImpl` is a good name for a `CipherSpi` object. cipher vs cipherImpl looks same to me. I can revert it back since you have a preference. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From valeriep at openjdk.java.net Mon May 9 23:48:47 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 9 May 2022 23:48:47 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v2] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 22:22:47 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright year for PBES2Core.java > > src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 215: > >> 213: void implInit(int opmode, Key key, AlgorithmParameterSpec params, >> 214: SecureRandom random, CipherSpi cipher) >> 215: throws InvalidKeyException, InvalidAlgorithmParameterException { > > Indent the line above. Ok, I will change the indentation of other throws to be consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From weijun at openjdk.java.net Tue May 10 00:12:48 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 10 May 2022 00:12:48 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v2] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 23:23:05 GMT, Valerie Peng wrote: >> src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java line 229: >> >>> 227: if (key instanceof javax.crypto.interfaces.PBEKey pbeKey) { >>> 228: salt = check(pbeKey.getSalt()); // may be null >>> 229: iCount = check(pbeKey.getIterationCount()); // may be 0 >> >> It seems the return value is never 0. > > Oh, the comment about "may be 0" is meant toward the pbeKey.getInterationCount() call... Hmm, I will make it clearer. I see. Another question, shall we reset `salt` and `iCount` at the beginning? If `params` is null and `key` is not `PBEKey` and there is an existing positive `iCount`, it will not be set to `DEFAULT_COUNT`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From weijun at openjdk.java.net Tue May 10 00:22:10 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 10 May 2022 00:22:10 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v4] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 18:45:05 GMT, Valerie Peng wrote: >> This is to update the method javadoc of java.security.Signature.getParameters() with the missing `@throws UnsupportedOperationException`. In addition, the wording on the returned parameters are updated to match those in Cipher and CipherSpi classes. >> >> CSR will be filed later. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8253176 > - Sync'ed w/ the wording in the other Cipher.getParameters() PR. > - Undo un-intentional changes. > - 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From weijun at openjdk.java.net Tue May 10 00:22:15 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 10 May 2022 00:22:15 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v5] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 18:28:04 GMT, Valerie Peng wrote: >> Anyone can help review this javadoc update? The main change is the wording for the method javadoc of Cipher.getParameters()/CipherSpi.engineGetParameters(). The original wording is somewhat restrictive and request is to broaden this to accommodate more scenarios such as when null can be returned. >> The rest are minor things like add {@code } to class name and null, and remove redundant ".". >> >> Will file CSR after the review is close to being wrapped up. >> Thanks~ > > Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8209038 > - update to address review feedback and minor javadoc cleanup > - Update for getParameters() > - Update w/ review feedbacks > - 8209038: Clarify the javadoc of Cipher.getParameters() Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From valeriep at openjdk.java.net Tue May 10 01:25:47 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 10 May 2022 01:25:47 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v2] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 22:24:57 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright year for PBES2Core.java > > src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 314: > >> 312: } else if (cipher instanceof DESedeCipher tripleDes) { >> 313: tripleDes.engineInit(opmode, cipherKey, ivSpec, random); >> 314: } else { > > Can we combine the 2 if above? What else type can it be? Currently, the specified CipherSpi object is one of RC4, RC2, DESede. The "else" part is for catching new PKCS12 PBE algorithms support which uses other cipher algorithms. CipherSpi.engineInit(...) is protected, so that's why we use the instanceof to cast the CipherSpi object into the actual impl class in order to call the engineInit(...) since the actual impl class is in the same package of this class. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From valeriep at openjdk.java.net Tue May 10 01:54:36 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 10 May 2022 01:54:36 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v2] In-Reply-To: References: Message-ID: <8Yl1DOu2_veKSTpC9w8V1b4pH_rzbHlzHKx0t__0PhE=.342cb488-0b31-4df6-ba09-9dc6afe72dfb@github.com> On Mon, 9 May 2022 14:09:28 GMT, Weijun Wang wrote: > It's a pity you have to implement all those `engineXyz` methods in all three `CipherSpi` implementations here. Is there something simpler? I debated shifting all these "engineXyz" methods into the PKCS12PBECipherCore class and store the CipherSpi object inside PKCS12PBECipher class, but then whenever we need to call "Cipher.engineXyz" methods, we'd need to cast the CipherSpi object to the actual impl class. There are also additional logic for handling mode, padding in PKCS12PBECipherCore class if we go this route. Comparing to the current approach, there are different pros and cons. I prefer less casting. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From weijun at openjdk.java.net Tue May 10 02:30:36 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 10 May 2022 02:30:36 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 01:22:21 GMT, Valerie Peng wrote: >> src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 314: >> >>> 312: } else if (cipher instanceof DESedeCipher tripleDes) { >>> 313: tripleDes.engineInit(opmode, cipherKey, ivSpec, random); >>> 314: } else { >> >> Can we combine the 2 if above? What else type can it be? > > Currently, the specified CipherSpi object is one of RC4, RC2, DESede. The "else" part is for catching new PKCS12 PBE algorithms support which uses other cipher algorithms. > CipherSpi.engineInit(...) is protected, so that's why we use the instanceof to cast the CipherSpi object into the actual impl class in order to call the engineInit(...) since the actual impl class is in the same package of this class. The `core.init(..., cipher)` is actually `cipher.init(core.translateKeyAndParams())`. Is it possible we write it this way? ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From xuelei at openjdk.java.net Tue May 10 04:19:12 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 10 May 2022 04:19:12 GMT Subject: RFR: 8286423: Destroy password protection in the example code in KeyStore Message-ID: <6jxClfPxpFrwWpPJG06sK5mEfNq8PE17eSMCppxiTK0=.58e07c78-0ba7-47f0-8893-8bb87adb7231@github.com> Hi, May I have this simple example update in the KeyStore specification? Password protection should be destroyed in the example code in KeyStore specification. Otherwise, applications may just copy and past the code, and forget to clean up password protection. It's a trivial update, and may not worthy of a CSR. But please let me know if you would like to have a CSR filed. Thanks, Xuelei ------------- Commit messages: - 8286423: Destroy password protection in the example code in KeyStore Changes: https://git.openjdk.java.net/jdk/pull/8623/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8623&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286423 Stats: 18 lines in 1 file changed: 3 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8623.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8623/head:pull/8623 PR: https://git.openjdk.java.net/jdk/pull/8623 From weijun at openjdk.java.net Tue May 10 13:11:56 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 10 May 2022 13:11:56 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v3] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 16:36:04 GMT, Mat Carter wrote: >> I'd like to contribute a test. Please modify it as much as you like. You can put it inside `test/jdk/sun/security/mscapi/`. >> >> /* >> * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> * under the terms of the GNU General Public License version 2 only, as >> * published by the Free Software Foundation. >> * >> * This code is distributed in the hope that it will be useful, but WITHOUT >> * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >> * version 2 for more details (a copy is included in the LICENSE file that >> * accompanied this code). >> * >> * You should have received a copy of the GNU General Public License version >> * 2 along with this work; if not, write to the Free Software Foundation, >> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> * >> * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA >> * or visit www.oracle.com if you need additional information or have any >> * questions. >> */ >> >> import jdk.test.lib.Asserts; >> import jdk.test.lib.SecurityTools; >> >> import java.security.KeyStore; >> import java.util.Collections; >> import java.util.List; >> import java.util.Locale; >> >> /* >> * @test >> * @bug 6782021 >> * @requires os.family == "windows" >> * @library /test/lib >> * @summary More keystore types >> */ >> public class AllTypes { >> public static void main(String[] args) throws Exception { >> var nm = test("windows-my"); >> var nr = test("windows-root"); >> var nmu = test("windows-my-currentuser"); >> var nru = test("windows-root-currentuser"); >> var nmm = test("windows-my-localmachine"); >> var nrm = test("windows-root-localmachine"); >> Asserts.assertEQ(nm, nmu); >> Asserts.assertEQ(nr, nru); >> } >> >> private static List test(String type) throws Exception { >> var stdType = "Windows-" + type.substring(8).toUpperCase(Locale.ROOT); >> SecurityTools.keytool("-storetype " + type + " -list") >> .shouldHaveExitValue(0) >> .shouldContain("Keystore provider: SunMSCAPI") >> .shouldContain("Keystore type: " + stdType); >> KeyStore ks = KeyStore.getInstance(type); >> ks.load(null, null); >> var content = Collections.list(ks.aliases()); >> Collections.sort(content); >> return content; >> } >> } > > @wangweij - regarding the two tests for localmachine, these will throw a KeyStore exception "Access denied" if the test is not run as admin, is there anyway in the test to make that a requirement? If so we could split into two tests, one in admin that does all and one in non-admin that does the currentuser tests @macarte You need to finalize your CSR soon if you want to include this change into JDK 19. RDP1 is 2022/06/09, and all enhancements require approval after that. BTW, is it possible to detect whether you have admin privilege inside the test? There is a `NTSystem` class inside Java which can find out user info. Maybe the `getGroupIDs()` method will tell you if you are an admin? We can enhance the test before RC. ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From weijun at openjdk.java.net Tue May 10 13:39:50 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 10 May 2022 13:39:50 GMT Subject: RFR: 8286423: Destroy password protection in the example code in KeyStore In-Reply-To: <6jxClfPxpFrwWpPJG06sK5mEfNq8PE17eSMCppxiTK0=.58e07c78-0ba7-47f0-8893-8bb87adb7231@github.com> References: <6jxClfPxpFrwWpPJG06sK5mEfNq8PE17eSMCppxiTK0=.58e07c78-0ba7-47f0-8893-8bb87adb7231@github.com> Message-ID: <23aXdnh3_mKt3MEI_FPnhhwve4re9PT3wiZYG4QVoy8=.8c521c4a-124a-414d-bdeb-0d3fa5381853@github.com> On Tue, 10 May 2022 04:13:43 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this simple example update in the KeyStore specification? > > Password protection should be destroyed in the example code in KeyStore specification. Otherwise, applications may just copy and past the code, and forget to clean up password protection. > > It's a trivial update, and may not worthy of a CSR. But please let me know if you would like to have a CSR filed. > > Thanks, > Xuelei src/java.base/share/classes/java/security/KeyStore.java line 165: > 163: * } > 164: * } finally { > 165: * protParam.destroy(); `KeyStore.ProtectionParameter` does not have a `destroy` method. Only `PasswordProtection` does. ------------- PR: https://git.openjdk.java.net/jdk/pull/8623 From duke at openjdk.java.net Tue May 10 17:23:24 2022 From: duke at openjdk.java.net (Mat Carter) Date: Tue, 10 May 2022 17:23:24 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v4] In-Reply-To: References: Message-ID: > On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. > > "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc > > No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode > > Tested on windows, passes tier1 and tier2 tests Mat Carter has updated the pull request incrementally with one additional commit since the last revision: Minor formatting and spelling issues addressed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8211/files - new: https://git.openjdk.java.net/jdk/pull/8211/files/5b3d4115..c56ce0fd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8211&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8211&range=02-03 Stats: 18 lines in 1 file changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/8211.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8211/head:pull/8211 PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Tue May 10 18:55:50 2022 From: duke at openjdk.java.net (Mat Carter) Date: Tue, 10 May 2022 18:55:50 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v5] In-Reply-To: References: Message-ID: > On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. > > "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc > > No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode > > Tested on windows, passes tier1 and tier2 tests Mat Carter has updated the pull request incrementally with one additional commit since the last revision: Add test from wangweij ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8211/files - new: https://git.openjdk.java.net/jdk/pull/8211/files/c56ce0fd..985378fb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8211&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8211&range=03-04 Stats: 87 lines in 1 file changed: 87 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8211.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8211/head:pull/8211 PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Tue May 10 18:55:50 2022 From: duke at openjdk.java.net (Mat Carter) Date: Tue, 10 May 2022 18:55:50 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v3] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 13:07:02 GMT, Weijun Wang wrote: >> @wangweij - regarding the two tests for localmachine, these will throw a KeyStore exception "Access denied" if the test is not run as admin, is there anyway in the test to make that a requirement? If so we could split into two tests, one in admin that does all and one in non-admin that does the currentuser tests > > @macarte You need to finalize your CSR soon if you want to include this change into JDK 19. RDP1 is 2022/06/09, and all enhancements require approval after that. > > BTW, is it possible to detect whether you have admin privilege inside the test? There is a `NTSystem` class inside Java which can find out user info. Maybe the `getGroupIDs()` method will tell you if you are an admin? > > We can enhance the test before RC. @wangweij - I added your test and updated to handle Access Denied errors due to admin rights missing, in this case we ignore the test The CSR has been finalized and I feel we are ready to close out this PR ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From weijun at openjdk.java.net Tue May 10 18:58:42 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 10 May 2022 18:58:42 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v4] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 17:23:24 GMT, Mat Carter wrote: >> On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. >> >> "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc >> >> No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode >> >> Tested on windows, passes tier1 and tier2 tests > > Mat Carter has updated the pull request incrementally with one additional commit since the last revision: > > Minor formatting and spelling issues addressed Great. After the CSR is approved I will approve this PR as well. Then you will need to type the `/integrate` command as a comment here, and I will type `/sponsor`. Then the Skara bot will integrate the change and close the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Tue May 10 19:27:50 2022 From: duke at openjdk.java.net (Mark Powers) Date: Tue, 10 May 2022 19:27:50 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com> References: <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com> Message-ID: On Fri, 6 May 2022 17:56:44 GMT, Alan Bateman wrote: >> JDK-6725221 Standardize obtaining boolean properties with defaults > > src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777: > >> 775: if (!printStackPropertiesSet && VM.initLevel() >= 1) { >> 776: printStackWhenAccessFails = GetBooleanAction. >> 777: privilegedGetProperty("sun.reflect.debugModuleAccessChecks"); > > Running with `-Dsun.reflect.debugModuleAccessChecks` should set printStackWhenAccessFails to true, not false. You are right. The old way maps the null string to true, and the new way maps it to false. I did not notice that. At this point, I see no value in making the "true".equals and "false".equals changes. Too much can break. I'll reverse these changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From mullan at openjdk.java.net Tue May 10 20:41:06 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 10 May 2022 20:41:06 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v5] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 18:28:04 GMT, Valerie Peng wrote: >> Anyone can help review this javadoc update? The main change is the wording for the method javadoc of Cipher.getParameters()/CipherSpi.engineGetParameters(). The original wording is somewhat restrictive and request is to broaden this to accommodate more scenarios such as when null can be returned. >> The rest are minor things like add {@code } to class name and null, and remove redundant ".". >> >> Will file CSR after the review is close to being wrapped up. >> Thanks~ > > Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8209038 > - update to address review feedback and minor javadoc cleanup > - Update for getParameters() > - Update w/ review feedbacks > - 8209038: Clarify the javadoc of Cipher.getParameters() Marked as reviewed by mullan (Reviewer). src/java.base/share/classes/javax/crypto/CipherSpi.java line 294: > 292: * values used by the underlying cipher implementation. If the required > 293: * parameters were not supplied and can be generated by the cipher, the > 294: * generated parameters will be returned. Otherwise, {@code null} is Minor wording nit - change "will be" to "are" to be consistent with other wording which uses the present tense. Same comment applies to `Cipher.getParameters`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From mullan at openjdk.java.net Tue May 10 20:47:12 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 10 May 2022 20:47:12 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v4] In-Reply-To: References: Message-ID: <3PhZPgbMppa_YVJ8GECtwlIHcn2rFZSaYJLmA1BsyL8=.05b69ecd-5bac-48c2-a4c3-5d16f1ef27bb@github.com> On Mon, 9 May 2022 18:45:05 GMT, Valerie Peng wrote: >> This is to update the method javadoc of java.security.Signature.getParameters() with the missing `@throws UnsupportedOperationException`. In addition, the wording on the returned parameters are updated to match those in Cipher and CipherSpi classes. >> >> CSR will be filed later. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8253176 > - Sync'ed w/ the wording in the other Cipher.getParameters() PR. > - Undo un-intentional changes. > - 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException src/java.base/share/classes/java/security/SignatureSpi.java line 399: > 397: * values used by the underlying signature scheme. If the required > 398: * parameters were not supplied and can be generated by the signature, > 399: * the generated parameters will be returned. Otherwise, {@code null} Minor wording nit - change "will be" to "are" to be consistent with other wording which uses the present tense. Same comment applies to `Signature.getParameters`. Also, do we no longer need to mention the part "and the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}"? ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From weijun at openjdk.java.net Tue May 10 21:03:52 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 10 May 2022 21:03:52 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v3] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 18:51:07 GMT, Mat Carter wrote: >> @macarte You need to finalize your CSR soon if you want to include this change into JDK 19. RDP1 is 2022/06/09, and all enhancements require approval after that. >> >> BTW, is it possible to detect whether you have admin privilege inside the test? There is a `NTSystem` class inside Java which can find out user info. Maybe the `getGroupIDs()` method will tell you if you are an admin? >> >> We can enhance the test before RC. > > @wangweij - I added your test and updated to handle Access Denied errors due to admin rights missing, in this case we ignore the test > > The CSR has been finalized and I feel we are ready to close out this PR @macarte Can you explain more on when an "access denied" error could happen? I create a normal user in my local AD and didn't see that. We might need to talk about this in the release note. ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From rriggs at openjdk.java.net Tue May 10 21:38:19 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 10 May 2022 21:38:19 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base Message-ID: PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions >From the CSR: "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." This PR anticipates the warnings and adds explicit casts to replace the implicit casts. In most cases, the cast matches the type of the right-hand side to type of the compound assignment. Since these casts are truncating the value, there might be a different refactoring that avoids the cast but a direct replacement was chosen here. (Advise and suggestions will inform similar updates to other OpenJDK modules). ------------- Commit messages: - 8286378: Address possibly lossy conversions in java.base Changes: https://git.openjdk.java.net/jdk/pull/8642/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286378 Stats: 57 lines in 33 files changed: 1 ins; 3 del; 53 mod Patch: https://git.openjdk.java.net/jdk/pull/8642.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8642/head:pull/8642 PR: https://git.openjdk.java.net/jdk/pull/8642 From naoto at openjdk.java.net Tue May 10 22:02:49 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 10 May 2022 22:02:49 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base In-Reply-To: References: Message-ID: On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs wrote: > PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." > > This PR anticipates the warnings and adds explicit casts to replace the implicit casts. > In most cases, the cast matches the type of the right-hand side to type of the compound assignment. > Since these casts are truncating the value, there might be a different refactoring that avoids the cast > but a direct replacement was chosen here. > > (Advise and suggestions will inform similar updates to other OpenJDK modules). Looks good. Assuming copyright years will be updated. src/java.base/share/classes/java/time/es line 1: > 1: X Looks like a random file was added by accident? ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8642 From weijun at openjdk.java.net Tue May 10 22:04:47 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 10 May 2022 22:04:47 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v5] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 18:55:50 GMT, Mat Carter wrote: >> On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. >> >> "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc >> >> No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode >> >> Tested on windows, passes tier1 and tier2 tests > > Mat Carter has updated the pull request incrementally with one additional commit since the last revision: > > Add test from wangweij test/jdk/sun/security/mscapi/AllTypes.java line 60: > 58: return true; > 59: } catch (IOException ioe) { > 60: if (ioe.getMessage().trim().endsWith("java.security.KeyStoreException: Access is denied.")) { Could the message be different if the system language is not English? ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From valeriep at openjdk.java.net Tue May 10 22:07:45 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 10 May 2022 22:07:45 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v2] In-Reply-To: References: Message-ID: <4QHBLaCQz2i2Kl70pIMxmSNsIQTalc-CWJHDLcAT3OA=.0d78a334-6766-4003-9ba1-7efd20aaa814@github.com> On Tue, 10 May 2022 00:09:16 GMT, Weijun Wang wrote: >> Oh, the comment about "may be 0" is meant toward the pbeKey.getInterationCount() call... Hmm, I will make it clearer. > > I see. Another question, shall we reset `salt` and `iCount` at the beginning? If `params` is null and `key` is not `PBEKey` and there is an existing positive `iCount`, it will not be set to `DEFAULT_COUNT`. Yeah, I see PKCS12PBECipherCore does that. Will update PBES2Core with it too. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From xuelei at openjdk.java.net Tue May 10 22:07:47 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 10 May 2022 22:07:47 GMT Subject: RFR: 8286423: Destroy password protection in the example code in KeyStore [v2] In-Reply-To: <6jxClfPxpFrwWpPJG06sK5mEfNq8PE17eSMCppxiTK0=.58e07c78-0ba7-47f0-8893-8bb87adb7231@github.com> References: <6jxClfPxpFrwWpPJG06sK5mEfNq8PE17eSMCppxiTK0=.58e07c78-0ba7-47f0-8893-8bb87adb7231@github.com> Message-ID: > Hi, > > May I have this simple example update in the KeyStore specification? > > Password protection should be destroyed in the example code in KeyStore specification. Otherwise, applications may just copy and past the code, and forget to clean up password protection. > > It's a trivial update, and may not worthy of a CSR. But please let me know if you would like to have a CSR filed. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Use PasswordProtection ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8623/files - new: https://git.openjdk.java.net/jdk/pull/8623/files/12c745d9..e0bd03d0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8623&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8623&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8623.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8623/head:pull/8623 PR: https://git.openjdk.java.net/jdk/pull/8623 From xuelei at openjdk.java.net Tue May 10 22:07:48 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 10 May 2022 22:07:48 GMT Subject: RFR: 8286423: Destroy password protection in the example code in KeyStore [v2] In-Reply-To: <23aXdnh3_mKt3MEI_FPnhhwve4re9PT3wiZYG4QVoy8=.8c521c4a-124a-414d-bdeb-0d3fa5381853@github.com> References: <6jxClfPxpFrwWpPJG06sK5mEfNq8PE17eSMCppxiTK0=.58e07c78-0ba7-47f0-8893-8bb87adb7231@github.com> <23aXdnh3_mKt3MEI_FPnhhwve4re9PT3wiZYG4QVoy8=.8c521c4a-124a-414d-bdeb-0d3fa5381853@github.com> Message-ID: On Tue, 10 May 2022 13:36:19 GMT, Weijun Wang wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Use PasswordProtection > > src/java.base/share/classes/java/security/KeyStore.java line 165: > >> 163: * } >> 164: * } finally { >> 165: * protParam.destroy(); > > `KeyStore.ProtectionParameter` does not have a `destroy` method. Only `PasswordProtection` does. Oops, I tried to check but finally forgot about it. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8623 From weijun at openjdk.java.net Tue May 10 22:13:48 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 10 May 2022 22:13:48 GMT Subject: RFR: 8286423: Destroy password protection in the example code in KeyStore [v2] In-Reply-To: References: <6jxClfPxpFrwWpPJG06sK5mEfNq8PE17eSMCppxiTK0=.58e07c78-0ba7-47f0-8893-8bb87adb7231@github.com> Message-ID: On Tue, 10 May 2022 22:07:47 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this simple example update in the KeyStore specification? >> >> Password protection should be destroyed in the example code in KeyStore specification. Otherwise, applications may just copy and past the code, and forget to clean up password protection. >> >> It's a trivial update, and may not worthy of a CSR. But please let me know if you would like to have a CSR filed. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Use PasswordProtection Approved. Although that `mySecretKey` is out of nowhere, but this is just example code. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8623 From weijun at openjdk.java.net Tue May 10 22:13:48 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 10 May 2022 22:13:48 GMT Subject: RFR: 8286423: Destroy password protection in the example code in KeyStore [v2] In-Reply-To: References: <6jxClfPxpFrwWpPJG06sK5mEfNq8PE17eSMCppxiTK0=.58e07c78-0ba7-47f0-8893-8bb87adb7231@github.com> <23aXdnh3_mKt3MEI_FPnhhwve4re9PT3wiZYG4QVoy8=.8c521c4a-124a-414d-bdeb-0d3fa5381853@github.com> Message-ID: On Tue, 10 May 2022 22:03:19 GMT, Xue-Lei Andrew Fan wrote: >> src/java.base/share/classes/java/security/KeyStore.java line 165: >> >>> 163: * } >>> 164: * } finally { >>> 165: * protParam.destroy(); >> >> `KeyStore.ProtectionParameter` does not have a `destroy` method. Only `PasswordProtection` does. > > Oops, I tried to check but finally forgot about it. Thanks! It's probably better to convert these long example code to snippets, maybe next time. ------------- PR: https://git.openjdk.java.net/jdk/pull/8623 From xuelei at openjdk.java.net Tue May 10 22:16:47 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 10 May 2022 22:16:47 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base In-Reply-To: References: Message-ID: <7lDCcjqL3nlin4_E8rebEkaoQ96_Tz2jbarFVJVF3PY=.88a6da8e-6f79-4889-88f3-4248037609e1@github.com> On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs wrote: > PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." > > This PR anticipates the warnings and adds explicit casts to replace the implicit casts. > In most cases, the cast matches the type of the right-hand side to type of the compound assignment. > Since these casts are truncating the value, there might be a different refactoring that avoids the cast > but a direct replacement was chosen here. > > (Advise and suggestions will inform similar updates to other OpenJDK modules). The update in security area looks good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8642 From valeriep at openjdk.java.net Tue May 10 22:29:44 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 10 May 2022 22:29:44 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v4] In-Reply-To: References: Message-ID: > This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Address review feedbacks ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8521/files - new: https://git.openjdk.java.net/jdk/pull/8521/files/307d2765..0907114b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=02-03 Stats: 63 lines in 2 files changed: 5 ins; 5 del; 53 mod Patch: https://git.openjdk.java.net/jdk/pull/8521.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8521/head:pull/8521 PR: https://git.openjdk.java.net/jdk/pull/8521 From bpb at openjdk.java.net Tue May 10 22:57:49 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 10 May 2022 22:57:49 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base In-Reply-To: References: Message-ID: <7I3Y3hwAO8Sirtab0JkW7SPyjqZlDAhGciKVD47qXOE=.22ddd9bd-1491-4b39-94ed-de1977181c1f@github.com> On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs wrote: > PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." > > This PR anticipates the warnings and adds explicit casts to replace the implicit casts. > In most cases, the cast matches the type of the right-hand side to type of the compound assignment. > Since these casts are truncating the value, there might be a different refactoring that avoids the cast > but a direct replacement was chosen here. > > (Advise and suggestions will inform similar updates to other OpenJDK modules). IO, math, and NIO changes look fine. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8642 From rriggs at openjdk.java.net Tue May 10 23:01:33 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 10 May 2022 23:01:33 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v2] In-Reply-To: References: Message-ID: > PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." > > This PR anticipates the warnings and adds explicit casts to replace the implicit casts. > In most cases, the cast matches the type of the right-hand side to type of the compound assignment. > Since these casts are truncating the value, there might be a different refactoring that avoids the cast > but a direct replacement was chosen here. > > (Advise and suggestions will inform similar updates to other OpenJDK modules). Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: remove stray file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8642/files - new: https://git.openjdk.java.net/jdk/pull/8642/files/e72ce85c..7ff806a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8642.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8642/head:pull/8642 PR: https://git.openjdk.java.net/jdk/pull/8642 From duke at openjdk.java.net Tue May 10 23:21:48 2022 From: duke at openjdk.java.net (Mat Carter) Date: Tue, 10 May 2022 23:21:48 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v5] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 22:01:16 GMT, Weijun Wang wrote: >> Mat Carter has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test from wangweij > > test/jdk/sun/security/mscapi/AllTypes.java line 60: > >> 58: return true; >> 59: } catch (IOException ioe) { >> 60: if (ioe.getMessage().trim().endsWith("java.security.KeyStoreException: Access is denied.")) { > > Could the message be different if the system language is not English? I checked the API and its not guaranteed to be English. I'm investigating a better method for detecting admin rights ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Tue May 10 23:43:50 2022 From: duke at openjdk.java.net (Mark Powers) Date: Tue, 10 May 2022 23:43:50 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> Message-ID: <3fC2CcoKgf_ux4zmAYxkMlZqFTxsp8BShZMjUtXmsl8=.509c28c2-7431-40da-a986-0d2d0957cfb8@github.com> On Fri, 29 Apr 2022 03:58:57 GMT, Anthony Scarpino wrote: > Hi, > > I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation > > The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision. > > Tony I don't yet count as a reviewer, but your changes look good to me. You might want to let IntelliJ check for problems before you integrate. ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From valeriep at openjdk.java.net Wed May 11 00:20:47 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 11 May 2022 00:20:47 GMT Subject: RFR: 8286428: AlgorithmId should understand PBES2 In-Reply-To: <4gme7URJVgzZQCxSXT68oLO6xmuo9bYbX1xnEc_z3-s=.1e1771b6-2bab-4788-8fea-24e6f4f32387@github.com> References: <4gme7URJVgzZQCxSXT68oLO6xmuo9bYbX1xnEc_z3-s=.1e1771b6-2bab-4788-8fea-24e6f4f32387@github.com> Message-ID: On Mon, 9 May 2022 21:44:10 GMT, Weijun Wang wrote: > `AlgorithmId.getName` is updated for PBES2 algorithm identifiers so it directly returns the standard algorithm defined by Java (Ex: `PBEWithHmacSHA256AndAES_256`), instead of a simple "PBES2". > > Please note I specifically update the javadoc for this method to clarify that this name is meant to be a name that's recognized by various `getInstance()` methods. This is how we are actually using this method. > > After this change, the `javax.crypto.EncryptedPrivateKeyInfo` API automatically works with PBES2 encrypted data. As the spec of its `getAlgName()` methods says, "Standard name is returned". This is shown by the newly include regression test. > > Existing security-related tests run fine. Marked as reviewed by valeriep (Reviewer). Changes looks fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/8615 From wetmore at openjdk.java.net Wed May 11 00:43:48 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 11 May 2022 00:43:48 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> Message-ID: On Fri, 29 Apr 2022 03:58:57 GMT, Anthony Scarpino wrote: > Hi, > > I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation > > The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision. > > Tony Finished the SSLEngine/tests, starting on the SSLCipher. Here's the notes so far. test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 1: > 1: /* Wondering why this is in javax/net/ssl/SSLSession instead of sun/security/ssl/SSLCipher. test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 51: > 49: public class ReadOnlyEngine { > 50: > 51: private static String pathToStores = "../etc"; These 6 can be final if you want. test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 96: > 94: status = engine.getHandshakeStatus(); > 95: break; > 96: case FINISHED: Can combine FINISHED/NOT_HANDSHAKING? test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 157: > 155: // Do TLS handshake > 156: do { > 157: statusClient = doHandshake(client, out, in); It's potentially a little inefficient returning after each wrap/unwrap() instead of doing the task right away, but it works. No need to change. Is this style something you copied from another test? The SSLEngineTemplate in the templates directory is what I often use. test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 160: > 158: statusServer = doHandshake(server, in, out); > 159: } while (statusClient != HandshakeStatus.NOT_HANDSHAKING || > 160: statusServer != HandshakeStatus.NOT_HANDSHAKING); Minor indent problem. test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 162: > 160: statusServer != HandshakeStatus.NOT_HANDSHAKING); > 161: > 162: // Read NST What is NST? test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 172: > 170: out.clear(); > 171: String testString = "ASDF"; > 172: in.put(testString.getBytes()).flip(); If you're going to convert back from UTF_8 later, you should probably convert using getBytes(UTF_8) here. test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 188: > 186: in.clear(); > 187: System.out.println("2: Server send: " + testString); > 188: in.put(testString.getBytes()).flip(); Same test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 189: > 187: System.out.println("2: Server send: " + testString); > 188: in.put(testString.getBytes()).flip(); > 189: send(server, in, out); Did you want to try asReadOnlyBuffer() here also? test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 191: > 189: send(server, in, out); > 190: in.clear(); > 191: receive(client, out, in); And here? ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From valeriep at openjdk.java.net Wed May 11 01:17:38 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 11 May 2022 01:17:38 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 02:27:13 GMT, Weijun Wang wrote: >> Currently, the specified CipherSpi object is one of RC4, RC2, DESede. The "else" part is for catching new PKCS12 PBE algorithms support which uses other cipher algorithms. >> CipherSpi.engineInit(...) is protected, so that's why we use the instanceof to cast the CipherSpi object into the actual impl class in order to call the engineInit(...) since the actual impl class is in the same package of this class. > > The `core.init(..., cipher)` is actually `cipher.init(core.translateKeyAndParams())`. Is it possible we write it this way? It's possible, more refactoring would be needed and not necessarily less lines of code. With your suggested change, the caller has to explicitly destroy the derived key after the cipher.engineInit() call. This would be repeated in all PKCS12 PBE cipher impl classes, but then there'd be no casting of the actual classes. I assume this is what you are referring to? Can code it out and see how it looks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From wetmore at openjdk.java.net Wed May 11 01:19:52 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 11 May 2022 01:19:52 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> Message-ID: On Fri, 29 Apr 2022 03:58:57 GMT, Anthony Scarpino wrote: > Hi, > > I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation > > The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision. > > Tony All of the comments observed are minor. Please consider some of the test changes, but otherwise looks good. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8462 From weijun at openjdk.java.net Wed May 11 04:08:50 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 11 May 2022 04:08:50 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 01:14:00 GMT, Valerie Peng wrote: >> The `core.init(..., cipher)` is actually `cipher.init(core.translateKeyAndParams())`. Is it possible we write it this way? > > It's possible, more refactoring would be needed and not necessarily less lines of code. With your suggested change, the caller has to explicitly destroy the derived key after the cipher.engineInit() call. This would be repeated in all PKCS12 PBE cipher impl classes, but then there'd be no casting of the actual classes. I assume this is what you are referring to? Can code it out and see how it looks. If the returned key-and-iv class implements Closeable, then you can do a try-with-resources to destroy the key, which saves you more lines. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From alanb at openjdk.java.net Wed May 11 05:26:39 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 May 2022 05:26:39 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." >> >> This PR anticipates the warnings and adds explicit casts to replace the implicit casts. >> In most cases, the cast matches the type of the right-hand side to type of the compound assignment. >> Since these casts are truncating the value, there might be a different refactoring that avoids the cast >> but a direct replacement was chosen here. >> >> (Advise and suggestions will inform similar updates to other OpenJDK modules). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > remove stray file src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128: > 126: // timed poll interrupted so need to adjust timeout > 127: long adjust = System.nanoTime() - startTime; > 128: to -= (int)TimeUnit.MILLISECONDS.convert(adjust, TimeUnit.NANOSECONDS); Can we change this `to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);` while we here? src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java line 615: > 613: if (outputStackTop >= elements) { > 614: outputStackTop -= (short)elements; > 615: } else { I think we usually try to avoid changing the ASM code if possible but maybe you have to do this because the compiler option is used for compiling java.base? src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java line 123: > 121: // timed poll interrupted so need to adjust timeout > 122: long adjust = System.nanoTime() - startTime; > 123: to -= (int)TimeUnit.MILLISECONDS.convert(adjust, TimeUnit.NANOSECONDS); This one can also be changed to: `to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);` ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From xuelei at openjdk.java.net Wed May 11 05:53:21 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 11 May 2022 05:53:21 GMT Subject: RFR: 8286423: Destroy password protection in the example code in KeyStore [v3] In-Reply-To: <6jxClfPxpFrwWpPJG06sK5mEfNq8PE17eSMCppxiTK0=.58e07c78-0ba7-47f0-8893-8bb87adb7231@github.com> References: <6jxClfPxpFrwWpPJG06sK5mEfNq8PE17eSMCppxiTK0=.58e07c78-0ba7-47f0-8893-8bb87adb7231@github.com> Message-ID: <-iZmkWtI56CGZ_KatM9DlxYxl6T3xTMVkT_-ASGe1cQ=.cdbcdff5-6f3d-4a63-9cc3-5ac508bcb41c@github.com> > Hi, > > May I have this simple example update in the KeyStore specification? > > Password protection should be destroyed in the example code in KeyStore specification. Otherwise, applications may just copy and past the code, and forget to clean up password protection. > > It's a trivial update, and may not worthy of a CSR. But please let me know if you would like to have a CSR filed. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: More udapte ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8623/files - new: https://git.openjdk.java.net/jdk/pull/8623/files/e0bd03d0..442c1fda Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8623&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8623&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8623.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8623/head:pull/8623 PR: https://git.openjdk.java.net/jdk/pull/8623 From xuelei at openjdk.java.net Wed May 11 05:53:21 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 11 May 2022 05:53:21 GMT Subject: RFR: 8286423: Destroy password protection in the example code in KeyStore [v3] In-Reply-To: References: <6jxClfPxpFrwWpPJG06sK5mEfNq8PE17eSMCppxiTK0=.58e07c78-0ba7-47f0-8893-8bb87adb7231@github.com> <23aXdnh3_mKt3MEI_FPnhhwve4re9PT3wiZYG4QVoy8=.8c521c4a-124a-414d-bdeb-0d3fa5381853@github.com> Message-ID: On Tue, 10 May 2022 22:09:14 GMT, Weijun Wang wrote: >> Oops, I tried to check but finally forgot about it. Thanks! > > It's probably better to convert these long example code to snippets, maybe next time. The length is a little bit long, but it is fine to me. It may be nice to revise the example and description, but let's do it later. I modified the example by using one try clause only. ------------- PR: https://git.openjdk.java.net/jdk/pull/8623 From xuelei at openjdk.java.net Wed May 11 05:55:38 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 11 May 2022 05:55:38 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> Message-ID: On Fri, 29 Apr 2022 03:58:57 GMT, Anthony Scarpino wrote: > Hi, > > I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation > > The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision. > > Tony src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 677: > 675: * @see #unwrap(ByteBuffer, ByteBuffer[], int, int) > 676: * > 677: * @implNote The data in {@code src} may be modified during the decryption It looks like a note for the API users to me. Is apiNote tag more appropriate here? ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From asotona at openjdk.java.net Wed May 11 08:06:39 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Wed, 11 May 2022 08:06:39 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." >> >> This PR anticipates the warnings and adds explicit casts to replace the implicit casts. >> In most cases, the cast matches the type of the right-hand side to type of the compound assignment. >> Since these casts are truncating the value, there might be a different refactoring that avoids the cast >> but a direct replacement was chosen here. >> >> (Advise and suggestions will inform similar updates to other OpenJDK modules). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > remove stray file I can confirm this patch clears all warnings from java.base. ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From weijun at openjdk.java.net Wed May 11 13:03:50 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 11 May 2022 13:03:50 GMT Subject: RFR: 8286423: Destroy password protection in the example code in KeyStore [v3] In-Reply-To: <-iZmkWtI56CGZ_KatM9DlxYxl6T3xTMVkT_-ASGe1cQ=.cdbcdff5-6f3d-4a63-9cc3-5ac508bcb41c@github.com> References: <6jxClfPxpFrwWpPJG06sK5mEfNq8PE17eSMCppxiTK0=.58e07c78-0ba7-47f0-8893-8bb87adb7231@github.com> <-iZmkWtI56CGZ_KatM9DlxYxl6T3xTMVkT_-ASGe1cQ=.cdbcdff5-6f3d-4a63-9cc3-5ac508bcb41c@github.com> Message-ID: On Wed, 11 May 2022 05:53:21 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this simple example update in the KeyStore specification? >> >> Password protection should be destroyed in the example code in KeyStore specification. Otherwise, applications may just copy and past the code, and forget to clean up password protection. >> >> It's a trivial update, and may not worthy of a CSR. But please let me know if you would like to have a CSR filed. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > More udapte Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8623 From redestad at openjdk.java.net Wed May 11 15:04:21 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 May 2022 15:04:21 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks Message-ID: #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). ------------- Commit messages: - 8286401: Address possibly lossy conversions in Microbenchmarks Changes: https://git.openjdk.java.net/jdk/pull/8654/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8654&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286401 Stats: 166 lines in 12 files changed: 0 ins; 0 del; 166 mod Patch: https://git.openjdk.java.net/jdk/pull/8654.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8654/head:pull/8654 PR: https://git.openjdk.java.net/jdk/pull/8654 From shade at openjdk.java.net Wed May 11 15:26:45 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 May 2022 15:26:45 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:57:16 GMT, Claes Redestad wrote: > #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. > > I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). I have questions. Also, copyright dates are not consistently updated in affected files? test/micro/org/openjdk/bench/vm/compiler/PointerBenchmarkFlat.java line 151: > 149: int sum = 0; > 150: for (int i = 0 ; i < ELEM_SIZE ; i++) { > 151: sum += (int)ptr_ptr.get(i).address().toRawLongValue(); Here and later: `toRawLongValue` returns `long`, right? So why don't we change the accumulator and return value to `long`, like we do in other tests? ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From redestad at openjdk.java.net Wed May 11 15:50:40 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 May 2022 15:50:40 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: > #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. > > I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Copyrights, consistently use the exact accumulator type ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8654/files - new: https://git.openjdk.java.net/jdk/pull/8654/files/5cba7820..41f37a25 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8654&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8654&range=00-01 Stats: 17 lines in 11 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/8654.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8654/head:pull/8654 PR: https://git.openjdk.java.net/jdk/pull/8654 From shade at openjdk.java.net Wed May 11 15:50:40 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 May 2022 15:50:40 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:47:29 GMT, Claes Redestad wrote: >> #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. >> >> I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Copyrights, consistently use the exact accumulator type Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From redestad at openjdk.java.net Wed May 11 15:50:41 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 May 2022 15:50:41 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:21:51 GMT, Aleksey Shipilev wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyrights, consistently use the exact accumulator type > > test/micro/org/openjdk/bench/vm/compiler/PointerBenchmarkFlat.java line 151: > >> 149: int sum = 0; >> 150: for (int i = 0 ; i < ELEM_SIZE ; i++) { >> 151: sum += (int)ptr_ptr.get(i).address().toRawLongValue(); > > Here and later: `toRawLongValue` returns `long`, right? So why don't we change the accumulator and return value to `long`, like we do in other tests? Yeah, let's be consistent. I have verified that this does not affect the raw scores of these benchmarks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From duke at openjdk.java.net Wed May 11 16:01:39 2022 From: duke at openjdk.java.net (Mat Carter) Date: Wed, 11 May 2022 16:01:39 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v6] In-Reply-To: References: Message-ID: > On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. > > "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc > > No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode > > Tested on windows, passes tier1 and tier2 tests Mat Carter has updated the pull request incrementally with one additional commit since the last revision: Change admin privilege test to reliable method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8211/files - new: https://git.openjdk.java.net/jdk/pull/8211/files/985378fb..6c1f181b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8211&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8211&range=04-05 Stats: 15 lines in 1 file changed: 1 ins; 1 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8211.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8211/head:pull/8211 PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Wed May 11 16:01:40 2022 From: duke at openjdk.java.net (Mat Carter) Date: Wed, 11 May 2022 16:01:40 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v5] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 18:55:50 GMT, Mat Carter wrote: >> On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. >> >> "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc >> >> No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode >> >> Tested on windows, passes tier1 and tier2 tests > > Mat Carter has updated the pull request incrementally with one additional commit since the last revision: > > Add test from wangweij @christophbrejla - my goal is to backport to latest (18 or 19), 17 and 11 ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Wed May 11 16:01:40 2022 From: duke at openjdk.java.net (Mat Carter) Date: Wed, 11 May 2022 16:01:40 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v5] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 23:17:54 GMT, Mat Carter wrote: >> test/jdk/sun/security/mscapi/AllTypes.java line 60: >> >>> 58: return true; >>> 59: } catch (IOException ioe) { >>> 60: if (ioe.getMessage().trim().endsWith("java.security.KeyStoreException: Access is denied.")) { >> >> Could the message be different if the system language is not English? > > I checked the API and its not guaranteed to be English. I'm investigating a better method for detecting admin rights Updated admin privilege test to more reliable method that does not rely on string parsing and thus not susceptible to locale issues ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From redestad at openjdk.java.net Wed May 11 16:03:49 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 May 2022 16:03:49 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:50:40 GMT, Claes Redestad wrote: >> #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. >> >> I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Copyrights, consistently use the exact accumulator type Thanks for reviewing. I'll let the GHA tests complete and integrate this tomorrow if all is clear. ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From coffeys at openjdk.java.net Wed May 11 16:05:54 2022 From: coffeys at openjdk.java.net (Sean Coffey) Date: Wed, 11 May 2022 16:05:54 GMT Subject: RFR: 8286433: Cache certificates decoded from TLS session tickets In-Reply-To: <6zuDRK0GQOkGXEtOmQrutFPUikMR-5aO02hp8Pl9Q4k=.0225a452-6a3f-47d5-9471-cd4ee82afc37@github.com> References: <6zuDRK0GQOkGXEtOmQrutFPUikMR-5aO02hp8Pl9Q4k=.0225a452-6a3f-47d5-9471-cd4ee82afc37@github.com> Message-ID: On Mon, 9 May 2022 19:38:36 GMT, Daniel Jeli?ski wrote: > When a TLS server resumes a session from a stateless session ticket, it populates the `SSLSessionImpl`'s `localCerts` and `peerCerts` fields with certificates deserialized from the session ticket. These certificates are often the same across a large number of tickets. > > This patch implements a certificate cache lookup for these certificates. This enables us to avoid deserializing the same certificates repeatedly, and saves memory by reusing the same certificate objects. Nice work. LGTM. ------------- Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8608 From ecaspole at openjdk.java.net Wed May 11 16:18:52 2022 From: ecaspole at openjdk.java.net (Eric Caspole) Date: Wed, 11 May 2022 16:18:52 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:50:40 GMT, Claes Redestad wrote: >> #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. >> >> I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Copyrights, consistently use the exact accumulator type Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From rriggs at openjdk.java.net Wed May 11 16:30:41 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 11 May 2022 16:30:41 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3] In-Reply-To: References: Message-ID: > PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." > > This PR anticipates the warnings and adds explicit casts to replace the implicit casts. > In most cases, the cast matches the type of the right-hand side to type of the compound assignment. > Since these casts are truncating the value, there might be a different refactoring that avoids the cast > but a direct replacement was chosen here. > > (Advise and suggestions will inform similar updates to other OpenJDK modules). Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Updated copyrights Fixed cast style to add a space after cast, (where consistent with file style) Improved code per review comments in PollSelectors. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8642/files - new: https://git.openjdk.java.net/jdk/pull/8642/files/7ff806a5..a6679ce7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=01-02 Stats: 41 lines in 24 files changed: 0 ins; 0 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/8642.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8642/head:pull/8642 PR: https://git.openjdk.java.net/jdk/pull/8642 From ecaspole at openjdk.java.net Wed May 11 16:38:51 2022 From: ecaspole at openjdk.java.net (Eric Caspole) Date: Wed, 11 May 2022 16:38:51 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: <6v98y-ilQDIQiWxh_Cq_tiKszBQS8GjJ0oPMlc8W_GI=.59ad3686-d1aa-4b0b-b742-33e83c7fb795@github.com> On Wed, 11 May 2022 15:50:40 GMT, Claes Redestad wrote: >> #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. >> >> I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Copyrights, consistently use the exact accumulator type Looks good, thanks for fixing this. ------------- Marked as reviewed by ecaspole (Committer). PR: https://git.openjdk.java.net/jdk/pull/8654 From shade at openjdk.java.net Wed May 11 16:42:47 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 May 2022 16:42:47 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:00:42 GMT, Claes Redestad wrote: > Thanks for reviewing. I'll let the GHA tests complete and integrate this tomorrow if all is clear. I don't think GHA builds any microbenchmarks (because JMH is not enabled there), so there is no point to wait for those. ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From bpb at openjdk.java.net Wed May 11 17:11:46 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 11 May 2022 17:11:46 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." >> >> This PR anticipates the warnings and adds explicit casts to replace the implicit casts. >> In most cases, the cast matches the type of the right-hand side to type of the compound assignment. >> Since these casts are truncating the value, there might be a different refactoring that avoids the cast >> but a direct replacement was chosen here. >> >> (Advise and suggestions will inform similar updates to other OpenJDK modules). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyrights > Fixed cast style to add a space after cast, (where consistent with file style) > Improved code per review comments in PollSelectors. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From alanb at openjdk.java.net Wed May 11 19:10:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 May 2022 19:10:45 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." >> >> This PR anticipates the warnings and adds explicit casts to replace the implicit casts. >> In most cases, the cast matches the type of the right-hand side to type of the compound assignment. >> Since these casts are truncating the value, there might be a different refactoring that avoids the cast >> but a direct replacement was chosen here. >> >> (Advise and suggestions will inform similar updates to other OpenJDK modules). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyrights > Fixed cast style to add a space after cast, (where consistent with file style) > Improved code per review comments in PollSelectors. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From valeriep at openjdk.java.net Wed May 11 20:34:40 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 11 May 2022 20:34:40 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 04:05:27 GMT, Weijun Wang wrote: >> It's possible, more refactoring would be needed and not necessarily less lines of code. With your suggested change, the caller has to explicitly destroy the derived key after the cipher.engineInit() call. This would be repeated in all PKCS12 PBE cipher impl classes, but then there'd be no casting of the actual classes. I assume this is what you are referring to? Can code it out and see how it looks. > > If the returned key-and-iv class implements Closeable, then you can do a try-with-resources to destroy the key, which saves you more lines. Yes, good point, will do so. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From redestad at openjdk.java.net Wed May 11 20:54:50 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 May 2022 20:54:50 GMT Subject: RFR: 8286401: Address possibly lossy conversions in Microbenchmarks [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:39:18 GMT, Aleksey Shipilev wrote: > > Thanks for reviewing. I'll let the GHA tests complete and integrate this tomorrow if all is clear. > > I don't think GHA builds any microbenchmarks (because JMH is not enabled there), so there is no point to wait for those. Good to know, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From redestad at openjdk.java.net Wed May 11 20:54:53 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 May 2022 20:54:53 GMT Subject: Integrated: 8286401: Address possibly lossy conversions in Microbenchmarks In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:57:16 GMT, Claes Redestad wrote: > #8599 would add a new warning. This address the conversions in the microbenchmark component by means of making the types precise or adding explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but the real change is in the template as these are generated. > > I've run through a subset of the affected benchmarks and verified that the results are either neutral or improve somewhat (seem to be the case in a few of the ByteBuffer micros). This pull request has now been integrated. Changeset: 1586bf86 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/1586bf862b6faa6477630fad2e62b198771ad187 Stats: 179 lines in 13 files changed: 0 ins; 0 del; 179 mod 8286401: Address possibly lossy conversions in Microbenchmarks Reviewed-by: shade, ecaspole ------------- PR: https://git.openjdk.java.net/jdk/pull/8654 From weijun at openjdk.java.net Wed May 11 22:02:31 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 11 May 2022 22:02:31 GMT Subject: RFR: 8284194: Allow empty subject fields in keytool Message-ID: This code change allows one entering "." at a distinguished name prompt to skip a sub-component when running `keytool -genkeyapir`. Several new resource strings are added. There is no detailed description in `keytool.html`, so I think there's no need to update it. I'll file a CSR to describe the behavior change. Here is an example after this change: $ keytool -genkeypair -keystore ks -storepass changeit -alias b -keyalg EC Enter the distinguished name. Enter a single dot (.) to leave the sub-component empty. What is your first and last name? [Unknown]: . What is the name of your organizational unit? [Unknown]: . What is the name of your organization? [Unknown]: . What is the name of your City or Locality? [Unknown]: . What is the name of your State or Province? [Unknown]: . What is the two-letter country code for this unit? [Unknown]: . At least one field must be provided. Enter again. Enter the distinguished name. Enter a single dot (.) to leave the sub-component empty. What is your first and last name? [EMPTY]: Duke What is the name of your organizational unit? [EMPTY]: What is the name of your organization? [EMPTY]: What is the name of your City or Locality? [EMPTY]: What is the name of your State or Province? [EMPTY]: What is the two-letter country code for this unit? [EMPTY]: Is CN=Duke correct? [no]: yes Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days for: CN=Duke In the first round, "." is entered for all fields and keytool rejected it. In the second round, CN is entered but the others are unchanged (just type enter, because they are already entered previously). At the end, the name is "CN=Duke". ------------- Commit messages: - the fix Changes: https://git.openjdk.java.net/jdk/pull/8667/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8667&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284194 Stats: 128 lines in 4 files changed: 91 ins; 3 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/8667.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8667/head:pull/8667 PR: https://git.openjdk.java.net/jdk/pull/8667 From valeriep at openjdk.java.net Wed May 11 22:02:42 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 11 May 2022 22:02:42 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v5] In-Reply-To: References: Message-ID: > This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Changed to extend various CipherSpi implementations. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8521/files - new: https://git.openjdk.java.net/jdk/pull/8521/files/0907114b..39f626e1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=03-04 Stats: 255 lines in 4 files changed: 63 ins; 145 del; 47 mod Patch: https://git.openjdk.java.net/jdk/pull/8521.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8521/head:pull/8521 PR: https://git.openjdk.java.net/jdk/pull/8521 From valeriep at openjdk.java.net Wed May 11 22:17:05 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 11 May 2022 22:17:05 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v4] In-Reply-To: <3PhZPgbMppa_YVJ8GECtwlIHcn2rFZSaYJLmA1BsyL8=.05b69ecd-5bac-48c2-a4c3-5d16f1ef27bb@github.com> References: <3PhZPgbMppa_YVJ8GECtwlIHcn2rFZSaYJLmA1BsyL8=.05b69ecd-5bac-48c2-a4c3-5d16f1ef27bb@github.com> Message-ID: On Tue, 10 May 2022 20:42:55 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8253176 >> - Sync'ed w/ the wording in the other Cipher.getParameters() PR. >> - Undo un-intentional changes. >> - 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException > > src/java.base/share/classes/java/security/SignatureSpi.java line 399: > >> 397: * values used by the underlying signature scheme. If the required >> 398: * parameters were not supplied and can be generated by the signature, >> 399: * the generated parameters will be returned. Otherwise, {@code null} > > Minor wording nit - change "will be" to "are" to be consistent with other wording which uses the present tense. Same comment applies to `Signature.getParameters`. > > Also, do we no longer need to mention the part "and the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}"? Fixed the nit. Thanks~ As for the part about returning the parameters as `{@code AlgorithmParameters}`, it should be covered by current sentence, i.e. `and can be generated by the signature`. Perhaps we don't have to spell out all possible causes where the parameter can't be generated? ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From ascarpino at openjdk.java.net Wed May 11 22:28:56 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 11 May 2022 22:28:56 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> Message-ID: On Mon, 9 May 2022 23:15:40 GMT, Bradford Wetmore wrote: >> Hi, >> >> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation >> >> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision. >> >> Tony > > test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 1: > >> 1: /* > > Wondering why this is in javax/net/ssl/SSLSession instead of sun/security/ssl/SSLCipher. I can move it.. I created it from another test which happen to be in that directory ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From valeriep at openjdk.java.net Wed May 11 22:32:43 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 11 May 2022 22:32:43 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v6] In-Reply-To: References: Message-ID: > Anyone can help review this javadoc update? The main change is the wording for the method javadoc of Cipher.getParameters()/CipherSpi.engineGetParameters(). The original wording is somewhat restrictive and request is to broaden this to accommodate more scenarios such as when null can be returned. > The rest are minor things like add {@code } to class name and null, and remove redundant ".". > > Will file CSR after the review is close to being wrapped up. > Thanks~ Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Minor wording changes. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8117/files - new: https://git.openjdk.java.net/jdk/pull/8117/files/f9727edf..10228192 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8117&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8117&range=04-05 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8117.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8117/head:pull/8117 PR: https://git.openjdk.java.net/jdk/pull/8117 From valeriep at openjdk.java.net Wed May 11 22:32:48 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 11 May 2022 22:32:48 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v5] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 20:38:31 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8209038 >> - update to address review feedback and minor javadoc cleanup >> - Update for getParameters() >> - Update w/ review feedbacks >> - 8209038: Clarify the javadoc of Cipher.getParameters() > > src/java.base/share/classes/javax/crypto/CipherSpi.java line 294: > >> 292: * values used by the underlying cipher implementation. If the required >> 293: * parameters were not supplied and can be generated by the cipher, the >> 294: * generated parameters will be returned. Otherwise, {@code null} is > > Minor wording nit - change "will be" to "are" to be consistent with other wording which uses the present tense. Same comment applies to `Cipher.getParameters`. Yes, will fix the nit. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From ascarpino at openjdk.java.net Wed May 11 22:41:47 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 11 May 2022 22:41:47 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> Message-ID: On Mon, 9 May 2022 23:48:24 GMT, Bradford Wetmore wrote: >> Hi, >> >> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation >> >> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision. >> >> Tony > > test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 157: > >> 155: // Do TLS handshake >> 156: do { >> 157: statusClient = doHandshake(client, out, in); > > It's potentially a little inefficient returning after each wrap/unwrap() instead of doing the task right away, but it works. No need to change. > > Is this style something you copied from another test? The SSLEngineTemplate in the templates directory is what I often use. I got it from somewhere that I don't remember off hand. I'm just trying to get through the handshake. > test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 162: > >> 160: statusServer != HandshakeStatus.NOT_HANDSHAKING); >> 161: >> 162: // Read NST > > What is NST? New Session Ticket ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From weijun at openjdk.java.net Wed May 11 22:42:29 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 11 May 2022 22:42:29 GMT Subject: RFR: 8286422: Add OIDs for RC2 and Blowfish Message-ID: Add missing OIDs for 2 secret key algorithms. These will be used when storing secret keys in a PKCS12 keystore. Like DES and DESede, the OIDs were originally defined for CBC mode cipher algorithms, they are reused here for key algorithms. OpenSSL uses the same OIDs for cipher algorithms. 1 3 6 1 4 1 3029 1 2 : BF-CBC : bf-cbc rsadsi 3 2 : RC2-CBC : rc2-cbc Similar to DES, RC2 is only added as an alias so it needs to be specially treated when getting a secret key entry from a PKCS12 keystore. No attempt is made to define these OIDs as aliases to existing cipher algorithms. ------------- Commit messages: - add OIDs Changes: https://git.openjdk.java.net/jdk/pull/8668/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8668&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286422 Stats: 118 lines in 4 files changed: 66 ins; 49 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8668.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8668/head:pull/8668 PR: https://git.openjdk.java.net/jdk/pull/8668 From jnimeh at openjdk.java.net Wed May 11 22:51:49 2022 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Wed, 11 May 2022 22:51:49 GMT Subject: RFR: 8284194: Allow empty subject fields in keytool In-Reply-To: References: Message-ID: On Wed, 11 May 2022 21:55:45 GMT, Weijun Wang wrote: > This code change allows one entering "." at a distinguished name prompt to skip a sub-component when running `keytool -genkeyapir`. Several new resource strings are added. > > There is no detailed description in `keytool.html`, so I think there's no need to update it. > > I'll file a CSR to describe the behavior change. > > Here is an example after this change: > > $ keytool -genkeypair -keystore ks -storepass changeit -alias b -keyalg EC > Enter the distinguished name. Enter a single dot (.) to leave the sub-component empty. > What is your first and last name? > [Unknown]: . > What is the name of your organizational unit? > [Unknown]: . > What is the name of your organization? > [Unknown]: . > What is the name of your City or Locality? > [Unknown]: . > What is the name of your State or Province? > [Unknown]: . > What is the two-letter country code for this unit? > [Unknown]: . > At least one field must be provided. Enter again. > Enter the distinguished name. Enter a single dot (.) to leave the sub-component empty. > What is your first and last name? > [EMPTY]: Duke > What is the name of your organizational unit? > [EMPTY]: > What is the name of your organization? > [EMPTY]: > What is the name of your City or Locality? > [EMPTY]: > What is the name of your State or Province? > [EMPTY]: > What is the two-letter country code for this unit? > [EMPTY]: > Is CN=Duke correct? > [no]: yes > > Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days > for: CN=Duke > > In the first round, "." is entered for all fields and keytool rejected it. In the second round, CN is entered but the others are unchanged (just type enter, because they are already entered previously). At the end, the name is "CN=Duke". Looks pretty solid. Just that one question about how to handle an errant space after the ".". I think it might be fine to treat it literally as a dot-space combo. If it was an error it would be caught by the user most likely at the check at the end of the DN entry loop. src/java.base/share/classes/sun/security/tools/keytool/Main.java line 3781: > 3779: > 3780: private static String dotToNull(String input) { > 3781: return ".".equals(input) ? null : input; Do we deal at all with leading/trailing whitespace (maybe more concerned about trailing whitespace than leading)? What happens if we get a ". " (trailing space)? ------------- PR: https://git.openjdk.java.net/jdk/pull/8667 From ascarpino at openjdk.java.net Wed May 11 22:52:50 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 11 May 2022 22:52:50 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> Message-ID: On Wed, 11 May 2022 05:52:38 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation >> >> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision. >> >> Tony > > src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 677: > >> 675: * @see #unwrap(ByteBuffer, ByteBuffer[], int, int) >> 676: * >> 677: * @implNote The data in {@code src} may be modified during the decryption > > It looks like a note for the API users to me. Is apiNote tag more appropriate here? The CSR and this code is changing, the note I was adding was already documented, but its existing wording should be more clear. ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From jnimeh at openjdk.java.net Wed May 11 22:59:48 2022 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Wed, 11 May 2022 22:59:48 GMT Subject: RFR: 8284194: Allow empty subject fields in keytool In-Reply-To: References: Message-ID: <_qzIInp9rpLTFXYISIDfy_uKoHj5vxyNHIp9shAtSxE=.35f0fd0b-09e3-4fd4-b074-50ece1b9408b@github.com> On Wed, 11 May 2022 21:55:45 GMT, Weijun Wang wrote: > This code change allows one entering "." at a distinguished name prompt to skip a sub-component when running `keytool -genkeyapir`. Several new resource strings are added. > > There is no detailed description in `keytool.html`, so I think there's no need to update it. > > I'll file a CSR to describe the behavior change. > > Here is an example after this change: > > $ keytool -genkeypair -keystore ks -storepass changeit -alias b -keyalg EC > Enter the distinguished name. Enter a single dot (.) to leave the sub-component empty. > What is your first and last name? > [Unknown]: . > What is the name of your organizational unit? > [Unknown]: . > What is the name of your organization? > [Unknown]: . > What is the name of your City or Locality? > [Unknown]: . > What is the name of your State or Province? > [Unknown]: . > What is the two-letter country code for this unit? > [Unknown]: . > At least one field must be provided. Enter again. > Enter the distinguished name. Enter a single dot (.) to leave the sub-component empty. > What is your first and last name? > [EMPTY]: Duke > What is the name of your organizational unit? > [EMPTY]: > What is the name of your organization? > [EMPTY]: > What is the name of your City or Locality? > [EMPTY]: > What is the name of your State or Province? > [EMPTY]: > What is the two-letter country code for this unit? > [EMPTY]: > Is CN=Duke correct? > [no]: yes > > Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days > for: CN=Duke > > In the first round, "." is entered for all fields and keytool rejected it. In the second round, CN is entered but the others are unchanged (just type enter, because they are already entered previously). At the end, the name is "CN=Duke". Marked as reviewed by jnimeh (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8667 From weijun at openjdk.java.net Wed May 11 22:59:48 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 11 May 2022 22:59:48 GMT Subject: RFR: 8284194: Allow empty subject fields in keytool In-Reply-To: References: Message-ID: On Wed, 11 May 2022 22:37:18 GMT, Jamil Nimeh wrote: >> This code change allows one entering "." at a distinguished name prompt to skip a sub-component when running `keytool -genkeyapir`. Several new resource strings are added. >> >> There is no detailed description in `keytool.html`, so I think there's no need to update it. >> >> I'll file a CSR to describe the behavior change. >> >> Here is an example after this change: >> >> $ keytool -genkeypair -keystore ks -storepass changeit -alias b -keyalg EC >> Enter the distinguished name. Enter a single dot (.) to leave the sub-component empty. >> What is your first and last name? >> [Unknown]: . >> What is the name of your organizational unit? >> [Unknown]: . >> What is the name of your organization? >> [Unknown]: . >> What is the name of your City or Locality? >> [Unknown]: . >> What is the name of your State or Province? >> [Unknown]: . >> What is the two-letter country code for this unit? >> [Unknown]: . >> At least one field must be provided. Enter again. >> Enter the distinguished name. Enter a single dot (.) to leave the sub-component empty. >> What is your first and last name? >> [EMPTY]: Duke >> What is the name of your organizational unit? >> [EMPTY]: >> What is the name of your organization? >> [EMPTY]: >> What is the name of your City or Locality? >> [EMPTY]: >> What is the name of your State or Province? >> [EMPTY]: >> What is the two-letter country code for this unit? >> [EMPTY]: >> Is CN=Duke correct? >> [no]: yes >> >> Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days >> for: CN=Duke >> >> In the first round, "." is entered for all fields and keytool rejected it. In the second round, CN is entered but the others are unchanged (just type enter, because they are already entered previously). At the end, the name is "CN=Duke". > > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 3781: > >> 3779: >> 3780: private static String dotToNull(String input) { >> 3781: return ".".equals(input) ? null : input; > > Do we deal at all with leading/trailing whitespace (maybe more concerned about trailing whitespace than leading)? What happens if we get a ". " (trailing space)? The user must be deliberately doing this. Let's respect their decision. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/8667 From hchao at openjdk.java.net Wed May 11 23:05:49 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 11 May 2022 23:05:49 GMT Subject: RFR: 8284194: Allow empty subject fields in keytool In-Reply-To: References: Message-ID: On Wed, 11 May 2022 21:55:45 GMT, Weijun Wang wrote: > This code change allows one entering "." at a distinguished name prompt to skip a sub-component when running `keytool -genkeyapir`. Several new resource strings are added. > > There is no detailed description in `keytool.html`, so I think there's no need to update it. > > I'll file a CSR to describe the behavior change. > > Here is an example after this change: > > $ keytool -genkeypair -keystore ks -storepass changeit -alias b -keyalg EC > Enter the distinguished name. Enter a single dot (.) to leave the sub-component empty. > What is your first and last name? > [Unknown]: . > What is the name of your organizational unit? > [Unknown]: . > What is the name of your organization? > [Unknown]: . > What is the name of your City or Locality? > [Unknown]: . > What is the name of your State or Province? > [Unknown]: . > What is the two-letter country code for this unit? > [Unknown]: . > At least one field must be provided. Enter again. > Enter the distinguished name. Enter a single dot (.) to leave the sub-component empty. > What is your first and last name? > [EMPTY]: Duke > What is the name of your organizational unit? > [EMPTY]: > What is the name of your organization? > [EMPTY]: > What is the name of your City or Locality? > [EMPTY]: > What is the name of your State or Province? > [EMPTY]: > What is the two-letter country code for this unit? > [EMPTY]: > Is CN=Duke correct? > [no]: yes > > Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days > for: CN=Duke > > In the first round, "." is entered for all fields and keytool rejected it. In the second round, CN is entered but the others are unchanged (just type enter, because they are already entered previously). At the end, the name is "CN=Duke". Marked as reviewed by hchao (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8667 From ascarpino at openjdk.java.net Wed May 11 23:07:40 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 11 May 2022 23:07:40 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> Message-ID: On Wed, 11 May 2022 00:31:23 GMT, Bradford Wetmore wrote: >> Hi, >> >> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation >> >> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision. >> >> Tony > > test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 172: > >> 170: out.clear(); >> 171: String testString = "ASDF"; >> 172: in.put(testString.getBytes()).flip(); > > If you're going to convert back from UTF_8 later, you should probably convert using getBytes(UTF_8) here. setting the input to UTF8 isn't a concern. The latter line to decode it changes it from using the ByteBuffer.toString() to the contents of the ByteBuffer in a String. > test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 188: > >> 186: in.clear(); >> 187: System.out.println("2: Server send: " + testString); >> 188: in.put(testString.getBytes()).flip(); > > Same Same :) > test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 189: > >> 187: System.out.println("2: Server send: " + testString); >> 188: in.put(testString.getBytes()).flip(); >> 189: send(server, in, out); > > Did you want to try asReadOnlyBuffer() here also? Yeah, they should have been. I must have undid it to test something > test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 191: > >> 189: send(server, in, out); >> 190: in.clear(); >> 191: receive(client, out, in); > > And here? Same ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From weijun at openjdk.java.net Wed May 11 23:40:46 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 11 May 2022 23:40:46 GMT Subject: RFR: 8284194: Allow empty subject fields in keytool [v2] In-Reply-To: References: Message-ID: > This code change allows one entering "." at a distinguished name prompt to skip a sub-component when running `keytool -genkeyapir`. Several new resource strings are added. > > There is no detailed description in `keytool.html`, so I think there's no need to update it. > > I'll file a CSR to describe the behavior change. > > Here is an example after this change: > > $ keytool -genkeypair -keystore ks -storepass changeit -alias b -keyalg EC > Enter the distinguished name. Enter a single dot (.) to leave the sub-component empty. > What is your first and last name? > [Unknown]: . > What is the name of your organizational unit? > [Unknown]: . > What is the name of your organization? > [Unknown]: . > What is the name of your City or Locality? > [Unknown]: . > What is the name of your State or Province? > [Unknown]: . > What is the two-letter country code for this unit? > [Unknown]: . > At least one field must be provided. Enter again. > Enter the distinguished name. Enter a single dot (.) to leave the sub-component empty. > What is your first and last name? > [EMPTY]: Duke > What is the name of your organizational unit? > [EMPTY]: > What is the name of your organization? > [EMPTY]: > What is the name of your City or Locality? > [EMPTY]: > What is the name of your State or Province? > [EMPTY]: > What is the two-letter country code for this unit? > [EMPTY]: > Is CN=Duke correct? > [no]: yes > > Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days > for: CN=Duke > > In the first round, "." is entered for all fields and keytool rejected it. In the second round, CN is entered but the others are unchanged (just type enter, because they are already entered previously). At the end, the name is "CN=Duke". Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: word change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8667/files - new: https://git.openjdk.java.net/jdk/pull/8667/files/abed47cb..1894055d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8667&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8667&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8667.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8667/head:pull/8667 PR: https://git.openjdk.java.net/jdk/pull/8667 From weijun at openjdk.java.net Wed May 11 23:51:40 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 11 May 2022 23:51:40 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v5] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 22:02:42 GMT, Valerie Peng wrote: >> This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Changed to extend various CipherSpi implementations. src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 171: > 169: > 170: // holder for the derived key and iv > 171: private static class KeyAndIv implements Closeable { You can make this a `record`. src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 317: > 315: Arrays.fill(derivedKey, (byte)0); > 316: > 317: KeyAndIv result; I think the fancy 2022 way is to `return switch (...) { case "RC4" -> new KeyAndIv(...) ... }`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From valeriep at openjdk.java.net Thu May 12 00:21:34 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 12 May 2022 00:21:34 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v5] In-Reply-To: References: Message-ID: > This is to update the method javadoc of java.security.Signature.getParameters() with the missing `@throws UnsupportedOperationException`. In addition, the wording on the returned parameters are updated to match those in Cipher and CipherSpi classes. > > CSR will be filed later. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Minor update. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8396/files - new: https://git.openjdk.java.net/jdk/pull/8396/files/660adeeb..1f02b558 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=03-04 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8396/head:pull/8396 PR: https://git.openjdk.java.net/jdk/pull/8396 From hchao at openjdk.java.net Thu May 12 00:22:00 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 12 May 2022 00:22:00 GMT Subject: RFR: 8286422: Add OIDs for RC2 and Blowfish In-Reply-To: References: Message-ID: On Wed, 11 May 2022 22:35:32 GMT, Weijun Wang wrote: > Add missing OIDs for 2 secret key algorithms. These will be used when storing secret keys in a PKCS12 keystore. Like DES and DESede, the OIDs were originally defined for CBC mode cipher algorithms, they are reused here for key algorithms. > > OpenSSL uses the same OIDs for cipher algorithms. > > 1 3 6 1 4 1 3029 1 2 : BF-CBC : bf-cbc > rsadsi 3 2 : RC2-CBC : rc2-cbc > > > Similar to DES, RC2 is only added as an alias so it needs to be specially treated when getting a secret key entry from a PKCS12 keystore. > > No attempt is made to define these OIDs as aliases to existing cipher algorithms. Marked as reviewed by hchao (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8668 From valeriep at openjdk.java.net Thu May 12 00:46:49 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 12 May 2022 00:46:49 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v5] In-Reply-To: References: Message-ID: <-pja8W9gSHoXZLhjM8wxRu2Iqw_k4Kbcr1rh_uajgi8=.38a727c2-f1cb-4d97-8406-b102df2b4703@github.com> On Thu, 12 May 2022 00:21:34 GMT, Valerie Peng wrote: >> This is to update the method javadoc of java.security.Signature.getParameters() with the missing `@throws UnsupportedOperationException`. In addition, the wording on the returned parameters are updated to match those in Cipher and CipherSpi classes. >> >> CSR will be filed later. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Minor update. CSR filed at https://bugs.openjdk.java.net/browse/JDK-8286616 Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From ascarpino at openjdk.java.net Thu May 12 01:58:03 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 12 May 2022 01:58:03 GMT Subject: RFR: 8286422: Add OIDs for RC2 and Blowfish In-Reply-To: References: Message-ID: On Wed, 11 May 2022 22:35:32 GMT, Weijun Wang wrote: > Add missing OIDs for 2 secret key algorithms. These will be used when storing secret keys in a PKCS12 keystore. Like DES and DESede, the OIDs were originally defined for CBC mode cipher algorithms, they are reused here for key algorithms. > > OpenSSL uses the same OIDs for cipher algorithms. > > 1 3 6 1 4 1 3029 1 2 : BF-CBC : bf-cbc > rsadsi 3 2 : RC2-CBC : rc2-cbc > > > Similar to DES, RC2 is only added as an alias so it needs to be specially treated when getting a secret key entry from a PKCS12 keystore. > > No attempt is made to define these OIDs as aliases to existing cipher algorithms. Marked as reviewed by ascarpino (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8668 From weijun at openjdk.java.net Thu May 12 02:20:43 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 12 May 2022 02:20:43 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v5] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:55:40 GMT, Mat Carter wrote: > @christophbrejla - my goal is to backport to latest (18 or 19), 17 and 11 Then please add the versions to the "Fix Version(s)" field of the CSR. There are also some questions waiting for you in the comment there. ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From valeriep at openjdk.java.net Thu May 12 03:24:32 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 12 May 2022 03:24:32 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v6] In-Reply-To: References: Message-ID: > This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Updated to use record and switch expression. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8521/files - new: https://git.openjdk.java.net/jdk/pull/8521/files/39f626e1..d253f8d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=04-05 Stats: 25 lines in 1 file changed: 0 ins; 13 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/8521.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8521/head:pull/8521 PR: https://git.openjdk.java.net/jdk/pull/8521 From valeriep at openjdk.java.net Thu May 12 03:24:33 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 12 May 2022 03:24:33 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v5] In-Reply-To: References: Message-ID: <-FzV9q9zK-35i-1Q8wYE2mAhF_RdsxJtPVrj81Mi0oA=.dff63c49-17a3-4133-8ed6-f15bb7f41a85@github.com> On Wed, 11 May 2022 23:45:00 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed to extend various CipherSpi implementations. > > src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 171: > >> 169: >> 170: // holder for the derived key and iv >> 171: private static class KeyAndIv implements Closeable { > > You can make this a `record`. Sure, good suggestion~ > src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 317: > >> 315: Arrays.fill(derivedKey, (byte)0); >> 316: >> 317: KeyAndIv result; > > I think the fancy 2022 way is to `return switch (...) { case "RC4" -> new KeyAndIv(...) ... }`. Ok~ ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From valeriep at openjdk.java.net Thu May 12 03:28:15 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 12 May 2022 03:28:15 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v7] In-Reply-To: References: Message-ID: > This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: trivial syntax fix. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8521/files - new: https://git.openjdk.java.net/jdk/pull/8521/files/d253f8d6..c1893f8b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8521.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8521/head:pull/8521 PR: https://git.openjdk.java.net/jdk/pull/8521 From xuelei at openjdk.java.net Thu May 12 04:25:56 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 12 May 2022 04:25:56 GMT Subject: RFR: 8286433: Cache certificates decoded from TLS session tickets In-Reply-To: <6zuDRK0GQOkGXEtOmQrutFPUikMR-5aO02hp8Pl9Q4k=.0225a452-6a3f-47d5-9471-cd4ee82afc37@github.com> References: <6zuDRK0GQOkGXEtOmQrutFPUikMR-5aO02hp8Pl9Q4k=.0225a452-6a3f-47d5-9471-cd4ee82afc37@github.com> Message-ID: On Mon, 9 May 2022 19:38:36 GMT, Daniel Jeli?ski wrote: > When a TLS server resumes a session from a stateless session ticket, it populates the `SSLSessionImpl`'s `localCerts` and `peerCerts` fields with certificates deserialized from the session ticket. These certificates are often the same across a large number of tickets. > > This patch implements a certificate cache lookup for these certificates. This enables us to avoid deserializing the same certificates repeatedly, and saves memory by reusing the same certificate objects. It looks good to me. Thanks! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8608 From xuelei at openjdk.java.net Thu May 12 04:40:49 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 12 May 2022 04:40:49 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> Message-ID: <6oUg2vg_n11wCSlyvzZZtPj8iVTGByT9bMRvYT2wt-o=.2f57f210-0bed-45ab-a5d3-89364496a396@github.com> On Wed, 11 May 2022 22:49:02 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 677: >> >>> 675: * @see #unwrap(ByteBuffer, ByteBuffer[], int, int) >>> 676: * >>> 677: * @implNote The data in {@code src} may be modified during the decryption >> >> It looks like a note for the API users to me. Is apiNote tag more appropriate here? > > The CSR and this code is changing, the note I was adding was already documented, but its existing wording should be more clear. I like the new update as specified in the CSR. I added my name as Reviewer for the CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From djelinski at openjdk.java.net Thu May 12 06:52:56 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 12 May 2022 06:52:56 GMT Subject: Integrated: 8286433: Cache certificates decoded from TLS session tickets In-Reply-To: <6zuDRK0GQOkGXEtOmQrutFPUikMR-5aO02hp8Pl9Q4k=.0225a452-6a3f-47d5-9471-cd4ee82afc37@github.com> References: <6zuDRK0GQOkGXEtOmQrutFPUikMR-5aO02hp8Pl9Q4k=.0225a452-6a3f-47d5-9471-cd4ee82afc37@github.com> Message-ID: <5nKecMYHjmJmmnpFM-qWNNCjT-iSMgOxHwuEMso0JZw=.5eed50db-6cac-4fa2-be9a-7dbba3f71d2e@github.com> On Mon, 9 May 2022 19:38:36 GMT, Daniel Jeli?ski wrote: > When a TLS server resumes a session from a stateless session ticket, it populates the `SSLSessionImpl`'s `localCerts` and `peerCerts` fields with certificates deserialized from the session ticket. These certificates are often the same across a large number of tickets. > > This patch implements a certificate cache lookup for these certificates. This enables us to avoid deserializing the same certificates repeatedly, and saves memory by reusing the same certificate objects. This pull request has now been integrated. Changeset: 96d48f38 Author: Daniel Jeli?ski URL: https://git.openjdk.java.net/jdk/commit/96d48f386b59096c6d1c88c142037c44db5ccacf Stats: 26 lines in 2 files changed: 13 ins; 8 del; 5 mod 8286433: Cache certificates decoded from TLS session tickets Reviewed-by: coffeys, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/8608 From weijun at openjdk.java.net Thu May 12 13:31:02 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 12 May 2022 13:31:02 GMT Subject: Integrated: 8286422: Add OIDs for RC2 and Blowfish In-Reply-To: References: Message-ID: On Wed, 11 May 2022 22:35:32 GMT, Weijun Wang wrote: > Add missing OIDs for 2 secret key algorithms. These will be used when storing secret keys in a PKCS12 keystore. Like DES and DESede, the OIDs were originally defined for CBC mode cipher algorithms, they are reused here for key algorithms. > > OpenSSL uses the same OIDs for cipher algorithms. > > 1 3 6 1 4 1 3029 1 2 : BF-CBC : bf-cbc > rsadsi 3 2 : RC2-CBC : rc2-cbc > > > Similar to DES, RC2 is only added as an alias so it needs to be specially treated when getting a secret key entry from a PKCS12 keystore. > > No attempt is made to define these OIDs as aliases to existing cipher algorithms. This pull request has now been integrated. Changeset: 752ad1c4 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/752ad1c41093645506dd267f618bd46882d0c674 Stats: 118 lines in 4 files changed: 66 ins; 49 del; 3 mod 8286422: Add OIDs for RC2 and Blowfish Reviewed-by: hchao, ascarpino ------------- PR: https://git.openjdk.java.net/jdk/pull/8668 From mullan at openjdk.java.net Thu May 12 13:45:56 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 12 May 2022 13:45:56 GMT Subject: RFR: 8284194: Allow empty subject fields in keytool [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 23:40:46 GMT, Weijun Wang wrote: >> This code change allows one entering "." at a distinguished name prompt to skip a sub-component when running `keytool -genkeyapir`. Several new resource strings are added. >> >> There is no detailed description in `keytool.html`, so I think there's no need to update it. >> >> I'll file a CSR to describe the behavior change. >> >> Here is an example after this change: >> >> $ keytool -genkeypair -keystore ks -storepass changeit -alias b -keyalg EC >> Enter the distinguished name. Enter a single dot (.) to leave the sub-component empty. >> What is your first and last name? >> [Unknown]: . >> What is the name of your organizational unit? >> [Unknown]: . >> What is the name of your organization? >> [Unknown]: . >> What is the name of your City or Locality? >> [Unknown]: . >> What is the name of your State or Province? >> [Unknown]: . >> What is the two-letter country code for this unit? >> [Unknown]: . >> At least one field must be provided. Enter again. >> Enter the distinguished name. Enter a single dot (.) to leave the sub-component empty. >> What is your first and last name? >> [EMPTY]: Duke >> What is the name of your organizational unit? >> [EMPTY]: >> What is the name of your organization? >> [EMPTY]: >> What is the name of your City or Locality? >> [EMPTY]: >> What is the name of your State or Province? >> [EMPTY]: >> What is the two-letter country code for this unit? >> [EMPTY]: >> Is CN=Duke correct? >> [no]: yes >> >> Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days >> for: CN=Duke >> >> In the first round, "." is entered for all fields and keytool rejected it. In the second round, CN is entered but the others are unchanged (just type enter, because they are already entered previously). At the end, the name is "CN=Duke". > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > word change It might also be helpful to note that hitting return or enter will use the default, ex: "Enter a single dot (.) to leave the sub-component empty or enter return to use the default value in braces." For this: > What is your first and last name? > [EMPTY]: Duke I find the word "EMPTY" here a bit confusing because this is not a default value like "Unknown". It seems to me that it might be more intuitive to just repeat the initial set of prompts using [Unknown] and requiring '.' to be entered, especially since you repeat the part "Enter a single dot (.) to leave the sub-component empty." ------------- PR: https://git.openjdk.java.net/jdk/pull/8667 From weijun at openjdk.java.net Thu May 12 13:54:09 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 12 May 2022 13:54:09 GMT Subject: RFR: 8284194: Allow empty subject fields in keytool [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 23:40:46 GMT, Weijun Wang wrote: >> This code change allows one entering "." at a distinguished name prompt to skip a sub-component when running `keytool -genkeyapir`. Several new resource strings are added. >> >> There is no detailed description in `keytool.html`, so I think there's no need to update it. >> >> I'll file a CSR to describe the behavior change. >> >> Here is an example after this change: >> >> $ keytool -genkeypair -keystore ks -storepass changeit -alias b -keyalg EC >> Enter the distinguished name. Provide a single dot (.) to leave a sub-component empty. >> What is your first and last name? >> [Unknown]: . >> What is the name of your organizational unit? >> [Unknown]: . >> What is the name of your organization? >> [Unknown]: . >> What is the name of your City or Locality? >> [Unknown]: . >> What is the name of your State or Province? >> [Unknown]: . >> What is the two-letter country code for this unit? >> [Unknown]: . >> At least one field must be provided. Enter again. >> Enter the distinguished name. Provide a single dot (.) to leave a sub-component empty. >> What is your first and last name? >> [EMPTY]: Duke >> What is the name of your organizational unit? >> [EMPTY]: >> What is the name of your organization? >> [EMPTY]: >> What is the name of your City or Locality? >> [EMPTY]: >> What is the name of your State or Province? >> [EMPTY]: >> What is the two-letter country code for this unit? >> [EMPTY]: >> Is CN=Duke correct? >> [no]: yes >> >> Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days >> for: CN=Duke >> >> In the first round, "." is entered for all fields and keytool rejected it. In the second round, CN is entered but the others are unchanged (just type enter, because they are already entered previously). At the end, the name is "CN=Duke". > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > word change I've already modified the prompt a little before the CSR is finalized. How about Enter the distinguished name. Provider a single dot (.) to leave a sub-component empty or press ENTER to use the default value in braces. Hopefully this is not too long, and macOS users know "ENTER" is "return", and people won't debate on "braces" or "brackets". As for the "[EMPTY]" prompt, the user has already entered "." in the first round and we always remember the inputs as the new default values in the next round so that they only need to enter the components they want to update. ------------- PR: https://git.openjdk.java.net/jdk/pull/8667 From xuelei at openjdk.java.net Thu May 12 13:55:58 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 12 May 2022 13:55:58 GMT Subject: Integrated: 8286423: Destroy password protection in the example code in KeyStore In-Reply-To: <6jxClfPxpFrwWpPJG06sK5mEfNq8PE17eSMCppxiTK0=.58e07c78-0ba7-47f0-8893-8bb87adb7231@github.com> References: <6jxClfPxpFrwWpPJG06sK5mEfNq8PE17eSMCppxiTK0=.58e07c78-0ba7-47f0-8893-8bb87adb7231@github.com> Message-ID: On Tue, 10 May 2022 04:13:43 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this simple example update in the KeyStore specification? > > Password protection should be destroyed in the example code in KeyStore specification. Otherwise, applications may just copy and past the code, and forget to clean up password protection. > > It's a trivial update, and may not worthy of a CSR. But please let me know if you would like to have a CSR filed. > > Thanks, > Xuelei This pull request has now been integrated. Changeset: 1904e9d2 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/1904e9d280d1cce2deead4d4aa39dda1beb9dff1 Stats: 28 lines in 1 file changed: 14 ins; 13 del; 1 mod 8286423: Destroy password protection in the example code in KeyStore Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/8623 From mullan at openjdk.java.net Thu May 12 14:15:10 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 12 May 2022 14:15:10 GMT Subject: RFR: 8284194: Allow empty subject fields in keytool [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 13:48:46 GMT, Weijun Wang wrote: > I've already modified the prompt a little before the CSR is finalized. How about > > ``` > Enter the distinguished name. Provider a single dot (.) to leave a sub-component empty or press ENTER to use the default value in braces. > ``` > > Hopefully this is not too long, and macOS users know "ENTER" is "return", and people won't debate on "braces" or "brackets". Ok, I like that. One typo though: s/Provider/Provide > As for the "[EMPTY]" prompt, the user has already entered "." in the first round and we always remember the inputs as the new default values in the next round so that they only need to enter the components they want to update. What about just "[]"? I think if you keep EMPTY, you should really define what that keyword means, but that might make the text too verbose. ------------- PR: https://git.openjdk.java.net/jdk/pull/8667 From weijun at openjdk.java.net Thu May 12 14:18:59 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 12 May 2022 14:18:59 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: References: Message-ID: <_iORn6NU_sX0ffx8xSNHkigSlplyKN58kEJ7pIcxhUo=.79b191fd-edde-40d7-a28c-e6bc82a8e28a@github.com> On Thu, 10 Mar 2022 08:52:17 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8282662: Revert dubious changes in MethodType src/java.base/share/classes/sun/security/validator/EndEntityChecker.java line 119: > 117: // TLS key exchange algorithms requiring keyEncipherment key usage > 118: private static final Collection KU_SERVER_ENCRYPTION = > 119: Arrays.asList("RSA"); I understand that you haven't modified the `KU_SERVER_KEY_AGREEMENT` on line 122 because it has 4 elements. However, these 2 nearby lines using different styles look a little strange to me. Why restrict the number to 0, 1, and 2? If we have defined methods with up to 9 arguments, does that mean the new type is suitable for 9 elements? ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From weijun at openjdk.java.net Thu May 12 14:44:56 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 12 May 2022 14:44:56 GMT Subject: RFR: 8284194: Allow empty subject fields in keytool [v3] In-Reply-To: References: Message-ID: > This code change allows one entering "." at a distinguished name prompt to skip a sub-component when running `keytool -genkeyapir`. Several new resource strings are added. > > There is no detailed description in `keytool.html`, so I think there's no need to update it. > > I'll file a CSR to describe the behavior change. > > Here is an example after this change: > > $ keytool -genkeypair -keystore ks -storepass changeit -alias b -keyalg EC > Enter the distinguished name. Provide a single dot (.) to leave a sub-component empty. > What is your first and last name? > [Unknown]: . > What is the name of your organizational unit? > [Unknown]: . > What is the name of your organization? > [Unknown]: . > What is the name of your City or Locality? > [Unknown]: . > What is the name of your State or Province? > [Unknown]: . > What is the two-letter country code for this unit? > [Unknown]: . > At least one field must be provided. Enter again. > Enter the distinguished name. Provide a single dot (.) to leave a sub-component empty. > What is your first and last name? > [EMPTY]: Duke > What is the name of your organizational unit? > [EMPTY]: > What is the name of your organization? > [EMPTY]: > What is the name of your City or Locality? > [EMPTY]: > What is the name of your State or Province? > [EMPTY]: > What is the two-letter country code for this unit? > [EMPTY]: > Is CN=Duke correct? > [no]: yes > > Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days > for: CN=Duke > > In the first round, "." is entered for all fields and keytool rejected it. In the second round, CN is entered but the others are unchanged (just type enter, because they are already entered previously). At the end, the name is "CN=Duke". Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: update the output ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8667/files - new: https://git.openjdk.java.net/jdk/pull/8667/files/1894055d..8c592f89 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8667&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8667&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8667.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8667/head:pull/8667 PR: https://git.openjdk.java.net/jdk/pull/8667 From weijun at openjdk.java.net Thu May 12 15:07:55 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 12 May 2022 15:07:55 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v7] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 03:28:15 GMT, Valerie Peng wrote: >> This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > trivial syntax fix. LGTM. src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 363: > 361: return core.implGetParameters(); > 362: } > 363: @Override These 3 methods are the same in 3 classes. I wish we had a way to simplify this but I don't know myself. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8521 From rriggs at openjdk.java.net Thu May 12 16:54:48 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 12 May 2022 16:54:48 GMT Subject: Integrated: 8286378: Address possibly lossy conversions in java.base In-Reply-To: References: Message-ID: On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs wrote: > PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." > > This PR anticipates the warnings and adds explicit casts to replace the implicit casts. > In most cases, the cast matches the type of the right-hand side to type of the compound assignment. > Since these casts are truncating the value, there might be a different refactoring that avoids the cast > but a direct replacement was chosen here. > > (Advise and suggestions will inform similar updates to other OpenJDK modules). This pull request has now been integrated. Changeset: 17c52789 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/17c52789b79a4ccd65308f90c4e02c1732b206be Stats: 71 lines in 32 files changed: 0 ins; 3 del; 68 mod 8286378: Address possibly lossy conversions in java.base Reviewed-by: naoto, xuelei, bpb, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From rriggs at openjdk.java.net Thu May 12 16:57:18 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 12 May 2022 16:57:18 GMT Subject: RFR: 8286393: Address possibly lossy conversions in java.rmi Message-ID: Updates to modules java.rmi and java.smartcardio to remove warnings about lossy-conversions introduced by PR#8599. Explicit casts are inserted where implicit casts occur. 8286393: Address possibly lossy conversions in java.rmi 8286388: Address possibly lossy conversions in java.smartcardio ------------- Commit messages: - 8286393: Address possibly lossy conversions in java.rmi Changes: https://git.openjdk.java.net/jdk/pull/8683/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8683&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286393 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8683.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8683/head:pull/8683 PR: https://git.openjdk.java.net/jdk/pull/8683 From lancea at openjdk.java.net Thu May 12 17:36:57 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 12 May 2022 17:36:57 GMT Subject: RFR: 8286393: Address possibly lossy conversions in java.rmi In-Reply-To: References: Message-ID: On Thu, 12 May 2022 16:47:43 GMT, Roger Riggs wrote: > Updates to modules java.rmi and java.smartcardio to remove warnings about lossy-conversions introduced by PR#8599. > > Explicit casts are inserted where implicit casts occur. > > 8286393: Address possibly lossy conversions in java.rmi > 8286388: Address possibly lossy conversions in java.smartcardio Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8683 From dfuchs at openjdk.java.net Thu May 12 17:43:49 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 12 May 2022 17:43:49 GMT Subject: RFR: 8286393: Address possibly lossy conversions in java.rmi In-Reply-To: References: Message-ID: On Thu, 12 May 2022 16:47:43 GMT, Roger Riggs wrote: > Updates to modules java.rmi and java.smartcardio to remove warnings about lossy-conversions introduced by PR#8599. > > Explicit casts are inserted where implicit casts occur. > > 8286393: Address possibly lossy conversions in java.rmi > 8286388: Address possibly lossy conversions in java.smartcardio Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8683 From mullan at openjdk.java.net Thu May 12 18:26:55 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 12 May 2022 18:26:55 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v4] In-Reply-To: References: <3PhZPgbMppa_YVJ8GECtwlIHcn2rFZSaYJLmA1BsyL8=.05b69ecd-5bac-48c2-a4c3-5d16f1ef27bb@github.com> Message-ID: <9HZ7qW9IV2-1vZJP4j1npSkwI354PX9cda8ouwnWcSw=.7219c9bb-0b29-4bb6-88ea-e7bab915eb96@github.com> On Wed, 11 May 2022 22:12:48 GMT, Valerie Peng wrote: >> src/java.base/share/classes/java/security/SignatureSpi.java line 399: >> >>> 397: * values used by the underlying signature scheme. If the required >>> 398: * parameters were not supplied and can be generated by the signature, >>> 399: * the generated parameters will be returned. Otherwise, {@code null} >> >> Minor wording nit - change "will be" to "are" to be consistent with other wording which uses the present tense. Same comment applies to `Signature.getParameters`. >> >> Also, do we no longer need to mention the part "and the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}"? > > Fixed the nit. Thanks~ > As for the part about returning the parameters as `{@code AlgorithmParameters}`, it should be covered by current sentence, i.e. `and can be generated by the signature`. Perhaps we don't have to spell out all possible causes where the parameter can't be generated? That sentence is specifically if the caller did not specify parameters though. The previous wording is if the caller did specify parameters (as say an `AlgorithmParameterSpec`) and the implementation cannot return them as `AlgorithmParameters`. So I think it needs to be mentioned as it is kind of surprising if you specify parameters to `init` but `getParameters` returns null. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From mullan at openjdk.java.net Thu May 12 19:32:36 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 12 May 2022 19:32:36 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v7] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 03:28:15 GMT, Valerie Peng wrote: >> This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > trivial syntax fix. src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java line 184: > 182: "Iteration count must be a positive number"); > 183: } > 184: return iCount == 0? DEFAULT_COUNT : iCount; Nit: add space before '?'. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From valeriep at openjdk.java.net Thu May 12 19:48:54 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 12 May 2022 19:48:54 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v4] In-Reply-To: <9HZ7qW9IV2-1vZJP4j1npSkwI354PX9cda8ouwnWcSw=.7219c9bb-0b29-4bb6-88ea-e7bab915eb96@github.com> References: <3PhZPgbMppa_YVJ8GECtwlIHcn2rFZSaYJLmA1BsyL8=.05b69ecd-5bac-48c2-a4c3-5d16f1ef27bb@github.com> <9HZ7qW9IV2-1vZJP4j1npSkwI354PX9cda8ouwnWcSw=.7219c9bb-0b29-4bb6-88ea-e7bab915eb96@github.com> Message-ID: On Thu, 12 May 2022 18:23:18 GMT, Sean Mullan wrote: >> Fixed the nit. Thanks~ >> As for the part about returning the parameters as `{@code AlgorithmParameters}`, it should be covered by current sentence, i.e. `and can be generated by the signature`. Perhaps we don't have to spell out all possible causes where the parameter can't be generated? > > That sentence is specifically if the caller did not specify parameters though. The previous wording is if the caller did specify parameters (as say an `AlgorithmParameterSpec`) and the implementation cannot return them as `AlgorithmParameters`. So I think it needs to be mentioned as it is kind of surprising if you specify parameters to `init` but `getParameters` returns null. Hmm, would it fall under the "Otherwise, null is returned"? If not, perhaps we can add back the part about returning AlgorithmParameters as below: **If the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters},** the returned parameters may be the same that were used to initialize this signature, or may contain additional default or random parameter values used by the underlying signature scheme. If the required parameters were not supplied and can be generated by the signature, the generated parameters are returned. Otherwise, {@code null} is returned. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From valeriep at openjdk.java.net Thu May 12 20:02:45 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 12 May 2022 20:02:45 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v7] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 19:27:20 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> trivial syntax fix. > > src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java line 184: > >> 182: "Iteration count must be a positive number"); >> 183: } >> 184: return iCount == 0? DEFAULT_COUNT : iCount; > > Nit: add space before '?'. Sure ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From weijun at openjdk.java.net Thu May 12 20:57:38 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 12 May 2022 20:57:38 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v7] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 03:28:15 GMT, Valerie Peng wrote: >> This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > trivial syntax fix. src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java line 244: > 242: iCount = DEFAULT_COUNT; > 243: } > 244: //if (ivSpec == null) { // old behavior always generate How could `ivSpec` be non-null here? IIUC the only answer is from a previous `engineInit`, and it should not be retained. I suggest removing this check plus adding an explicit `ivSpec = null` at the beginning of this method along with `iCount` and `salt`. Those are the only 3 non final instance fields. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From wetmore at openjdk.java.net Thu May 12 21:20:50 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 12 May 2022 21:20:50 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> Message-ID: On Wed, 11 May 2022 22:25:43 GMT, Anthony Scarpino wrote: >> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 1: >> >>> 1: /* >> >> Wondering why this is in javax/net/ssl/SSLSession instead of sun/security/ssl/SSLCipher. > > I can move it.. I created it from another test which happen to be in that directory Ah. If you can, please do. Thanks. >> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 157: >> >>> 155: // Do TLS handshake >>> 156: do { >>> 157: statusClient = doHandshake(client, out, in); >> >> It's potentially a little inefficient returning after each wrap/unwrap() instead of doing the task right away, but it works. No need to change. >> >> Is this style something you copied from another test? The SSLEngineTemplate in the templates directory is what I often use. > > I got it from somewhere that I don't remember off hand. I'm just trying to get through the handshake. It was just an observation, no need to change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From valeriep at openjdk.java.net Thu May 12 21:34:41 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 12 May 2022 21:34:41 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v7] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 20:53:00 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> trivial syntax fix. > > src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java line 244: > >> 242: iCount = DEFAULT_COUNT; >> 243: } >> 244: //if (ivSpec == null) { // old behavior always generate > > How could `ivSpec` be non-null here? IIUC the only answer is from a previous `engineInit`, and it should not be retained. I suggest removing this check plus adding an explicit `ivSpec = null` at the beginning of this method along with `iCount` and `salt`. Those are the only 3 non final instance fields. Yeah, it's also possible that ivSpec is non-null if getParameters() is called before init(). Now that salt and iCount is reset in the beginning of init(), ivSpec should be reset too. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From wetmore at openjdk.java.net Thu May 12 22:18:11 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 12 May 2022 22:18:11 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> Message-ID: On Wed, 11 May 2022 23:03:27 GMT, Anthony Scarpino wrote: >> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 172: >> >>> 170: out.clear(); >>> 171: String testString = "ASDF"; >>> 172: in.put(testString.getBytes()).flip(); >> >> If you're going to convert back from UTF_8 later, you should probably convert using getBytes(UTF_8) here. > > setting the input to UTF8 isn't a concern. The latter line to decode it changes it from using the ByteBuffer.toString() to the contents of the ByteBuffer in a String. You could use the default charsets for encoding and decoding. i.e. in.clear(); receive(server, out.asReadOnlyBuffer(), in); byte[] ba = new byte[in.remaining()]; in.get(ba); String testResult = new String(ba); ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From wetmore at openjdk.java.net Thu May 12 22:37:58 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 12 May 2022 22:37:58 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> Message-ID: On Wed, 11 May 2022 22:38:04 GMT, Anthony Scarpino wrote: >> test/jdk/javax/net/ssl/SSLSession/ReadOnlyEngine.java line 162: >> >>> 160: statusServer != HandshakeStatus.NOT_HANDSHAKING); >>> 161: >>> 162: // Read NST >> >> What is NST? > > New Session Ticket Duh, of course! Yay, TLAs!!! (Three Letter Acronyms...) Feel free to expand if you're so inclined. ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From weijun at openjdk.java.net Thu May 12 22:44:50 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 12 May 2022 22:44:50 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v7] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 21:31:39 GMT, Valerie Peng wrote: >> src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java line 244: >> >>> 242: iCount = DEFAULT_COUNT; >>> 243: } >>> 244: //if (ivSpec == null) { // old behavior always generate >> >> How could `ivSpec` be non-null here? IIUC the only answer is from a previous `engineInit`, and it should not be retained. I suggest removing this check plus adding an explicit `ivSpec = null` at the beginning of this method along with `iCount` and `salt`. Those are the only 3 non final instance fields. > > Yeah, it's also possible that ivSpec is non-null if getParameters() is called before init(). Now that salt and iCount is reset in the beginning of init(), ivSpec should be reset too. Oh, I didn't realize that. So now whenever `init()` is called every old param (no matter why it was set) is totally wiped. I like this consistent behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From valeriep at openjdk.java.net Thu May 12 22:52:59 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 12 May 2022 22:52:59 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v8] In-Reply-To: References: Message-ID: > This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: reset ivSpec and minor nit fix. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8521/files - new: https://git.openjdk.java.net/jdk/pull/8521/files/c1893f8b..95dfa948 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8521&range=06-07 Stats: 8 lines in 1 file changed: 1 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8521.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8521/head:pull/8521 PR: https://git.openjdk.java.net/jdk/pull/8521 From smarks at openjdk.java.net Fri May 13 00:35:39 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 13 May 2022 00:35:39 GMT Subject: RFR: 8286393: Address possibly lossy conversions in java.rmi In-Reply-To: References: Message-ID: On Thu, 12 May 2022 16:47:43 GMT, Roger Riggs wrote: > Updates to modules java.rmi and java.smartcardio to remove warnings about lossy-conversions introduced by PR#8599. > > Explicit casts are inserted where implicit casts occur. > > 8286393: Address possibly lossy conversions in java.rmi > 8286388: Address possibly lossy conversions in java.smartcardio Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8683 From smarks at openjdk.java.net Fri May 13 00:39:40 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 13 May 2022 00:39:40 GMT Subject: RFR: 8286393: Address possibly lossy conversions in java.rmi In-Reply-To: References: Message-ID: On Thu, 12 May 2022 16:47:43 GMT, Roger Riggs wrote: > Updates to modules java.rmi and java.smartcardio to remove warnings about lossy-conversions introduced by PR#8599. > > Explicit casts are inserted where implicit casts occur. > > 8286393: Address possibly lossy conversions in java.rmi > 8286388: Address possibly lossy conversions in java.smartcardio Reviewed. I also added `noreg-trivial` labels to the bug reports. ------------- PR: https://git.openjdk.java.net/jdk/pull/8683 From duke at openjdk.java.net Fri May 13 04:44:38 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 13 May 2022 04:44:38 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments." >> >> This PR anticipates the warnings and adds explicit casts to replace the implicit casts. >> In most cases, the cast matches the type of the right-hand side to type of the compound assignment. >> Since these casts are truncating the value, there might be a different refactoring that avoids the cast >> but a direct replacement was chosen here. >> >> (Advise and suggestions will inform similar updates to other OpenJDK modules). > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyrights > Fixed cast style to add a space after cast, (where consistent with file style) > Improved code per review comments in PollSelectors. src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128: > 126: // timed poll interrupted so need to adjust timeout > 127: long adjust = System.nanoTime() - startTime; > 128: to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust); This?will?now always?assign a?negative?number to?`to`. -------------------------------------------------------------------------------- `=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment. ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From alanb at openjdk.java.net Fri May 13 05:56:40 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 13 May 2022 05:56:40 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 04:41:03 GMT, ExE Boss wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated copyrights >> Fixed cast style to add a space after cast, (where consistent with file style) >> Improved code per review comments in PollSelectors. > > src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128: > >> 126: // timed poll interrupted so need to adjust timeout >> 127: long adjust = System.nanoTime() - startTime; >> 128: to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust); > > This?will?now always?assign a?negative?number to?`to`. > > -------------------------------------------------------------------------------- > > `=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment. Well spotted, I don't think that change was intentionally. ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From duke at openjdk.java.net Fri May 13 06:30:47 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 13 May 2022 06:30:47 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: <_iORn6NU_sX0ffx8xSNHkigSlplyKN58kEJ7pIcxhUo=.79b191fd-edde-40d7-a28c-e6bc82a8e28a@github.com> References: <_iORn6NU_sX0ffx8xSNHkigSlplyKN58kEJ7pIcxhUo=.79b191fd-edde-40d7-a28c-e6bc82a8e28a@github.com> Message-ID: On Thu, 12 May 2022 14:14:38 GMT, Weijun Wang wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282662: Revert dubious changes in MethodType > > src/java.base/share/classes/sun/security/validator/EndEntityChecker.java line 119: > >> 117: // TLS key exchange algorithms requiring keyEncipherment key usage >> 118: private static final Collection KU_SERVER_ENCRYPTION = >> 119: Arrays.asList("RSA"); > > I understand that you haven't modified the `KU_SERVER_KEY_AGREEMENT` on line 122 because it has 4 elements. However, these 2 nearby lines using different styles look a little strange to me. Why restrict the number to 0, 1, and 2? If we have defined methods with up to 9 arguments, does that mean the new type is suitable for 9 elements? The reason is that for the cases of length 0, 1, 2 we don't create underlying array as we do for larger number of elements. In other words when we replace `Arrays.asList()` with `List.of()` we win only for 0, 1 and 2 elements. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From michaelm at openjdk.java.net Fri May 13 11:11:56 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 13 May 2022 11:11:56 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v3] In-Reply-To: References: Message-ID: On Sat, 7 May 2022 11:46:37 GMT, Daniel Fuchs wrote: >> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java` >> >> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit. >> >> The fix comprises several cleanup - in particular: >> >> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed >> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed >> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called >> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary >> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`) > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into ExecutorShutdown-intermittent-8286194 > - Added a comment to ReferenceTracker.java as suggested in the review > - 8286194: ExecutorShutdown test fails intermittently Good to see the dead code removed from HttpClientImpl (cancel). Question about the code copied in from ThreadInfo. Is there any way we could request a change to that class to adjust the number of stack frames printed? Okay, I see the same issue has been raised already. I agree we should request that enhancement. ------------- PR: https://git.openjdk.java.net/jdk/pull/8562 From duke at openjdk.java.net Fri May 13 11:19:51 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 13 May 2022 11:19:51 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: References: Message-ID: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com> On Thu, 10 Mar 2022 08:52:17 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8282662: Revert dubious changes in MethodType src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 727: > 725: MethodVisitor mv = cw.visitMethod(accessFlags, > 726: method.getName(), desc, null, > 727: typeNames(List.of(exceptionTypes))); Since?`exceptionTypes` is?an?array, it?might be?better to?keep?using `Arrays.asList`, or?add an?overload for?`typeNames` that?works on?class?arrays. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From dfuchs at openjdk.java.net Fri May 13 11:34:03 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 13 May 2022 11:34:03 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v3] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 11:09:31 GMT, Michael McMahon wrote: > Question about the code copied in from ThreadInfo. Is there any way we could request a change to that class to adjust the number of stack frames printed? Thanks Michael. I have logged https://bugs.openjdk.java.net/browse/JDK-8286720 ------------- PR: https://git.openjdk.java.net/jdk/pull/8562 From michaelm at openjdk.java.net Fri May 13 11:41:11 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 13 May 2022 11:41:11 GMT Subject: RFR: 8286194: ExecutorShutdown test fails intermittently [v3] In-Reply-To: References: Message-ID: On Sat, 7 May 2022 11:46:37 GMT, Daniel Fuchs wrote: >> Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java` >> >> A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit. >> >> The fix comprises several cleanup - in particular: >> >> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed >> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed >> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called >> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary >> - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`) > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into ExecutorShutdown-intermittent-8286194 > - Added a comment to ReferenceTracker.java as suggested in the review > - 8286194: ExecutorShutdown test fails intermittently Change looks fine to me. We can revisit the ThreadInfo code later. ------------- Marked as reviewed by michaelm (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8562 From dfuchs at openjdk.java.net Fri May 13 11:56:52 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 13 May 2022 11:56:52 GMT Subject: Integrated: 8286194: ExecutorShutdown test fails intermittently In-Reply-To: References: Message-ID: <_ntXnBTOB4AhEv9fAUIJrKq4Qo1Vp3YzKN00xzmSFfo=.3331d153-d17a-4d84-bdff-d1a4b70dc550@github.com> On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs wrote: > Hi, please find here a patch that solves a rare intermittent test failure observed in the test `java/net/httpclient/ExecutorShutdown.java` > > A race condition coupled with some too eager synchronization was causing a deadlock between an Http2Connection close, a thread trying to shutdown the HttpClient due to a RejectedTaskException, and the SelectorManager thread trying to exit. > > The fix comprises several cleanup - in particular: > > - `Http2Connection`: no need to try to send a `GOAWAY` frame if the underlying TCP connection is already closed > - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will request more data from upstream if the sequential scheduler that is supposed to handle that data once it arrives is already closed > - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an exception is raised before `onSubscribe()` has been called > - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks when not necessary > - `ReferenceTracker`: better thread dumps in case where the selector is still alive at the end of the test (remove the limit that limited the stack traces to 8 element max by no longer relying on `ThreadInfo::toString`) This pull request has now been integrated. Changeset: 04df8b74 Author: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/04df8b74379c9de7b20931fea1642f82569d3a2d Stats: 138 lines in 7 files changed: 110 ins; 3 del; 25 mod 8286194: ExecutorShutdown test fails intermittently Reviewed-by: jpai, michaelm ------------- PR: https://git.openjdk.java.net/jdk/pull/8562 From duke at openjdk.java.net Fri May 13 12:23:03 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 13 May 2022 12:23:03 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com> References: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com> Message-ID: On Fri, 13 May 2022 11:14:29 GMT, ExE Boss wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282662: Revert dubious changes in MethodType > > src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 727: > >> 725: MethodVisitor mv = cw.visitMethod(accessFlags, >> 726: method.getName(), desc, null, >> 727: typeNames(List.of(exceptionTypes))); > > Since?`exceptionTypes` is?an?array, it?might be?better to?keep?using `Arrays.asList`, or?add an?overload for?`typeNames` that?works on?class?arrays. Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Fri May 13 12:23:04 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 13 May 2022 12:23:04 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: References: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com> Message-ID: <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com> On Fri, 13 May 2022 12:19:08 GMT, ?????? ??????? wrote: >> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 727: >> >>> 725: MethodVisitor mv = cw.visitMethod(accessFlags, >>> 726: method.getName(), desc, null, >>> 727: typeNames(List.of(exceptionTypes))); >> >> Since?`exceptionTypes` is?an?array, it?might be?better to?keep?using `Arrays.asList`, or?add an?overload for?`typeNames` that?works on?class?arrays. > > Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From mcimadamore at openjdk.java.net Fri May 13 12:43:27 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 May 2022 12:43:27 GMT Subject: RFR: 8286715: Generalize MemorySegment::ofBuffer Message-ID: This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`. This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function. We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`. So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`. In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case. ------------- Commit messages: - Tweak javadoc - Merge branch 'foreign-preview' into generalize_ofbuffer - Merge branch 'master' into foreign-preview - Merge branch 'master' into foreign-preview - Merge branch 'master' into foreign-preview - Fix crashes in heap segment benchmarks due to misaligned access - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java - Initial push - Add tests for loaderLookup/restricted method corner cases - ... and 59 more: https://git.openjdk.java.net/jdk/compare/11fa03f3...02494e2f Changes: https://git.openjdk.java.net/jdk/pull/8701/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8701&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286715 Stats: 95 lines in 8 files changed: 55 ins; 1 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/8701.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8701/head:pull/8701 PR: https://git.openjdk.java.net/jdk/pull/8701 From mcimadamore at openjdk.java.net Fri May 13 12:43:28 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 May 2022 12:43:28 GMT Subject: RFR: 8286715: Generalize MemorySegment::ofBuffer In-Reply-To: References: Message-ID: On Fri, 13 May 2022 12:33:10 GMT, Maurizio Cimadamore wrote: > This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`. > This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function. > > We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`. > So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`. > > In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case. src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 88: > 86: * if it is associated with a confined session, it can only be accessed by the thread which owns the memory session. > 87: *

> 88: * Heap segments are always associated with the {@linkplain MemorySession#global() global} memory session. I've tweaked this text, as I realized the old version was erroneously suggesting that all buffer segments were backed by a global session. src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 577: > 575: } > 576: > 577: private static int getScaleFactor(Buffer buffer) { Note: for each buffer kind, there are three possible cases. Consider `IntBuffer`: an `IntBuffer` can be backed by: * `byte[]`, if it's a byte buffer view * `int[]`, if it's allocated with `IntBuffer.allocate`, or `IntBuffer.wrap` * null, if it comes from a direct byte buffer viewed as an `IntBuffer` As such, the buffer kind (IntBuffer vs. LongBuffer) determines the buffer element size, and therefore how much the buffer position and size should be scaled. But to check whether we need to create a heap vs. off-heap vs. mapped segment, or to check _which_ kind of heap segment we need, we need to look into the buffer base object, since there can be multiple options for any single buffer type. ------------- PR: https://git.openjdk.java.net/jdk/pull/8701 From duke at openjdk.java.net Fri May 13 13:41:48 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 13 May 2022 13:41:48 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com> References: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com> <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com> Message-ID: On Fri, 13 May 2022 12:19:25 GMT, ?????? ??????? wrote: >> Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving > > Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving Even?in the?no?exceptions?case, the?`exceptionTypes`?array still?has to?be?allocated/copied by?`Method.getExceptionTypes()`[^1] when?the?`ProxyMethod`?constructor[^2] is?invoked. So?if?anything, the?`List.of(?)`?call should?be?moved into?the?`ProxyMethod`?constructor. And?maybe the?call to?`Method.getExceptionTypes()` should?be?changed to?`Method.getSharedExceptionTypes()`[^3]. [^1]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/Method.java#L340-L343 [^2]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L710-L714 [^3]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/Method.java#L305-L308 ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From rriggs at openjdk.java.net Fri May 13 14:22:01 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 13 May 2022 14:22:01 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 05:54:15 GMT, Alan Bateman wrote: >> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128: >> >>> 126: // timed poll interrupted so need to adjust timeout >>> 127: long adjust = System.nanoTime() - startTime; >>> 128: to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust); >> >> This?will?now always?assign a?negative?number to?`to`. >> >> -------------------------------------------------------------------------------- >> >> `=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment. > > Well spotted, I don't think that change was intentionally. Ouch; Will fix: I took Alan's earlier comment literally: "This one can also be changed to: to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);" ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From duke at openjdk.java.net Fri May 13 14:27:02 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 13 May 2022 14:27:02 GMT Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 14:18:04 GMT, Roger Riggs wrote: >> Well spotted, I don't think that change was intentionally. > > Ouch; Will fix: > > I took Alan's earlier comment literally: > > "This one can also be changed to: > > to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);" @RogerRiggs This?already got?fixed by?@jaikiran in?[GH?8693]. [GH?8693]: https://github.com/openjdk/jdk/pull/8693 ------------- PR: https://git.openjdk.java.net/jdk/pull/8642 From xueleifan at tencent.com Fri May 13 14:37:21 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Fri, 13 May 2022 14:37:21 +0000 Subject: [Internet]Re: Reproducer for JDK-8221218 In-Reply-To: <20A6E533-D210-40B4-8A0E-9CACC8767966@Tencent.Com> References: <20A6E533-D210-40B4-8A0E-9CACC8767966@Tencent.Com> Message-ID: <82B3EA9E-E65A-430C-ACC9-590BAAE9999A@Tencent.Com> Ping ? Is there a link to the "How to reproduce? information? Thanks, Xuelei On Apr 26, 2022, at 7:16 AM, xueleifan(XueleiFan) > wrote: I will have a look at it. I may need help for more information. On Apr 25, 2022, at 7:45 AM, Flavia Rainone > wrote: Hi everyone, I work with the XNIO ( https://github.com/xnio/xnio/ ) project, led by David Lloyd in CC. I'm not sure if this is the best way to get in touch, but I could not find out how to create an account for OpenJDK Jira to add a comment there. We have a reproducer for JDK-8221218, and it appears it is not solved yet (tested with jdk 11.0.12). It is not intermittent, and it happens when we try to do an SSLEngine.unwrap with a zero remaining() ByteBuffer (in older versions, the engine would just return a BUFFER_UNDERFLOW result). It is expected to check the remaining before reading the packet. Is there a working closing thread while unwrap() is in progress? Did you have the debug log (-Djavax.net.debug=all) and the exception stacks that I can refer to? It would be nice if JDK 17 or 18 get checked as well. You can see more information about this here: https://issues.redhat.com/browse/XNIO-406 To reproduce the issue, just follow the steps in "How to reproduce" using JDK11 and add a breakpoint at this line: https://github.com/xnio/xnio/pull/282/commits/2ae0c1b368c6e0886f9c03030ec443c346cb0a71#diff-9f162fd704e4d5eaff8abb932a923ae868adf3f642d85bc6f5bcfd5f7fe1763bR695 Is there a link to "How to reproduce?? Thanks, Xuelei Or you can simply open the test output file to view the exception: xnio/nio-impl/target/surefire-reports/org.xnio.nio.test.NioSslTcpChannelTestCase-output.txt (but then you have to comment out the XNIO-406 workaround above) Notice that there are other failures with XNIO testsuite related to JDK11 and newer, as tracked by another Jira (XNIO-347), but they seem to be unrelated to this issue, hence why the mvn clean install -DskipTests in the reproduce steps. Branch of choice should be 3.8 Since I won't be around for the next few days, Richard Opalka in CC will follow up with you. Best regards, -- Flavia Rainone Principal Software Engineer Red Hat frainone at redhat.com [https://static.redhat.com/libs/redhat/brand-assets/2/corp/logo--200.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From mullan at openjdk.java.net Fri May 13 14:39:50 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 13 May 2022 14:39:50 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v4] In-Reply-To: References: <3PhZPgbMppa_YVJ8GECtwlIHcn2rFZSaYJLmA1BsyL8=.05b69ecd-5bac-48c2-a4c3-5d16f1ef27bb@github.com> <9HZ7qW9IV2-1vZJP4j1npSkwI354PX9cda8ouwnWcSw=.7219c9bb-0b29-4bb6-88ea-e7bab915eb96@github.com> Message-ID: On Thu, 12 May 2022 19:45:37 GMT, Valerie Peng wrote: >> That sentence is specifically if the caller did not specify parameters though. The previous wording is if the caller did specify parameters (as say an `AlgorithmParameterSpec`) and the implementation cannot return them as `AlgorithmParameters`. So I think it needs to be mentioned as it is kind of surprising if you specify parameters to `setParameter` but `getParameters` returns null. > > Hmm, would it fall under the "Otherwise, null is returned"? If not, perhaps we can add back the part about returning AlgorithmParameters as below: > > **If the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters},** the returned parameters may be the same that were used to initialize > this signature, or may contain additional default or random parameter values used by the underlying signature scheme. If the required parameters were not supplied and can be generated by the signature, the generated parameters are returned. Otherwise, {@code null} is returned. I think it is a special case that should be specified. Theoretically, it could also occur if params were not supplied by the caller, but the implementation generated parameters and then could not return them as AlgorithmParameters. I think the underlying issue is that not all Signature algorithms should be required to support an encoded form of the parameters. It is hard to fit all of these cases in a couple of sentences. I would be more inclined to add something like the following after the two sentences you currently have: "However, if the underlying implementation does not support returning the parameters as `AlgorithmParameters`, `null` is always returned." ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From rriggs at openjdk.java.net Fri May 13 14:43:52 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 13 May 2022 14:43:52 GMT Subject: Integrated: 8286393: Address possibly lossy conversions in java.rmi In-Reply-To: References: Message-ID: <80bLg-vrdH0f0tm8xBx_Cv9uHyLfeRKaY1PYD44wSe4=.95ad8079-cbe0-4416-a051-cb7722b1ef34@github.com> On Thu, 12 May 2022 16:47:43 GMT, Roger Riggs wrote: > Updates to modules java.rmi and java.smartcardio to remove warnings about lossy-conversions introduced by PR#8599. > > Explicit casts are inserted where implicit casts occur. > > 8286393: Address possibly lossy conversions in java.rmi > 8286388: Address possibly lossy conversions in java.smartcardio This pull request has now been integrated. Changeset: 237f2801 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/237f28014ab9d27d2cdfe3fdc4a5b0a0680f8e95 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod 8286393: Address possibly lossy conversions in java.rmi 8286388: Address possibly lossy conversions in java.smartcardio Reviewed-by: lancea, dfuchs, smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/8683 From ihse at openjdk.java.net Fri May 13 15:08:56 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 15:08:56 GMT Subject: Integrated: 8285380: Fix typos in security In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 13:51:27 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on modules owned by the security team (`java.security.jgss java.security.sasl java.smartcardio java.xml.crypto jdk.crypto.cryptoki jdk.crypto.ec jdk.crypto.mscapi jdk.security.auth jdk.security.jgss`), and accepted those changes where it indeed discovered real typos. > > I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). > > The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. This pull request has now been integrated. Changeset: f631c988 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/f631c9884f252a1349b81ee2db2e69af43784802 Stats: 81 lines in 52 files changed: 0 ins; 0 del; 81 mod 8285380: Fix typos in security Reviewed-by: weijun, wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/8340 From xueleifan at tencent.com Fri May 13 15:27:56 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Fri, 13 May 2022 15:27:56 +0000 Subject: [Internet]Re: JDK-8221218 - Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16) In-Reply-To: References: <4446C848-22C7-4B0F-B0F2-94D1924D5C57@Tencent.Com> <4882b356-5bfa-b4ae-285e-c197feb7c557@suche.org> Message-ID: <6D7A3BFB-7A86-43C1-A3B9-8BA7642D9149@Tencent.Com> Hm, I get a hint about the issue now. Did SunJSSE provider used in both client and server? Xuelei > On Apr 26, 2022, at 7:36 AM, Thomas Lu?nig wrote: > > Hi, > > i changed the logging and now better get the Location of the error > > javax.crypto.BadPaddingException: Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16) > at java.base/sun.security.ssl.SSLCipher$T13GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1898) > at java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:239) > at java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:196) > at java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:159) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111) > at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:736) > at java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:691) > at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506) > at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482) > at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:679) > at org.eclipse.jetty.io.ssl.SslConnection.unwrap(SslConnection.java:406) > > > Gru? Thomas > > From xueleifan at tencent.com Fri May 13 17:34:35 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Fri, 13 May 2022 17:34:35 +0000 Subject: [Internet]Re: Re: JDK-8221218 - Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16) In-Reply-To: <6D7A3BFB-7A86-43C1-A3B9-8BA7642D9149@Tencent.Com> References: <4446C848-22C7-4B0F-B0F2-94D1924D5C57@Tencent.Com> <4882b356-5bfa-b4ae-285e-c197feb7c557@suche.org> <6D7A3BFB-7A86-43C1-A3B9-8BA7642D9149@Tencent.Com> Message-ID: Would you mind send the debug log information, with System property javax.net.debug=all? Thanks, Xuelei > On May 13, 2022, at 8:27 AM, xueleifan(XueleiFan) wrote: > > Hm, I get a hint about the issue now. Did SunJSSE provider used in both client and server? > > Xuelei > >> On Apr 26, 2022, at 7:36 AM, Thomas Lu?nig wrote: >> >> Hi, >> >> i changed the logging and now better get the Location of the error >> >> javax.crypto.BadPaddingException: Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16) >> at java.base/sun.security.ssl.SSLCipher$T13GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1898) >> at java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:239) >> at java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:196) >> at java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:159) >> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111) >> at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:736) >> at java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:691) >> at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506) >> at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482) >> at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:679) >> at org.eclipse.jetty.io.ssl.SslConnection.unwrap(SslConnection.java:406) >> >> >> Gru? Thomas >> >> > From valeriep at openjdk.java.net Fri May 13 18:54:57 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 13 May 2022 18:54:57 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v7] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 15:03:40 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> trivial syntax fix. > > src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java line 363: > >> 361: return core.implGetParameters(); >> 362: } >> 363: @Override > > These 3 methods are the same in 3 classes. I wish we had a way to simplify this but I don't know myself. Me neither. However, the refactoring is already reduced quite some code (~300 lines less for the two PBE classes), just can't be 100% lean. ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From valeriep at openjdk.java.net Fri May 13 19:03:56 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 13 May 2022 19:03:56 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v4] In-Reply-To: References: <3PhZPgbMppa_YVJ8GECtwlIHcn2rFZSaYJLmA1BsyL8=.05b69ecd-5bac-48c2-a4c3-5d16f1ef27bb@github.com> <9HZ7qW9IV2-1vZJP4j1npSkwI354PX9cda8ouwnWcSw=.7219c9bb-0b29-4bb6-88ea-e7bab915eb96@github.com> Message-ID: On Fri, 13 May 2022 14:35:56 GMT, Sean Mullan wrote: >> Hmm, would it fall under the "Otherwise, null is returned"? If not, perhaps we can add back the part about returning AlgorithmParameters as below: >> >> **If the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters},** the returned parameters may be the same that were used to initialize >> this signature, or may contain additional default or random parameter values used by the underlying signature scheme. If the required parameters were not supplied and can be generated by the signature, the generated parameters are returned. Otherwise, {@code null} is returned. > > I think it is a special case that should be specified. Theoretically, it could also occur if params were not supplied by the caller, but the implementation generated parameters and then could not return them as AlgorithmParameters. I think the underlying issue is that not all Signature algorithms should be required to support an encoded form of the parameters. > > It is hard to fit all of these cases in a couple of sentences. I would be more inclined to add something like the following after the two sentences you currently have: "However, if the underlying implementation does not support returning the parameters as `AlgorithmParameters`, `null` is always returned." Yes, I agree that it's a special case as the convention is to define the parameter spec class based on the ASN.1 structure. I like your suggestion better also. Will update using it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From valeriep at openjdk.java.net Fri May 13 19:30:28 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 13 May 2022 19:30:28 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v6] In-Reply-To: References: Message-ID: > This is to update the method javadoc of java.security.Signature.getParameters() with the missing `@throws UnsupportedOperationException`. In addition, the wording on the returned parameters are updated to match those in Cipher and CipherSpi classes. > > CSR will be filed later. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: change the last sentence for the "cannot return AlgorithmParameters" case. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8396/files - new: https://git.openjdk.java.net/jdk/pull/8396/files/1f02b558..7026bb65 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=04-05 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8396/head:pull/8396 PR: https://git.openjdk.java.net/jdk/pull/8396 From valeriep at openjdk.java.net Fri May 13 19:35:35 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 13 May 2022 19:35:35 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v7] In-Reply-To: References: Message-ID: > This is to update the method javadoc of java.security.Signature.getParameters() with the missing `@throws UnsupportedOperationException`. In addition, the wording on the returned parameters are updated to match those in Cipher and CipherSpi classes. > > CSR will be filed later. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: fix newline. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8396/files - new: https://git.openjdk.java.net/jdk/pull/8396/files/7026bb65..68b36fc1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=05-06 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8396/head:pull/8396 PR: https://git.openjdk.java.net/jdk/pull/8396 From mullan at openjdk.java.net Fri May 13 20:32:45 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 13 May 2022 20:32:45 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v7] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 19:35:35 GMT, Valerie Peng wrote: >> This is to update the method javadoc of java.security.Signature.getParameters() with the missing `@throws UnsupportedOperationException`. In addition, the wording on the returned parameters are updated to match those in Cipher and CipherSpi classes. >> >> CSR will be filed later. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > fix newline. src/java.base/share/classes/java/security/Signature.java line 1012: > 1010: * values used by the underlying signature scheme. If the required > 1011: * parameters were not supplied and can be generated by the signature, > 1012: * the generated parameters are returned. However, if the signature scheme I think one small addition to the 2nd sentence would help to cover the case where null is returned if params were not set and the impl does not generate params (regardless as to whether it supports returning them as `AlgorithmParameters`): "If the required parameters were not supplied and can be generated by the signature, the generated parameters are returned; otherwise `null` is returned." ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From valeriep at openjdk.java.net Fri May 13 21:02:00 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 13 May 2022 21:02:00 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v7] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 20:29:11 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> fix newline. > > src/java.base/share/classes/java/security/Signature.java line 1012: > >> 1010: * values used by the underlying signature scheme. If the required >> 1011: * parameters were not supplied and can be generated by the signature, >> 1012: * the generated parameters are returned. However, if the signature scheme > > I think one small addition to the 2nd sentence would help to cover the case where null is returned if params were not set and the impl does not generate params (regardless as to whether it supports returning them as `AlgorithmParameters`): "If the required parameters were not supplied and can be generated by the signature, the generated parameters are returned; otherwise `null` is returned." With this modification of 2nd sentence. The whole paragraph becomes: *

The returned parameters may be the same that were used to initialize * this signature, or may contain additional default or random parameter * values used by the underlying signature scheme. If the required * parameters were not supplied and can be generated by the signature, * the generated parameters are returned; otherwise {@code null} is * returned. However, if the signature scheme does not support returning * the parameters as {@code AlgorithmParameters}, {@code null} is always * returned. For the last sentence, would it be better to use "also" instead of "always"? ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From hchao at openjdk.java.net Sat May 14 02:00:16 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Sat, 14 May 2022 02:00:16 GMT Subject: RFR: 8286090: Add RC2/RC4 to jdk.security.legacyAlgorithms Message-ID: Please review the small change to add RC2 and ARCFOUR to jdk.security.legacyAlgorithms. So it enables keytool -genseckey, -list, and -importkeystore commands to warn users when RC2 or ARCFOUR algorithm is used. ------------- Commit messages: - 8286090: Add RC2/RC4 to jdk.security.legacyAlgorithms Changes: https://git.openjdk.java.net/jdk/pull/8712/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8712&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286090 Stats: 20 lines in 2 files changed: 18 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8712.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8712/head:pull/8712 PR: https://git.openjdk.java.net/jdk/pull/8712 From hchao at openjdk.java.net Sat May 14 02:04:47 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Sat, 14 May 2022 02:04:47 GMT Subject: RFR: 8286090: Add RC2/RC4 to jdk.security.legacyAlgorithms In-Reply-To: References: Message-ID: On Sat, 14 May 2022 01:51:34 GMT, Hai-May Chao wrote: > Please review the small change to add RC2 and ARCFOUR to jdk.security.legacyAlgorithms. So it enables keytool -genseckey, -list, and -importkeystore commands to warn users when RC2 or ARCFOUR algorithm is used. CSR is at: https://bugs.openjdk.java.net/browse/JDK-8286764 ------------- PR: https://git.openjdk.java.net/jdk/pull/8712 From ascarpino at openjdk.java.net Sat May 14 03:29:14 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Sat, 14 May 2022 03:29:14 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer [v2] In-Reply-To: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> Message-ID: <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com> > Hi, > > I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation > > The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision. > > Tony Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - review update - update some nits - PR ready - Initial ------------- Changes: https://git.openjdk.java.net/jdk/pull/8462/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8462&range=01 Stats: 393 lines in 3 files changed: 291 ins; 20 del; 82 mod Patch: https://git.openjdk.java.net/jdk/pull/8462.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8462/head:pull/8462 PR: https://git.openjdk.java.net/jdk/pull/8462 From xuelei at openjdk.java.net Sat May 14 07:01:55 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 14 May 2022 07:01:55 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer [v2] In-Reply-To: <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com> References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com> Message-ID: On Sat, 14 May 2022 03:29:14 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation >> >> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision. >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - review update > - update some nits > - PR ready > - Initial As the specification has been indicate that the input buffer could be updated, what do you think if closing the bug as "Not an issue" (or clarify the spec but no implementation update)? I was just wondering if it really worthy the effort to make the code more complicated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From jjiang at openjdk.java.net Sat May 14 13:48:58 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Sat, 14 May 2022 13:48:58 GMT Subject: RFR: 8286773: cleanup @returns in sun.security classes Message-ID: The below sun.security classes should use `@return` rather than `@returns`. sun/security/tools/keytool/Main.java sun/security/util/DerValue.java ------------- Commit messages: - 8286773: cleanup @returns in sun.security classes Changes: https://git.openjdk.java.net/jdk/pull/8714/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8714&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286773 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8714.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8714/head:pull/8714 PR: https://git.openjdk.java.net/jdk/pull/8714 From xuelei at openjdk.java.net Sat May 14 14:12:39 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 14 May 2022 14:12:39 GMT Subject: RFR: 8286773: cleanup @returns in sun.security classes In-Reply-To: References: Message-ID: On Sat, 14 May 2022 13:41:38 GMT, John Jiang wrote: > The below sun.security classes should use `@return` rather than `@returns`. > sun/security/tools/keytool/Main.java > sun/security/util/DerValue.java Looks good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8714 From jjiang at openjdk.java.net Sat May 14 21:55:41 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Sat, 14 May 2022 21:55:41 GMT Subject: Integrated: 8286773: cleanup @returns in sun.security classes In-Reply-To: References: Message-ID: On Sat, 14 May 2022 13:41:38 GMT, John Jiang wrote: > The below sun.security classes should use `@return` rather than `@returns`. > sun/security/tools/keytool/Main.java > sun/security/util/DerValue.java This pull request has now been integrated. Changeset: 63bd3b77 Author: John Jiang URL: https://git.openjdk.java.net/jdk/commit/63bd3b7728e0e717e6b4a45a519ff03002cbdb66 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8286773: cleanup @returns in sun.security classes Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/8714 From weijun at openjdk.java.net Sun May 15 22:33:00 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 15 May 2022 22:33:00 GMT Subject: Integrated: 8284194: Allow empty subject fields in keytool In-Reply-To: References: Message-ID: On Wed, 11 May 2022 21:55:45 GMT, Weijun Wang wrote: > This code change allows one entering "." at a distinguished name prompt to skip a sub-component when running `keytool -genkeyapir`. Several new resource strings are added. > > There is no detailed description in `keytool.html`, so I think there's no need to update it. > > I'll file a CSR to describe the behavior change. > > Here is an example after this change: > > $ keytool -genkeypair -keystore ks -storepass changeit -alias b -keyalg EC > Enter the distinguished name. Provide a single dot (.) to leave a sub-component empty or press ENTER to use the default value in braces. > What is your first and last name? > [Unknown]: . > What is the name of your organizational unit? > [Unknown]: . > What is the name of your organization? > [Unknown]: . > What is the name of your City or Locality? > [Unknown]: . > What is the name of your State or Province? > [Unknown]: . > What is the two-letter country code for this unit? > [Unknown]: . > At least one field must be provided. Enter again. > Enter the distinguished name. Provide a single dot (.) to leave a sub-component empty or press ENTER to use the default value in braces. > What is your first and last name? > []: Duke > What is the name of your organizational unit? > []: > What is the name of your organization? > []: > What is the name of your City or Locality? > []: > What is the name of your State or Province? > []: > What is the two-letter country code for this unit? > []: > Is CN=Duke correct? > [no]: yes > > Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days > for: CN=Duke > > In the first round, "." is entered for all fields and keytool rejected it. In the second round, CN is entered but the others are unchanged (just type enter, because they are already entered previously). At the end, the name is "CN=Duke". This pull request has now been integrated. Changeset: f4f1dddf Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/f4f1dddfef6ed3206763bb0e441aebd06a23d6fe Stats: 128 lines in 4 files changed: 91 ins; 3 del; 34 mod 8284194: Allow empty subject fields in keytool Reviewed-by: jnimeh, hchao ------------- PR: https://git.openjdk.java.net/jdk/pull/8667 From weijun at openjdk.java.net Sun May 15 22:34:42 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 15 May 2022 22:34:42 GMT Subject: Integrated: 8286428: AlgorithmId should understand PBES2 In-Reply-To: <4gme7URJVgzZQCxSXT68oLO6xmuo9bYbX1xnEc_z3-s=.1e1771b6-2bab-4788-8fea-24e6f4f32387@github.com> References: <4gme7URJVgzZQCxSXT68oLO6xmuo9bYbX1xnEc_z3-s=.1e1771b6-2bab-4788-8fea-24e6f4f32387@github.com> Message-ID: On Mon, 9 May 2022 21:44:10 GMT, Weijun Wang wrote: > `AlgorithmId.getName` is updated for PBES2 algorithm identifiers so it directly returns the standard algorithm defined by Java (Ex: `PBEWithHmacSHA256AndAES_256`), instead of a simple "PBES2". > > Please note I specifically update the javadoc for this method to clarify that this name is meant to be a name that's recognized by various `getInstance()` methods. This is how we are actually using this method. > > After this change, the `javax.crypto.EncryptedPrivateKeyInfo` API automatically works with PBES2 encrypted data. As the spec of its `getAlgName()` methods says, "Standard name is returned". This is shown by the newly include regression test. > > Existing security-related tests run fine. This pull request has now been integrated. Changeset: 357f990e Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/357f990e3244feaba6d8709b7ea50660220a418b Stats: 149 lines in 3 files changed: 118 ins; 16 del; 15 mod 8286428: AlgorithmId should understand PBES2 Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/8615 From mullan at openjdk.java.net Mon May 16 13:03:14 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 16 May 2022 13:03:14 GMT Subject: RFR: 8286090: Add RC2/RC4 to jdk.security.legacyAlgorithms In-Reply-To: References: Message-ID: On Sat, 14 May 2022 01:51:34 GMT, Hai-May Chao wrote: > Please review the small change to add RC2 and ARCFOUR to jdk.security.legacyAlgorithms. So it enables keytool -genseckey, -list, and -importkeystore commands to warn users when RC2 or ARCFOUR algorithm is used. test/jdk/sun/security/tools/keytool/WeakSecretKeyTest.java line 67: > 65: > 66: SecurityTools.keytool("-keystore ks.p12 -storepass changeit " + > 67: "-genseckey -keyalg RC4 -alias rc4key -keysize 1024") `-keysize` should be 128. ------------- PR: https://git.openjdk.java.net/jdk/pull/8712 From mullan at openjdk.java.net Mon May 16 13:31:50 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 16 May 2022 13:31:50 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v7] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 20:58:16 GMT, Valerie Peng wrote: >> src/java.base/share/classes/java/security/Signature.java line 1012: >> >>> 1010: * values used by the underlying signature scheme. If the required >>> 1011: * parameters were not supplied and can be generated by the signature, >>> 1012: * the generated parameters are returned. However, if the signature scheme >> >> I think one small addition to the 2nd sentence would help to cover the case where null is returned if params were not set and the impl does not generate params (regardless as to whether it supports returning them as `AlgorithmParameters`): "If the required parameters were not supplied and can be generated by the signature, the generated parameters are returned; otherwise `null` is returned." > > With this modification of 2nd sentence. The whole paragraph becomes: > > *

The returned parameters may be the same that were used to initialize > * this signature, or may contain additional default or random parameter > * values used by the underlying signature scheme. If the required > * parameters were not supplied and can be generated by the signature, > * the generated parameters are returned; otherwise {@code null} is > * returned. However, if the signature scheme does not support returning > * the parameters as {@code AlgorithmParameters}, {@code null} is always > * returned. > > For the last sentence, would it be better to use "also" instead of "always"? I think "also" would not be quite right, because I would read that as there is something else that is also returned with `null`. I think you can remove the word "always" -- it isn't really necessary and that might address your concern. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From duke at openjdk.java.net Mon May 16 15:32:41 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 16 May 2022 15:32:41 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: References: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com> <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com> Message-ID: On Fri, 13 May 2022 13:36:52 GMT, ExE Boss wrote: > So if anything, the List.of(?) call should be moved into the ProxyMethod constructor. And maybe the call to Method.getExceptionTypes() should be changed to Method.getSharedExceptionTypes() Makes sense. Do you want me to do this within this PR (this would be a deviation from ticket's target), or it's better to create another one? ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From jvernee at openjdk.java.net Mon May 16 16:36:35 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 16 May 2022 16:36:35 GMT Subject: RFR: 8286715: Generalize MemorySegment::ofBuffer In-Reply-To: References: Message-ID: On Fri, 13 May 2022 12:33:10 GMT, Maurizio Cimadamore wrote: > This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`. > This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function. > > We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`. > So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`. > > In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case. Marked as reviewed by jvernee (Reviewer). src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 572: > 570: return new NativeMemorySegmentImpl(bbAddress + (pos << scaleFactor), size << scaleFactor, modes, bufferSession); > 571: } else { > 572: // we can ignore scale factor here, a mapped buffer is always a byte buffer, so scaleFactor == 1. Suggestion: // we can ignore scale factor here, a mapped buffer is always a byte buffer, so scaleFactor == 0. ------------- PR: https://git.openjdk.java.net/jdk/pull/8701 From weijun at openjdk.java.net Mon May 16 17:02:48 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 16 May 2022 17:02:48 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v5] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:55:40 GMT, Mat Carter wrote: >> Mat Carter has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test from wangweij > > @christophbrejla - my goal is to backport to latest (18 or 19), 17 and 11 @macarte I think Sean's comment on your CSR about the scope is correct. The "algorithm" name should be at the JDK level so user knows what to write in their app. Once you think there's no more to update, you can finalize the CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From mullan at openjdk.java.net Mon May 16 17:20:43 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 16 May 2022 17:20:43 GMT Subject: RFR: 8286090: Add RC2/RC4 to jdk.security.legacyAlgorithms In-Reply-To: References: Message-ID: On Sat, 14 May 2022 01:51:34 GMT, Hai-May Chao wrote: > Please review the small change to add RC2 and ARCFOUR to jdk.security.legacyAlgorithms. So it enables keytool -genseckey, -list, and -importkeystore commands to warn users when RC2 or ARCFOUR algorithm is used. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8712 From mullan at openjdk.java.net Mon May 16 17:20:43 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 16 May 2022 17:20:43 GMT Subject: RFR: 8286090: Add RC2/RC4 to jdk.security.legacyAlgorithms In-Reply-To: References: Message-ID: On Mon, 16 May 2022 12:59:09 GMT, Sean Mullan wrote: >> Please review the small change to add RC2 and ARCFOUR to jdk.security.legacyAlgorithms. So it enables keytool -genseckey, -list, and -importkeystore commands to warn users when RC2 or ARCFOUR algorithm is used. > > test/jdk/sun/security/tools/keytool/WeakSecretKeyTest.java line 67: > >> 65: >> 66: SecurityTools.keytool("-keystore ks.p12 -storepass changeit " + >> 67: "-genseckey -keyalg RC4 -alias rc4key -keysize 1024") > > `-keysize` should be 128. Oops, I stand corrected. 1024 is a valid RC4 key size. ------------- PR: https://git.openjdk.java.net/jdk/pull/8712 From duke at openjdk.java.net Mon May 16 20:40:43 2022 From: duke at openjdk.java.net (Mat Carter) Date: Mon, 16 May 2022 20:40:43 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v5] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 16:59:02 GMT, Weijun Wang wrote: >> @christophbrejla - my goal is to backport to latest (18 or 19), 17 and 11 > > @macarte I think Sean's comment on your CSR about the scope is correct. The "algorithm" name should be at the JDK level so user knows what to write in their app. Once you think there's no more to update, you can finalize the CSR. Appologies i misread the process - waiting for @wangweij to approve ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From mcimadamore at openjdk.java.net Mon May 16 20:56:26 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 16 May 2022 20:56:26 GMT Subject: RFR: 8286715: Generalize MemorySegment::ofBuffer [v2] In-Reply-To: References: Message-ID: > This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`. > This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function. > > We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`. > So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`. > > In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8701/files - new: https://git.openjdk.java.net/jdk/pull/8701/files/02494e2f..b6629787 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8701&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8701&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8701.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8701/head:pull/8701 PR: https://git.openjdk.java.net/jdk/pull/8701 From ascarpino at openjdk.java.net Mon May 16 21:11:37 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 16 May 2022 21:11:37 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer [v2] In-Reply-To: <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com> References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com> Message-ID: On Sat, 14 May 2022 03:29:14 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation >> >> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision. >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - review update > - update some nits > - PR ready > - Initial There is too much grey area. It says the src buffer maybe modified, which one could interpret it cannot be a read-only, but that would still need clarification to explicitly say "no read only buffers". And other than these internal 'in-place' crypto reason, there is no API reason to not allow read-only buffers as input. I did think about closing the CSR as the text was already there about the src buffer, even thought it was using a different term. But I felt strongly enough that I wanted to prevent that confusion in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From xuelei at openjdk.java.net Mon May 16 22:49:39 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 16 May 2022 22:49:39 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer [v2] In-Reply-To: References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com> Message-ID: <8OHZl5E-vk4kdhFQuUylRxmFDIhcwTPGYJ_hVQXeyy0=.efd4d05b-22de-4220-849b-6a262efabcbe@github.com> On Mon, 16 May 2022 21:08:48 GMT, Anthony Scarpino wrote: > There is too much grey area. It says the src buffer maybe modified, which one could interpret it cannot be a read-only, but that would still need clarification to explicitly say "no read only buffers". And other than these internal 'in-place' crypto reason, there is no API reason to not allow read-only buffers as input. I did think about closing the CSR as the text was already there about the src buffer, even thought it was using a different term. But I felt strongly enough that I wanted to prevent that confusion in the future. I think it is good to make the clarification with a CSR. As the spec says, "The inbound network buffer, {@code src}, may be modified", applications cannot assume that the inbound network buffer cannot be modified (read-only) any longer. It does not grant that an application will work with read-only inbound buffers for another JSSE provider. As a result, an application that want to support read-only buffers may also need to support non-read-only buffers. As makes it more complicated in both application layers and the JSSE implementation layer. It may be simple that applications and JSSE implementation codes only need to handle non-read-only buffers. Just my $0.02. I will let you and Brad for the final decision. ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From valeriep at openjdk.java.net Mon May 16 23:18:20 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 16 May 2022 23:18:20 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v8] In-Reply-To: References: Message-ID: > This is to update the method javadoc of java.security.Signature.getParameters() with the missing `@throws UnsupportedOperationException`. In addition, the wording on the returned parameters are updated to match those in Cipher and CipherSpi classes. > > CSR will be filed later. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: review feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8396/files - new: https://git.openjdk.java.net/jdk/pull/8396/files/68b36fc1..94a584bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=06-07 Stats: 12 lines in 2 files changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8396/head:pull/8396 PR: https://git.openjdk.java.net/jdk/pull/8396 From valeriep at openjdk.java.net Mon May 16 23:18:21 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 16 May 2022 23:18:21 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v7] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 13:28:13 GMT, Sean Mullan wrote: >> With this modification of 2nd sentence. The whole paragraph becomes: >> >> *

The returned parameters may be the same that were used to initialize >> * this signature, or may contain additional default or random parameter >> * values used by the underlying signature scheme. If the required >> * parameters were not supplied and can be generated by the signature, >> * the generated parameters are returned; otherwise {@code null} is >> * returned. However, if the signature scheme does not support returning >> * the parameters as {@code AlgorithmParameters}, {@code null} is always >> * returned. >> >> For the last sentence, would it be better to use "also" instead of "always"? > > I think "also" would not be quite right, because I would read that as there is something else that is also returned with `null`. I think you can remove the word "always" -- it isn't really necessary and that might address your concern. Max suggested moving the last sentence to a new paragraph, so I did that and leave the "always" in. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From weijun at openjdk.java.net Tue May 17 02:01:38 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 17 May 2022 02:01:38 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v6] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:01:39 GMT, Mat Carter wrote: >> On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. >> >> "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc >> >> No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode >> >> Tested on windows, passes tier1 and tier2 tests > > Mat Carter has updated the pull request incrementally with one additional commit since the last revision: > > Change admin privilege test to reliable method Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Tue May 17 02:45:49 2022 From: duke at openjdk.java.net (Mat Carter) Date: Tue, 17 May 2022 02:45:49 GMT Subject: Integrated: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider In-Reply-To: References: Message-ID: <9h5vhplrdA-TjPgj2PP6XXZLzpSgN3s28adCj7kt9rw=.fe1a0a63-a09f-48d1-8a35-814147cafe2b@github.com> On Tue, 12 Apr 2022 19:03:40 GMT, Mat Carter wrote: > On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. > > "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the current user, I added "Windows-MY-CURRENTUSER" and "Windows-ROOT-CURRENTUSER" so that a developer can explicitly specify the current user location. These two new strings simply map to the original two strings, i.e. no duplication of code paths etc > > No new tests added, keystore functionality and API remains unchanged, the local machine keystore types would require the tests to run in admin mode > > Tested on windows, passes tier1 and tier2 tests This pull request has now been integrated. Changeset: 5e5500cb Author: Mat Carter <54955201+macarte at users.noreply.github.com> Committer: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/5e5500cbd79b40a32c20547ea0cdb81ef6904a3d Stats: 187 lines in 5 files changed: 155 ins; 1 del; 31 mod 6782021: It is not possible to read local computer certificates with the SunMSCAPI provider Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From xuelei at openjdk.java.net Tue May 17 05:03:00 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 17 May 2022 05:03:00 GMT Subject: RFR: 8284926: Share the certificate NamedGroup in SignatureScheme::getSignerOfPreferableAlgorithm [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 12:37:15 GMT, John Jiang wrote: >> It would not to generate the certificate's ECParameterSpec and NamedGroup multiple times in method `SignatureScheme::getSignerOfPreferableAlgorithm`. > > John Jiang has updated the pull request incrementally with one additional commit since the last revision: > > cache ParamSpec and NamedGroup in X509Possession src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchange.java line 274: > 272: // Iteratively determine the X509Possession type's ParameterSpec. > 273: ECParameterSpec ecParams = x509Possession.getECParameterSpec(); > 274: NamedParameterSpec namedParams = x509Possession.getXECParameterSpec(); It may not necessary to define 'ecParams' and 'namedParams' any longer, which was used to find out the named group. Now, the checking could be placed on the "namedGroup" (if the named group is EC/CDH) around line 293. src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 476: > 474: PrivateKey signingKey = x509Possession.popPrivateKey; > 475: > 476: ECParameterSpec params = x509Possession.getECParameterSpec(); This 'params' variable is used for debug only. Maybe, it could be moved to the debug log block. src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 157: > 155: } > 156: > 157: private ECParameterSpec getECParams() { 'getECParamSpec' may be a better method name. src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 182: > 180: > 181: // Similar to above, but for XEC. > 182: private NamedParameterSpec getXECParams() { 'getXECParamSpec' may be a better method name. ------------- PR: https://git.openjdk.java.net/jdk/pull/8271 From jjiang at openjdk.java.net Tue May 17 11:06:28 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Tue, 17 May 2022 11:06:28 GMT Subject: RFR: 8284926: Share the certificate NamedGroup in SignatureScheme::getSignerOfPreferableAlgorithm [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 12:37:15 GMT, John Jiang wrote: >> It would not to generate the certificate's ECParameterSpec and NamedGroup multiple times in method `SignatureScheme::getSignerOfPreferableAlgorithm`. > > John Jiang has updated the pull request incrementally with one additional commit since the last revision: > > cache ParamSpec and NamedGroup in X509Possession @XueleiFan Just submitted a new commit and addressed your comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/8271 From jjiang at openjdk.java.net Tue May 17 11:06:28 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Tue, 17 May 2022 11:06:28 GMT Subject: RFR: 8284926: Share the certificate NamedGroup in SignatureScheme::getSignerOfPreferableAlgorithm [v3] In-Reply-To: References: Message-ID: <9Rt9O4ga083z8W5RLysEd3jQHKqI3xIKV3dbtnQyoyA=.856d4994-35a8-42f5-8528-3eb77fdd5c93@github.com> > It would not to generate the certificate's ECParameterSpec and NamedGroup multiple times in method `SignatureScheme::getSignerOfPreferableAlgorithm`. John Jiang has updated the pull request incrementally with one additional commit since the last revision: add some comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8271/files - new: https://git.openjdk.java.net/jdk/pull/8271/files/eb706ae8..cd6e6dba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8271&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8271&range=01-02 Stats: 36 lines in 3 files changed: 9 ins; 12 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8271.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8271/head:pull/8271 PR: https://git.openjdk.java.net/jdk/pull/8271 From valeriep at openjdk.java.net Tue May 17 18:40:58 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 17 May 2022 18:40:58 GMT Subject: Integrated: 8209038: Clarify the javadoc of Cipher.getParameters() In-Reply-To: References: Message-ID: <4sgKj0zDB7UhlMxzGH-6C1y5JLhlrsBkOuLIaIr3HWA=.307a8513-5b97-49c1-b36b-df59d813f219@github.com> On Wed, 6 Apr 2022 00:14:04 GMT, Valerie Peng wrote: > Anyone can help review this javadoc update? The main change is the wording for the method javadoc of Cipher.getParameters()/CipherSpi.engineGetParameters(). The original wording is somewhat restrictive and request is to broaden this to accommodate more scenarios such as when null can be returned. > The rest are minor things like add {@code } to class name and null, and remove redundant ".". > > Will file CSR after the review is close to being wrapped up. > Thanks~ This pull request has now been integrated. Changeset: 0c5ab6da Author: Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/0c5ab6daa93cd063d8fa54880f7b1aa981c27c5f Stats: 417 lines in 2 files changed: 3 ins; 5 del; 409 mod 8209038: Clarify the javadoc of Cipher.getParameters() Reviewed-by: xuelei, mullan, weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From weijun at openjdk.java.net Tue May 17 19:00:00 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 17 May 2022 19:00:00 GMT Subject: RFR: 8002277: Refactor two PBE classes to simplify maintenance [v8] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 22:52:59 GMT, Valerie Peng wrote: >> This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > reset ivSpec and minor nit fix. Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From weijun at openjdk.java.net Tue May 17 20:05:07 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 17 May 2022 20:05:07 GMT Subject: RFR: 8286908: ECDSA signature should not return parameters Message-ID: Let ECDSA's `engineGetParameters()` always return null. At the same time, remove the remembered `sigParams` field. One behavior change is that after calling `setParameter()`, one can call `init()` again with a key using different parameters. I think this should be allowed since we are reusing the signature object with a brand new key. `setParameter` is kept unchanged to be able to deal with certificates still having parameters after the signature algorithm object identifier. See https://bugs.openjdk.java.net/browse/JDK-8225745. Also added SHA1withECDSA to the no-NULL list in `KnownOIDs`. ------------- Commit messages: - the fix Changes: https://git.openjdk.java.net/jdk/pull/8758/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8758&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286908 Stats: 96 lines in 3 files changed: 59 ins; 29 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8758.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8758/head:pull/8758 PR: https://git.openjdk.java.net/jdk/pull/8758 From jnimeh at openjdk.java.net Tue May 17 20:30:54 2022 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Tue, 17 May 2022 20:30:54 GMT Subject: RFR: 8286908: ECDSA signature should not return parameters In-Reply-To: References: Message-ID: <1shIFw3xkR4BMlD4j2w1wD84zkxH8apcBTEwgj4MrQY=.ba4b87dc-4384-4b8a-8a06-4a81de544f50@github.com> On Tue, 17 May 2022 19:56:22 GMT, Weijun Wang wrote: > Let ECDSA's `engineGetParameters()` always return null. At the same time, remove the remembered `sigParams` field. One behavior change is that after calling `setParameter()`, one can call `init()` again with a key using different parameters. I think this should be allowed since we are reusing the signature object with a brand new key. > > `setParameter` is kept unchanged to be able to deal with certificates still having parameters after the signature algorithm object identifier. See https://bugs.openjdk.java.net/browse/JDK-8225745. > > Also added SHA1withECDSA to the no-NULL list in `KnownOIDs`. Do the behavioral changes you've cited in the PR description warrant a CSR, or do you feel this behavioral change is still consistent with the current Signature API documentation? ------------- PR: https://git.openjdk.java.net/jdk/pull/8758 From weijun at openjdk.java.net Tue May 17 20:40:55 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 17 May 2022 20:40:55 GMT Subject: RFR: 8286908: ECDSA signature should not return parameters In-Reply-To: <1shIFw3xkR4BMlD4j2w1wD84zkxH8apcBTEwgj4MrQY=.ba4b87dc-4384-4b8a-8a06-4a81de544f50@github.com> References: <1shIFw3xkR4BMlD4j2w1wD84zkxH8apcBTEwgj4MrQY=.ba4b87dc-4384-4b8a-8a06-4a81de544f50@github.com> Message-ID: On Tue, 17 May 2022 20:27:41 GMT, Jamil Nimeh wrote: > Do the behavioral changes you've cited in the PR description warrant a CSR, or do you feel this behavioral change is still consistent with the current Signature API documentation? I think so. In fact, after this change, there's simply no parameters for the signature, so calling `setParameter` should not change any internal state and thus has no effect on other calls. While this is a behavior change, I don't think it has any negative impact to users. ------------- PR: https://git.openjdk.java.net/jdk/pull/8758 From valeriep at openjdk.java.net Tue May 17 20:59:58 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 17 May 2022 20:59:58 GMT Subject: Integrated: 8002277: Refactor two PBE classes to simplify maintenance In-Reply-To: References: Message-ID: <2pSb3CxjBxucl-zTVhjaKLEl6jeirSU64s0Rers6Vsk=.6dd630b3-8aa3-47f6-89fd-b37e8b57d524@github.com> On Tue, 3 May 2022 19:30:40 GMT, Valerie Peng wrote: > This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE provider as requested in the bug record. Functionality should remain the same with a clearer and simplified code/control flow with less lines of code. This should improve readability and maintenance. I enhanced one existing regression test to test more scenarios. This test would pass before the proposed change and continues to pass with the proposed changes. This pull request has now been integrated. Changeset: 61ddbef3 Author: Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/61ddbef3681770b7a1f56456f686fcb176063329 Stats: 733 lines in 6 files changed: 185 ins; 402 del; 146 mod 8002277: Refactor two PBE classes to simplify maintenance Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/8521 From ascarpino at openjdk.java.net Tue May 17 21:25:55 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 17 May 2022 21:25:55 GMT Subject: RFR: 8286908: ECDSA signature should not return parameters In-Reply-To: References: Message-ID: On Tue, 17 May 2022 19:56:22 GMT, Weijun Wang wrote: > Let ECDSA's `engineGetParameters()` always return null. At the same time, remove the remembered `sigParams` field. One behavior change is that after calling `setParameter()`, one can call `init()` again with a key using different parameters. I think this should be allowed since we are reusing the signature object with a brand new key. > > `setParameter` is kept unchanged to be able to deal with certificates still having parameters after the signature algorithm object identifier. See https://bugs.openjdk.java.net/browse/JDK-8225745. > > Also added SHA1withECDSA to the no-NULL list in `KnownOIDs`. > > All security-related tests passed. Marked as reviewed by ascarpino (Reviewer). Looks good to me. The changes seem within the spec to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/8758 From ascarpino at openjdk.java.net Tue May 17 21:42:04 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 17 May 2022 21:42:04 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer [v2] In-Reply-To: <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com> References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> <91IvgD0-TEZVcvihQrpU1eBXhfScJeo_Kp8KphVUOFc=.d682d311-9c9e-4446-b49a-356e617a7028@github.com> Message-ID: <8VOhl2ipKsUgpystX7M8sDiDHhNfDVYWA0x1npAWf4s=.0fb01b2b-cd78-4a59-8533-c912ffbeb078@github.com> On Sat, 14 May 2022 03:29:14 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation >> >> The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision. >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - review update > - update some nits > - PR ready > - Initial I think read-only has been allowed by the spec from the start, we just never allowed it to work properly. I don't think this opens up possible complications in the code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From ascarpino at openjdk.java.net Tue May 17 21:42:07 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 17 May 2022 21:42:07 GMT Subject: Integrated: 8283577: SSLEngine.unwrap on read-only input ByteBuffer In-Reply-To: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> References: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@github.com> Message-ID: <8gT7YpYQtrAe7iXCq6peNX13K1dSTDbznWmvPERWTCg=.74d3093e-b694-4f7e-9564-cbe936cffba0@github.com> On Fri, 29 Apr 2022 03:58:57 GMT, Anthony Scarpino wrote: > Hi, > > I need a review of this fix to allow a read-only 'src' buffer to be used with SSLEngine.unwrap(). A temporary read-write buffer is created in the SSLCipher operation when a read-only buffer is passed. If the 'src' is read-write, there is no effect on the current operation > > The PR also includes a CSR for an API implementation note to the SSLEngine.unwrap. The 'src' buffer may be modified during the decryption operation. 'unwrap()' has had this behavior forever, so there is no compatibility issue with this note. Using the 'src' buffer for in-place decryption was a performance decision. > > Tony This pull request has now been integrated. Changeset: f17c68ce Author: Anthony Scarpino URL: https://git.openjdk.java.net/jdk/commit/f17c68ce4a0b4f5c3131f4e4626a5a55b7f2f61f Stats: 393 lines in 3 files changed: 291 ins; 20 del; 82 mod 8283577: SSLEngine.unwrap on read-only input ByteBuffer Reviewed-by: wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/8462 From hchao at openjdk.java.net Tue May 17 21:48:49 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 17 May 2022 21:48:49 GMT Subject: RFR: 8286090: Add RC2/RC4 to jdk.security.legacyAlgorithms In-Reply-To: References: Message-ID: On Mon, 16 May 2022 17:17:24 GMT, Sean Mullan wrote: >> Please review the small change to add RC2 and ARCFOUR to jdk.security.legacyAlgorithms. So it enables keytool -genseckey, -list, and -importkeystore commands to warn users when RC2 or ARCFOUR algorithm is used. > > Marked as reviewed by mullan (Reviewer). @seanjmullan Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8712 From hchao at openjdk.java.net Tue May 17 21:51:56 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 17 May 2022 21:51:56 GMT Subject: Integrated: 8286090: Add RC2/RC4 to jdk.security.legacyAlgorithms In-Reply-To: References: Message-ID: On Sat, 14 May 2022 01:51:34 GMT, Hai-May Chao wrote: > Please review the small change to add RC2 and ARCFOUR to jdk.security.legacyAlgorithms. So it enables keytool -genseckey, -list, and -importkeystore commands to warn users when RC2 or ARCFOUR algorithm is used. This pull request has now been integrated. Changeset: 2ed75be6 Author: Hai-May Chao URL: https://git.openjdk.java.net/jdk/commit/2ed75be659503da584cfec9ead5e27665ae900ef Stats: 20 lines in 2 files changed: 18 ins; 0 del; 2 mod 8286090: Add RC2/RC4 to jdk.security.legacyAlgorithms Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/8712 From valeriep at openjdk.java.net Tue May 17 22:22:36 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 17 May 2022 22:22:36 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v9] In-Reply-To: References: Message-ID: > This is to update the method javadoc of java.security.Signature.getParameters() with the missing `@throws UnsupportedOperationException`. In addition, the wording on the returned parameters are updated to match those in Cipher and CipherSpi classes. > > CSR will be filed later. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: more minor cleanups for consistencies. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8396/files - new: https://git.openjdk.java.net/jdk/pull/8396/files/94a584bc..681a5bc4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=07-08 Stats: 43 lines in 2 files changed: 4 ins; 0 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/8396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8396/head:pull/8396 PR: https://git.openjdk.java.net/jdk/pull/8396 From hchao at openjdk.java.net Tue May 17 23:09:42 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 17 May 2022 23:09:42 GMT Subject: RFR: 8286908: ECDSA signature should not return parameters In-Reply-To: References: Message-ID: <7phxPgdYeXUlhwyB6cQ9y9OiwQABgOpEKk8fnqKIvOs=.1f6013ee-57c2-4515-a426-7a65bbd902a3@github.com> On Tue, 17 May 2022 19:56:22 GMT, Weijun Wang wrote: > Let ECDSA's `engineGetParameters()` always return null. At the same time, remove the remembered `sigParams` field. One behavior change is that after calling `setParameter()`, one can call `init()` again with a key using different parameters. I think this should be allowed since we are reusing the signature object with a brand new key. > > `setParameter` is kept unchanged to be able to deal with certificates still having parameters after the signature algorithm object identifier. See https://bugs.openjdk.java.net/browse/JDK-8225745. > > Also added SHA1withECDSA to the no-NULL list in `KnownOIDs`. > > All security-related tests passed. Marked as reviewed by hchao (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8758 From weijun at openjdk.java.net Tue May 17 23:14:56 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 17 May 2022 23:14:56 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v9] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 22:22:36 GMT, Valerie Peng wrote: >> This is to update the method javadoc of java.security.Signature.getParameters() with the missing `@throws UnsupportedOperationException`. In addition, the wording on the returned parameters are updated to match those in Cipher and CipherSpi classes. >> >> CSR will be filed later. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > more minor cleanups for consistencies. src/java.base/share/classes/java/security/SignatureSpi.java line 377: > 375: * > 376: *

This method is overridden by providers to initialize > 377: * this signature object with the specified parameter set. 1st paragraph: values, 2nd: set. Make them the same. src/java.base/share/classes/java/security/SignatureSpi.java line 397: > 395: * > 396: *

This method is overridden by providers to return the parameters > 397: * used with this signature object. The 2 paragraphs above look the same. Of course, if you believe the 1st paragraph should always be a simple description, that's OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From duke at openjdk.java.net Wed May 18 04:47:13 2022 From: duke at openjdk.java.net (Mark Powers) Date: Wed, 18 May 2022 04:47:13 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v7] In-Reply-To: References: Message-ID: <2sUBPokwZm7uX8L72d8crxyHWVHrXTugA60pNoyE8Xo=.3a07843b-2ffe-4dc0-8022-ee504a6baf8d@github.com> > https://bugs.openjdk.java.net/browse/JDK-8284688 > > [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: > > open/src/java.security.jgss/share/classes/javax/security > open/src/java.security.jgss/share/classes/org/ietf > open/src/java.security.jgss/share/classes/sun/security Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge - reverse IntelliJ unboxing suggestion - Merge - Merge - Merge - Brad comments - Max comments - sixth iteration - Merge - fifth iteration - ... and 8 more: https://git.openjdk.java.net/jdk/compare/2ed75be6...30ca27a2 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7746/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7746&range=06 Stats: 894 lines in 72 files changed: 96 ins; 193 del; 605 mod Patch: https://git.openjdk.java.net/jdk/pull/7746.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7746/head:pull/7746 PR: https://git.openjdk.java.net/jdk/pull/7746 From duke at openjdk.java.net Wed May 18 08:46:08 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 18 May 2022 08:46:08 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v4] In-Reply-To: References: Message-ID: <3DlU-JyFxA4D-e10Rh5qdEpsb3dbPMtfKrdqEHTbWkM=.a7ae971e-908c-495d-b7b4-8f833839fd7d@github.com> > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - 8282662: Revert ProxyGenerator - 8282662: Revert ProxyGenerator - 8282662: Revert dubious changes in MethodType - 8282662: Revert dubious changes - 8282662: Use List/Set.of() factory methods to save memory ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7729/files - new: https://git.openjdk.java.net/jdk/pull/7729/files/e765c42a..87c6623b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=02-03 Stats: 575367 lines in 7617 files changed: 421069 ins; 87224 del; 67074 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Wed May 18 08:46:09 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 18 May 2022 08:46:09 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: References: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com> <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com> Message-ID: On Mon, 16 May 2022 15:29:38 GMT, ?????? ??????? wrote: >> Even?in the?no?exceptions?case, the?`exceptionTypes`?array still?has to?be?allocated/copied by?`Method.getExceptionTypes()`[^1] when?the?`ProxyMethod`?constructor[^2] is?invoked. >> >> So?if?anything, the?`List.of(?)`?call should?be?moved into?the?`ProxyMethod`?constructor. >> And?maybe the?call to?`Method.getExceptionTypes()` should?be?changed to?`Method.getSharedExceptionTypes()`[^3]. >> >> [^1]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/Method.java#L340-L343 >> [^2]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L710-L714 >> [^3]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/Method.java#L305-L308 > >> So if anything, the List.of(?) call should be moved into the ProxyMethod constructor. And maybe the call to Method.getExceptionTypes() should be changed to Method.getSharedExceptionTypes() > > Makes sense. Do you want me to do this within this PR (this would be a deviation from ticket's target), or it's better to create another one? Ok, I've reverted `ProxyGenerator` and will include the changes into another PR ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From aivanov at openjdk.java.net Wed May 18 13:34:24 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 18 May 2022 13:34:24 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base Message-ID: Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? Also, I fixed a couple of spelling mistakes. ------------- Commit messages: - 8284191: Replace usages of 'the an' in hotspot and java.base - 8284191: Replace usages of 'the an' in hotspot and java.base - 8284191: Replace usages of 'the an' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - ... and 13 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...c7e73658 Changes: https://git.openjdk.java.net/jdk/pull/8768/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284191 Stats: 202 lines in 162 files changed: 0 ins; 11 del; 191 mod Patch: https://git.openjdk.java.net/jdk/pull/8768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768 PR: https://git.openjdk.java.net/jdk/pull/8768 From lancea at openjdk.java.net Wed May 18 14:42:53 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 18 May 2022 14:42:53 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From duke at openjdk.java.net Wed May 18 14:48:16 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 18 May 2022 14:48:16 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v5] In-Reply-To: References: Message-ID: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - 8282662: Revert wrong copyright year change - 8282662: Revert ProxyGenerator - 8282662: Revert ProxyGenerator - 8282662: Revert dubious changes in MethodType - 8282662: Revert dubious changes - 8282662: Use List/Set.of() factory methods to save memory ------------- Changes: https://git.openjdk.java.net/jdk/pull/7729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=04 Stats: 12 lines in 4 files changed: 1 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From aivanov at openjdk.java.net Wed May 18 14:53:28 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 18 May 2022 14:53:28 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code Message-ID: Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? It's the last issue in the series, and it still touches different areas of the code. ------------- Commit messages: - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'an? an?' in source code - 8284209: Replace remaining usages of 'a the' in source code - 8284209: Replace remaining usages of 'an the' in source code - ... and 1 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...8290c07e Changes: https://git.openjdk.java.net/jdk/pull/8771/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284209 Stats: 51 lines in 41 files changed: 0 ins; 2 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/8771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771 PR: https://git.openjdk.java.net/jdk/pull/8771 From lancea at openjdk.java.net Wed May 18 14:59:56 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 18 May 2022 14:59:56 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8771 From wetmore at openjdk.java.net Wed May 18 15:15:56 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 18 May 2022 15:15:56 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Looked at - java.base/.../sun/security - jdk.crypto.* - test/*/com/sun/crypto/provider - test/*/java/lang/SecurityManager - test/*/java/security - test/*/krb5 - test/*/jarsigner and those look fine. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8768 From wetmore at openjdk.java.net Wed May 18 15:19:55 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 18 May 2022 15:19:55 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. Looked at -java.security.jgss. LGTM ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8771 From mullan at openjdk.java.net Wed May 18 15:32:44 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 18 May 2022 15:32:44 GMT Subject: RFR: 8286908: ECDSA signature should not return parameters In-Reply-To: References: Message-ID: On Tue, 17 May 2022 19:56:22 GMT, Weijun Wang wrote: > Let ECDSA's `engineGetParameters()` always return null. At the same time, remove the remembered `sigParams` field. One behavior change is that after calling `setParameter()`, one can call `init()` again with a key using different parameters. I think this should be allowed since we are reusing the signature object with a brand new key. > > `setParameter` is kept unchanged to be able to deal with certificates still having parameters after the signature algorithm object identifier. See https://bugs.openjdk.java.net/browse/JDK-8225745. > > Also added SHA1withECDSA to the no-NULL list in `KnownOIDs`. > > All security-related tests passed. src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSASignature.java line 518: > 516: } > 517: if (!(params instanceof ECParameterSpec ecparams)) { > 518: throw new InvalidAlgorithmParameterException("No parameter accepted"); This is an odd error message since it does accept ECParameterSpec. Suggest changing the message to "Parameters must be of type ECParameterSpec". ------------- PR: https://git.openjdk.java.net/jdk/pull/8758 From dfuchs at openjdk.java.net Wed May 18 16:07:52 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 18 May 2022 16:07:52 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. Logging/JNDI OK ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8771 From naoto at openjdk.java.net Wed May 18 16:18:58 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 18 May 2022 16:18:58 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: <4eXpe5pmBsvw8u6fJlzd9BWsnY74LiyjTqQhQ88uxoc=.6182985a-f751-4d55-b9d0-bc605d7636da@github.com> On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. LGTM for i18n changes. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8768 From ssahoo at openjdk.java.net Wed May 18 16:27:13 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Wed, 18 May 2022 16:27:13 GMT Subject: RFR: 8286969: Add a new test library API to execute kinit in SecurityTools.java Message-ID: A new API to execute kinit. ------------- Commit messages: - 8286969: Add a new test library API to execute kinit in SecurityTools.java Changes: https://git.openjdk.java.net/jdk/pull/8775/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8775&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286969 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8775.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8775/head:pull/8775 PR: https://git.openjdk.java.net/jdk/pull/8775 From iris at openjdk.java.net Wed May 18 16:59:50 2022 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 18 May 2022 16:59:50 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From iris at openjdk.java.net Wed May 18 17:04:50 2022 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 18 May 2022 17:04:50 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8771 From rhalade at openjdk.java.net Wed May 18 17:59:39 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 18 May 2022 17:59:39 GMT Subject: RFR: 8286969: Add a new test library API to execute kinit in SecurityTools.java In-Reply-To: References: Message-ID: <2lwfnvF5wNbS-iceOL54w9SZ3t0Ka29rs8P2R6cHLro=.ef72f214-87ea-48cf-b550-856f36572db5@github.com> On Wed, 18 May 2022 16:19:40 GMT, Sibabrata Sahoo wrote: > A new API to execute kinit. Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8775 From jjg at openjdk.java.net Wed May 18 22:06:44 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 18 May 2022 22:06:44 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. javac and javadoc changes look OK test/langtools/tools/javac/modules/T8168854/module-info.java line 4: > 2: * @test > 3: * @bug 8168854 > 4: * @summary javac erroneously reject a service interface inner class in a provides clause FYI, this duplication was in the JBS issue summary; now fixed there. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8771 From weijun at openjdk.java.net Wed May 18 22:27:18 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 18 May 2022 22:27:18 GMT Subject: RFR: 8286908: ECDSA signature should not return parameters [v2] In-Reply-To: References: Message-ID: <4JcLq4H3Yp3LgURkhR0gwmQaPOpJrxuJWjlxq_4Opeg=.78aca1f4-cafe-406b-bd34-7a92c8dee773@github.com> > Let ECDSA's `engineGetParameters()` always return null. At the same time, remove the remembered `sigParams` field. One behavior change is that after calling `setParameter()`, one can call `init()` again with a key using different parameters. I think this should be allowed since we are reusing the signature object with a brand new key. > > `setParameter` is kept unchanged to be able to deal with certificates still having parameters after the signature algorithm object identifier. See https://bugs.openjdk.java.net/browse/JDK-8225745. > > Also added SHA1withECDSA to the no-NULL list in `KnownOIDs`. > > All security-related tests passed. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: will not read params for ECDSA ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8758/files - new: https://git.openjdk.java.net/jdk/pull/8758/files/b13de5a9..aceeb4a7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8758&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8758&range=00-01 Stats: 13 lines in 2 files changed: 1 ins; 8 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8758.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8758/head:pull/8758 PR: https://git.openjdk.java.net/jdk/pull/8758 From valeriep at openjdk.java.net Wed May 18 22:33:39 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 18 May 2022 22:33:39 GMT Subject: RFR: 8286908: ECDSA signature should not return parameters [v2] In-Reply-To: <4JcLq4H3Yp3LgURkhR0gwmQaPOpJrxuJWjlxq_4Opeg=.78aca1f4-cafe-406b-bd34-7a92c8dee773@github.com> References: <4JcLq4H3Yp3LgURkhR0gwmQaPOpJrxuJWjlxq_4Opeg=.78aca1f4-cafe-406b-bd34-7a92c8dee773@github.com> Message-ID: <_9K2tSZIi39wKjkNLfsxCAzU-_UKbtby4ZxU9OBKLVE=.c1f8704a-fedd-428a-810e-865cc22347e9@github.com> On Wed, 18 May 2022 22:27:18 GMT, Weijun Wang wrote: >> Let ECDSA's `engineGetParameters()` always return null. At the same time, remove the remembered `sigParams` field. One behavior change is that after calling `setParameter()`, one can call `init()` again with a key using different parameters. I think this should be allowed since we are reusing the signature object with a brand new key. >> >> `setParameter` is kept unchanged to be able to deal with certificates still having parameters after the signature algorithm object identifier. See https://bugs.openjdk.java.net/browse/JDK-8225745. >> >> Also added SHA1withECDSA to the no-NULL list in `KnownOIDs`. >> >> All security-related tests passed. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > will not read params for ECDSA Looks fine. ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8758 From valeriep at openjdk.java.net Wed May 18 22:37:36 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 18 May 2022 22:37:36 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v9] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 23:11:06 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> more minor cleanups for consistencies. > > src/java.base/share/classes/java/security/SignatureSpi.java line 377: > >> 375: * >> 376: *

This method is overridden by providers to initialize >> 377: * this signature object with the specified parameter set. > > 1st paragraph: values, 2nd: set. Make them the same. Will also remove the second sentence here. Thanks. > src/java.base/share/classes/java/security/SignatureSpi.java line 397: > >> 395: * >> 396: *

This method is overridden by providers to return the parameters >> 397: * used with this signature object. > > The 2 paragraphs above look the same. Of course, if you believe the 1st paragraph should always be a simple description, that's OK. Yes, I will remove the second sentence to match the javadoc of other methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From valeriep at openjdk.java.net Wed May 18 22:42:18 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 18 May 2022 22:42:18 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v10] In-Reply-To: References: Message-ID: > This is to update the method javadoc of java.security.Signature.getParameters() with the missing `@throws UnsupportedOperationException`. In addition, the wording on the returned parameters are updated to match those in Cipher and CipherSpi classes. > > CSR will be filed later. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: rewording the UOE for Signature.getParameters() and remove redundant sentences from SignatureSpi class. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8396/files - new: https://git.openjdk.java.net/jdk/pull/8396/files/681a5bc4..d5d75d74 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=08-09 Stats: 8 lines in 2 files changed: 0 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8396/head:pull/8396 PR: https://git.openjdk.java.net/jdk/pull/8396 From hchao at openjdk.java.net Wed May 18 22:52:37 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 18 May 2022 22:52:37 GMT Subject: RFR: 8286908: ECDSA signature should not return parameters [v2] In-Reply-To: <4JcLq4H3Yp3LgURkhR0gwmQaPOpJrxuJWjlxq_4Opeg=.78aca1f4-cafe-406b-bd34-7a92c8dee773@github.com> References: <4JcLq4H3Yp3LgURkhR0gwmQaPOpJrxuJWjlxq_4Opeg=.78aca1f4-cafe-406b-bd34-7a92c8dee773@github.com> Message-ID: On Wed, 18 May 2022 22:27:18 GMT, Weijun Wang wrote: >> Let ECDSA's `engineGetParameters()` always return null. At the same time, remove the remembered `sigParams` field. One behavior change is that after calling `setParameter()`, one can call `init()` again with a key using different parameters. I think this should be allowed since we are reusing the signature object with a brand new key. >> >> `setParameter` is kept unchanged to be able to deal with certificates still having parameters after the signature algorithm object identifier. See https://bugs.openjdk.java.net/browse/JDK-8225745. >> >> Also added SHA1withECDSA to the no-NULL list in `KnownOIDs`. >> >> All security-related tests passed. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > will not read params for ECDSA src/java.base/share/classes/sun/security/util/SignatureUtil.java line 156: > 154: // Some certificates have params in an ECDSA algorithmID, > 155: // they are useless and should be ignored. > 156: return null; Suggest adding the RFC reference for this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8758 From duke at openjdk.java.net Thu May 19 00:38:43 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 19 May 2022 00:38:43 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v7] In-Reply-To: <2sUBPokwZm7uX8L72d8crxyHWVHrXTugA60pNoyE8Xo=.3a07843b-2ffe-4dc0-8022-ee504a6baf8d@github.com> References: <2sUBPokwZm7uX8L72d8crxyHWVHrXTugA60pNoyE8Xo=.3a07843b-2ffe-4dc0-8022-ee504a6baf8d@github.com> Message-ID: <9p2H9pbc-3xwcIsmlBx47TWo8a6HMuJJhzoID_C9PXY=.81de5168-7c1c-4d01-a960-73199b47d6d0@github.com> On Wed, 18 May 2022 04:47:13 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8284688 >> >> [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: >> >> open/src/java.security.jgss/share/classes/javax/security >> open/src/java.security.jgss/share/classes/org/ietf >> open/src/java.security.jgss/share/classes/sun/security > > Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge > - reverse IntelliJ unboxing suggestion > - Merge > - Merge > - Merge > - Brad comments > - Max comments > - sixth iteration > - Merge > - fifth iteration > - ... and 8 more: https://git.openjdk.java.net/jdk/compare/2ed75be6...30ca27a2 IntelliJ complains that unboxed values should be boxed, e.g. `Integer.valueOf()` should be changed to `Integer`. After some discussion, it has been decided to ignore IntelliJ's complaints and leave the code as written. To box or unbox is a matter of personal preference. The generated byte code is the same either way. ------------- PR: https://git.openjdk.java.net/jdk/pull/7746 From weijun at openjdk.java.net Thu May 19 01:50:35 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 19 May 2022 01:50:35 GMT Subject: RFR: 8286969: Add a new test library API to execute kinit in SecurityTools.java In-Reply-To: References: Message-ID: On Wed, 18 May 2022 16:19:40 GMT, Sibabrata Sahoo wrote: > A new API to execute kinit. Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8775 From weijun at openjdk.java.net Thu May 19 02:01:55 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 19 May 2022 02:01:55 GMT Subject: RFR: 8286908: ECDSA signature should not return parameters [v3] In-Reply-To: References: Message-ID: > Let ECDSA's `engineGetParameters()` always return null. At the same time, remove the remembered `sigParams` field. One behavior change is that after calling `setParameter()`, one can call `init()` again with a key using different parameters. I think this should be allowed since we are reusing the signature object with a brand new key. > > `setParameter` is kept unchanged to be able to deal with certificates still having parameters after the signature algorithm object identifier. See https://bugs.openjdk.java.net/browse/JDK-8225745. > > Also added SHA1withECDSA to the no-NULL list in `KnownOIDs`. > > All security-related tests passed. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - add reference to RFCs - Merge branch 'master' into 8286908 - will not read params for ECDSA - the fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8758/files - new: https://git.openjdk.java.net/jdk/pull/8758/files/aceeb4a7..e5043a99 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8758&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8758&range=01-02 Stats: 107875 lines in 1550 files changed: 65071 ins; 35256 del; 7548 mod Patch: https://git.openjdk.java.net/jdk/pull/8758.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8758/head:pull/8758 PR: https://git.openjdk.java.net/jdk/pull/8758 From duke at openjdk.java.net Thu May 19 03:39:41 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 19 May 2022 03:39:41 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v7] In-Reply-To: <2sUBPokwZm7uX8L72d8crxyHWVHrXTugA60pNoyE8Xo=.3a07843b-2ffe-4dc0-8022-ee504a6baf8d@github.com> References: <2sUBPokwZm7uX8L72d8crxyHWVHrXTugA60pNoyE8Xo=.3a07843b-2ffe-4dc0-8022-ee504a6baf8d@github.com> Message-ID: On Wed, 18 May 2022 04:47:13 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8284688 >> >> [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: >> >> open/src/java.security.jgss/share/classes/javax/security >> open/src/java.security.jgss/share/classes/org/ietf >> open/src/java.security.jgss/share/classes/sun/security > > Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge > - reverse IntelliJ unboxing suggestion > - Merge > - Merge > - Merge > - Brad comments > - Max comments > - sixth iteration > - Merge > - fifth iteration > - ... and 8 more: https://git.openjdk.java.net/jdk/compare/2ed75be6...30ca27a2 Mach5 tests all passed in spite of some failing pre-submit tests. bash ./jib.sh mach5 -- remote-build-and-test --email mark.powers at oracle.com -b linux-x64,windows-x64,macosx-x64 --job tier1,tier2 ------------- PR: https://git.openjdk.java.net/jdk/pull/7746 From ssahoo at openjdk.java.net Thu May 19 06:09:49 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Thu, 19 May 2022 06:09:49 GMT Subject: Integrated: 8286969: Add a new test library API to execute kinit in SecurityTools.java In-Reply-To: References: Message-ID: <8GSgtdOqeyhdWLRSRTomeeI_6mvtILREbXu6pkdd4-s=.3bf5f2f3-9a96-43ac-9c52-a8b980c6f3f2@github.com> On Wed, 18 May 2022 16:19:40 GMT, Sibabrata Sahoo wrote: > A new API to execute kinit. This pull request has now been integrated. Changeset: dbda0e2b Author: Sibabrata Sahoo URL: https://git.openjdk.java.net/jdk/commit/dbda0e2bda5d8ba86f068684941a05387947d993 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod 8286969: Add a new test library API to execute kinit in SecurityTools.java Reviewed-by: rhalade, weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/8775 From kevinw at openjdk.java.net Thu May 19 08:43:45 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 08:43:45 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/jdk.sctp/share/classes/com/sun/nio/sctp/ShutdownNotification.java line 28: > 26: > 27: /** > 28: * Notification emitted when a peers shutdowns the association. Maybe: "...when a peer shuts down an association." (could be "shuts down the association" if there is only ever one, but using "an" looks safe) ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From kevinw at openjdk.java.net Thu May 19 08:50:49 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 08:50:49 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348: > 346: > 347: /** > 348: * Returns the single non-abstract {@link Method} visible from I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many. ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From kevinw at openjdk.java.net Thu May 19 09:02:49 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:02:49 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/hotspot/share/opto/graphKit.cpp line 3626: > 3624: // The optional arguments are for specialized use by intrinsics: > 3625: // - If 'extra_slow_test' if not null is an extra condition for the slow-path. > 3626: // - If 'return_size_val', report the total object size to the caller. "reports the total" ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From kevinw at openjdk.java.net Thu May 19 09:09:50 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:09:50 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/hotspot/share/interpreter/bytecodeUtils.cpp line 186: > 184: static const int _max_cause_detail = 5; > 185: > 186: // Merges the stack the given bci with the given stack. If there "...the stack at the given bci..." ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From kevinw at openjdk.java.net Thu May 19 09:27:55 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:27:55 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: <02e6mwqZ3ihNyJb4lBK-5WeIGMfiLMj3I8LpJPv4i8o=.3c56077b-54f0-4c4e-b031-5a000b9ea887@github.com> On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/hotspot/share/cds/filemap.cpp line 1914: > 1912: > 1913: // the current value of the pointers to be patched must be within this > 1914: // range (i.e., must be between the requested base address, and the of the current archive). "the of the" ? Maybe "..and the address of the current archive", or maybe it was a typo for "and that of the current archive". ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From kevinw at openjdk.java.net Thu May 19 09:35:42 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:35:42 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com> On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 84: > 82: > 83: /** > 84: * Create a Zip file that will result in an Zip64 Extra (EXT) header "result in a Zip64..." test/jdk/sun/security/tools/jarsigner/OldSig.java line 32: > 30: /* > 31: * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily > 32: * formatted individual sections in addition the main attributes tested "in addition to the..." ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From kevinw at openjdk.java.net Thu May 19 09:41:57 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:41:57 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. OK. I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews. test/jdk/java/net/InterfaceAddress/Equals.java line 81: > 79: /** > 80: * Returns an InterfaceAddress instance with its fields set the values > 81: * specificed. probably a typo for "set to the values specified." ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.java.net/jdk/pull/8768 From duke at openjdk.java.net Thu May 19 13:17:48 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 19 May 2022 13:17:48 GMT Subject: Integrated: JDK-8284688 Minor cleanup could be done in java.security.jgss In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 17:21:34 GMT, Mark Powers wrote: > https://bugs.openjdk.java.net/browse/JDK-8284688 > > [JDK-8273046](https://bugs.openjdk.java.net/browse/JDK-8273046) is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: > > open/src/java.security.jgss/share/classes/javax/security > open/src/java.security.jgss/share/classes/org/ietf > open/src/java.security.jgss/share/classes/sun/security This pull request has now been integrated. Changeset: db19dc6b Author: Mark Powers Committer: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/db19dc6bb99fe5f149045b6a2a9ceb0b79f0dcc8 Stats: 894 lines in 72 files changed: 96 ins; 193 del; 605 mod 8284688: Minor cleanup could be done in java.security.jgss Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/7746 From xuelei at openjdk.java.net Thu May 19 14:58:48 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 19 May 2022 14:58:48 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. The security/crypto parts look good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8768 From xuelei at openjdk.java.net Thu May 19 14:58:49 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 19 May 2022 14:58:49 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com> References: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com> Message-ID: On Thu, 19 May 2022 09:31:07 GMT, Kevin Walls wrote: >> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? >> >> Also, I fixed a couple of spelling mistakes. > > test/jdk/sun/security/tools/jarsigner/OldSig.java line 32: > >> 30: /* >> 31: * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily >> 32: * formatted individual sections in addition the main attributes tested > > "in addition to the..." +1. ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From valeriep at openjdk.java.net Thu May 19 18:46:50 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 19 May 2022 18:46:50 GMT Subject: Integrated: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 02:59:48 GMT, Valerie Peng wrote: > This is to update the method javadoc of java.security.Signature.getParameters() with the missing `@throws UnsupportedOperationException`. In addition, the wording on the returned parameters are updated to match those in Cipher and CipherSpi classes. > > CSR will be filed later. > > Thanks, > Valerie This pull request has now been integrated. Changeset: e60d8b51 Author: Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/e60d8b516e97a2c1f662e1f31f1cfde2c9fd163e Stats: 59 lines in 2 files changed: 3 ins; 1 del; 55 mod 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From aivanov at openjdk.java.net Thu May 19 18:54:04 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 19 May 2022 18:54:04 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base [v2] In-Reply-To: References: Message-ID: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision: - ...set to the values... - ...will result in a Zip64 Extra (EXT) header - ...in addition to the main attributes... - ...and the address of the current archive - Merges the stack at the given bci... - Returns a single ... - ...when a peer shuts down an association. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8768/files - new: https://git.openjdk.java.net/jdk/pull/8768/files/c7e73658..0669cdc1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00-01 Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768 PR: https://git.openjdk.java.net/jdk/pull/8768 From aivanov at openjdk.java.net Thu May 19 18:59:57 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 19 May 2022 18:59:57 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 08:47:47 GMT, Kevin Walls wrote: >> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision: >> >> - ...set to the values... >> - ...will result in a Zip64 Extra (EXT) header >> - ...in addition to the main attributes... >> - ...and the address of the current archive >> - Merges the stack at the given bci... >> - Returns a single ... >> - ...when a peer shuts down an association. > > src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348: > >> 346: >> 347: /** >> 348: * Returns the single non-abstract {@link Method} visible from > > I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many. I've accepted it, yet I'm still unsure whether ?a? or ?the?? ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From aivanov at openjdk.java.net Thu May 19 19:06:56 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 19 May 2022 19:06:56 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 09:38:40 GMT, Kevin Walls wrote: >> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision: >> >> - ...set to the values... >> - ...will result in a Zip64 Extra (EXT) header >> - ...in addition to the main attributes... >> - ...and the address of the current archive >> - Merges the stack at the given bci... >> - Returns a single ... >> - ...when a peer shuts down an association. > > OK. I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews. Thank you @kevinjwalls for your suggestions. I've incorporated them. ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From hchao at openjdk.java.net Thu May 19 19:23:57 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 19 May 2022 19:23:57 GMT Subject: RFR: 8286908: ECDSA signature should not return parameters [v3] In-Reply-To: References: Message-ID: <0J4qF6dRMw-ClcFt9gp1W_5Wrhke_Oi7z-K7X-U56jc=.0f56a817-ae3e-481e-8cf0-ea4c6611a71b@github.com> On Thu, 19 May 2022 02:01:55 GMT, Weijun Wang wrote: >> Let ECDSA's `engineGetParameters()` always return null. At the same time, remove the remembered `sigParams` field. One behavior change is that after calling `setParameter()`, one can call `init()` again with a key using different parameters. I think this should be allowed since we are reusing the signature object with a brand new key. >> >> `setParameter` is kept unchanged to be able to deal with certificates still having parameters after the signature algorithm object identifier. See https://bugs.openjdk.java.net/browse/JDK-8225745. >> >> Also added SHA1withECDSA to the no-NULL list in `KnownOIDs`. >> >> All security-related tests passed. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - add reference to RFCs > - Merge branch 'master' into 8286908 > - will not read params for ECDSA > - the fix CSR and updated webrev look good. ------------- PR: https://git.openjdk.java.net/jdk/pull/8758 From ihse at openjdk.java.net Fri May 20 08:42:44 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 20 May 2022 08:42:44 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. Build changes look good. Thanks for the cleanup! ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8771 From rhalade at openjdk.java.net Sat May 21 00:36:14 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Sat, 21 May 2022 00:36:14 GMT Subject: RFR: 8287119: Add Distrust.java to ProblemList Message-ID: It will take me some time to figure out what to do with expired certificates. We can either remove those test scenarios, perform backdated validation or allow those expired scenarios to be treated as pass. ------------- Commit messages: - 8287119: Add Distrust.java to ProblemList Changes: https://git.openjdk.java.net/jdk/pull/8823/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8823&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287119 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8823.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8823/head:pull/8823 PR: https://git.openjdk.java.net/jdk/pull/8823 From wetmore at openjdk.java.net Sat May 21 00:43:59 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Sat, 21 May 2022 00:43:59 GMT Subject: RFR: 8287119: Add Distrust.java to ProblemList In-Reply-To: References: Message-ID: On Sat, 21 May 2022 00:26:10 GMT, Rajan Halade wrote: > It will take me some time to figure out what to do with expired certificates. We can either remove those test scenarios, perform backdated validation or allow those expired scenarios to be treated as pass. LGTM. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8823 From rhalade at openjdk.java.net Sat May 21 00:43:59 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Sat, 21 May 2022 00:43:59 GMT Subject: Integrated: 8287119: Add Distrust.java to ProblemList In-Reply-To: References: Message-ID: On Sat, 21 May 2022 00:26:10 GMT, Rajan Halade wrote: > It will take me some time to figure out what to do with expired certificates. We can either remove those test scenarios, perform backdated validation or allow those expired scenarios to be treated as pass. This pull request has now been integrated. Changeset: da8fd454 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/da8fd4547f27cea8d940df5c99dd99503617bf4e Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8287119: Add Distrust.java to ProblemList Reviewed-by: wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/8823 From sebastian.luckner at st.oth-regensburg.de Mon May 9 23:28:20 2022 From: sebastian.luckner at st.oth-regensburg.de (Sebastian Luckner) Date: Mon, 9 May 2022 23:28:20 +0000 Subject: AW: [EXT] Re: RFR: JDK-8286348: incorrect use of `@serial` [v3] In-Reply-To: References: <_j4p9lLYLNTExFqEbx6Uwwwohdj7PY9nfOIh10fWQ60=.d5d107a5-6565-4fa9-abec-fe806e4d35ab@github.com>, Message-ID: public class bam0 { private static long parseLong(/*private **/String w) { long m = 1; long i = 2; long _q = 5; long value = 0; for(int p = w.length() - 1; p >= 0; --p) { if( w.charAt(p) == '1' ) value = value + m; m = m * 2; } return value; } /** * * 1 + (512 + 32 + 4) * 5 - 1 * * 1 + (512 + 32 + 4) * 5 - 1 + 2 * 548 * 5 * 1 - (1 + (512 + 32 + 4) * 5 - 1) * 2 * * 1 + (512 + 32 + 4) * 5 - 1 + 1 + (512 + 32 + 4) * 5 - 1 + 2 * 548 * 1 - 1 * 2 + 3 * (512 + 32 + 4) * ( 4 + 1 ) * 1 - ( 1 + (512 + 32 + 4) * 5 - 1 ) * (1 + (512 + 32 + 4) * ( 5 - 1 + 2 * 548 * 1 - 1 * 2 ) * 3) * * :[ * * */ public static void main(String[] args) { int i = (0b101010101010101010 | 0b0101101010101010) % 0b0110101010101010101001; while(i > 0) { main0(null); --i; } } public static void main0(String[] args) { long x, y, z; final long b = parseLong("1000100100"); final long a = parseLong("101"); //=!!=!=!=!=!=!==!!=!=!=!=!=!==!!=!=!=!==!!=!=!=!=!=!=!==!!=!=!==!=!!==!=!=!!= final long m = parseLong("1"); x = 1; y = 0; z = 0; for(int _b = 0; _b < 3; ++_b) { x = x + b*a - m; y = 2; for(int _a = 0; _a < 4; ++_a) { y = x + y * b * a * m - x * y; z = 3; for(int _m = 0; _m < 5; ++_m) { z = x + y + z * b * a * m - x * y * z; System.out.println(x); // 2740 System.out.println(y); // 2740 System.out.println(z); // -22509100 } } } //System.out.println("x:" + x + "|y:" + y + "|z:" + z); } } ________________________________ Von: client-libs-dev im Auftrag von Phil Race Gesendet: Montag, 9. Mai 2022 22:24:50 An: client-libs-dev at openjdk.java.net; security-dev at openjdk.java.net Betreff: [EXT] Re: RFR: JDK-8286348: incorrect use of `@serial` [v3] On Mon, 9 May 2022 20:19:45 GMT, Jonathan Gibbons wrote: >> Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. >> >> There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. >> >> Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespace (blank lines) after merge Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian.luckner at st.oth-regensburg.de Tue May 10 02:41:54 2022 From: sebastian.luckner at st.oth-regensburg.de (Sebastian Luckner) Date: Tue, 10 May 2022 02:41:54 +0000 Subject: AW: [EXT] Re: RFR: JDK-8286348: incorrect use of `@serial` In-Reply-To: <6Y-lOuoOL1sErefHH6psl-ADUySYCnXi5v1XqceO_Vo=.5b6bb529-e3e3-42f9-a318-16b11bc803cd@github.com> References: , <6Y-lOuoOL1sErefHH6psl-ADUySYCnXi5v1XqceO_Vo=.5b6bb529-e3e3-42f9-a318-16b11bc803cd@github.com> Message-ID: [cid:344f3b40-83d2-4dd0-97c2-936ceace3f9d] ________________________________ Von: client-libs-dev im Auftrag von Jonathan Gibbons Gesendet: Montag, 9. Mai 2022 03:02 An: client-libs-dev at openjdk.java.net; security-dev at openjdk.java.net Betreff: [EXT] Re: RFR: JDK-8286348: incorrect use of `@serial` On Sun, 8 May 2022 02:19:09 GMT, Phil Race wrote: > Jon, all of the changes in java.desktop are already underway in @SuppressWarnings("deprecation opon causation bitpattern as deactivator | deprecated") else { unseen unheard unfeelt nor seen by soul ; } JAVADOC for protecting children from further influences; namefind of problem source of java misuse : via incorrect use therefore no java class for "Wov-tpepewqoew?w" java the source of healing shamanic char arrays; project_name = "BIT PATTERN FOR THE END OF TIME" if( bit_string_to_long(bit_string) == 0 ) {} import java.util.HashMap; import java.util.Map; import java.util.Random; public class MtrxTest { private static Matrix mat = new Matrix( 5, 5 ); private static Matrix comp_mat = new Matrix(5, 5); public static long bitstring_to_long(String bit_string) { if( bit_string.charAt(0) == '0' ) { if( bit_string.charAt(1) == 'b' ) { int i = 2; long mul = 2; for( int x = bit_string.length() - 2; x >= 0; --x ) mul *= 2; long _integer = 0; for(int j = 2; j < bit_string.length(); ++j) { if( bit_string.charAt(j) == '1' ) { _integer = _integer + mul; } else if( bit_string.charAt(j) == '0') { } else { return -1; } mul = mul / 2; } return _integer; } } return 0; } public static void main(String[] args) { String bit_string = "0b10101010101010101010101010011010"; mat.random_init(); comp_mat.random_init(); mat.print(); Map num_pat = new HashMap<>(); while ( true ) { if( mat.contains_modulo((int)bitstring_to_long(bit_string), 6451) ) { mat.print_count(); System.out.println( "-----------------------------------------" ); num_pat q = new num_pat(bit_string, 0) { @Override protected void init() { init_mod(System.nanoTime()); } }; q.print(); System.out.println("\n--------------------------------"); //BufferedReader line_in = new BufferedReader(new InputStreamReader(System.in)); //try {}; //bit_string = line_in.readLine(); bit_string = "0b" + Long.toBinaryString(mat.random_read()); //throw new IOException(); //} catch(/*IOException e*/) { //System.err.println("INPUT SUCCESS"); //} System.out.println(bit_string); System.out.println( bitstring_to_long(bit_string) ); if( bitstring_to_long(bit_string) == 0 ) { bit_string = "0b10101010101010101010101010101010101010101010101010101010101010101010101010101010100110101010"; } System.out.println( bitstring_to_long(bit_string) ); if( bitstring_to_long(bit_string ) == 0 ) { bit_string = "0b10101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010"; } System.out.println( bitstring_to_long(bit_string) ); if( bitstring_to_long(bit_string) == 0 ) { bit_string = "0b011010101010101010101010101010101101010101010101010101010101010101010101010"; } System.out.println( bitstring_to_long(bit_string) ); if( bitstring_to_long(bit_string) == 0 ) { bit_string = "0b101010101010101010101010101010101010101001101010101010101010101010101010101010101010"; } System.out.println( bitstring_to_long(bit_string) ); if( bitstring_to_long(bit_string) == 0 ) { bit_string = "0b011010101010101010101010101010101010101010101010101010101010101010101010101010101010011010101010011010110"; } System.out.print("BIT_ZERO success"); mat.set_seed_by_bitstring(bit_string); mat.randomise(); comp_mat.set_seed_by_bitstring(bit_string); comp_mat.randomise(); Random num_rnd = new Random(mat.random_read() * System.nanoTime()); double o = 0.3083905400902; double[] _q = new double[101]; for(int w = 0; w < _q.length; ++w) _q[w] = o * num_rnd.nextDouble() * (w==0?0.5000000001:_q[w-1]) * num_rnd.nextDouble(); final String float_num = p.pow(42, _q ); System.out.println( float_num ); if(num_pat.containsKey(bit_string)) { for(Map.Entry entry : num_pat.entrySet()) { System.out.println(entry.getKey() + "|" + entry.getValue()); } try { Thread.sleep(2001); //new Object().wait(3007, 34); } catch(InterruptedException e) { e.printStackTrace(); } bit_string = "0b"+Long.toBinaryString(lx.parseLong("0b111101011111001100000000001000001100101010100111000")&num_rnd.nextLong()&lx.parseLong("111000110010101001011111001100001110111010101100101010100101000")); if(num_rnd.nextInt(174) == 7) { if(num_rnd.nextInt(9) == 1) bit_string = "0b1010001101110100010101110000000100110001101000000000000000000000"; else if(num_rnd.nextInt(9) == 2) bit_string = "0b101000110010111101011111001000000000100010101100101010100111000"; else if(num_rnd.nextInt(9) == 3) bit_string = "0b111000110100001000011001111111101110110100000000000000000000000"; else if(num_rnd.nextInt(9) == 4) bit_string = "0b110000110000111101011111001100000010100000001100101010100111000"; else bit_string = "0b" + num_rnd.nextLong(); } } num_pat.put(bit_string, float_num); } mat.random_init(); mat.print(); comp_mat.random_init(); if(!mat.equals(comp_mat)) { System.err.println("COMPUTATION ERROR"); } } } } public abstract class Mat { private static int Mat_Err = MatInteger.NAN(); private int[] matrix_data; protected Mat() { matrix_data = new int[1]; } protected Mat(int len) { matrix_data = new int[len]; } public int get(int x, int y) { return matrix_data[x + y * w()]; } protected int _get(int x, int y) { final int _w = w(); if( x < 0 || x >= w() || _w != w() ) return Mat_Err; if( y < 0 || y >= h() ) return Mat_Err; if( _w == w() ) return matrix_data[x + y * w()]; return Mat_Err * MatInteger.nextNAN(); } protected int get(int i) { return matrix_data[i]; } protected boolean contains(int v) { for(int i = 0; i < matrix_data.length; ++i) { if( matrix_data[i] == v ) return true; } return false; } protected boolean equals(Mat B) { if(len() != B.len()) return false; final int len = len(); for(int i = 0; i < len; ++i) { if(_get(i%w(), i/w()) != B._get(i%B.w(), i/B.w())) return false; } return true; } protected int len() { return matrix_data.length; } protected boolean contains_modulo(int v, int mod) { for( int i = 0; i < matrix_data.length; ++ i ) { // if( matrix_data[i] % mod == v % mod ) { return true; } } return false; } protected int set(int value, int x, int y) { int v_tmp = _get(x, y); matrix_data[x + y * w()] = value; return v_tmp; } protected int _set(int x, int y, int v) { int v_tmp = _get(x, y); if( v == v_tmp ) { } final int _w = w(); final int _h = h(); while( _w == w() && _h == h() ) { if( _w == h() && _h == w() ) { _tmp(v); if( _w != w() && _h != h() ) if( _w == h() && _h == w() ) return 0; } } return set(v, x, y); } protected abstract int w(); protected abstract int h(); protected abstract void _tmp(int tmp); } import java.util.Random; import java.io.PrintStream; public class Matrix extends Mat { private static long seed = 0b10011001011010011001101001100110; private Random rnd = new Random( seed ); private static int print_count = 0; private static PrintStream out = System.out; private static String out_sep = ";"; private int w; private int h; protected int tmp; public Matrix(int w, int h) { super(w * h); this.w = w; this.h = h; } protected void random_init() { for(int x = 0; x < w; ++x) { for(int y = 0; y < h; ++y) { set(rnd.nextInt(), x, y); } } } public boolean equals(Matrix m) { if( !(m instanceof Mat) ) return false; return super.equals(m); } protected void randomise() { rnd = new Random(seed); random_init(); } public long random_read() { long r = 1; for(int i = 0; i < len(); ++i) r *= get(i); return r; } protected void set_seed_by_bitstring(String bit_seed) { if( bit_seed.charAt(0) == '0' ) { if( bit_seed.charAt(1) == 'b' ) { int i = 2; long mul = 2; for( int x = bit_seed.length() - 2; x >= 0; --x ) mul *= 2; long _seed = 0; for(int j = 2; j < bit_seed.length(); ++j) { if( bit_seed.charAt(j) == '1' ) { _seed = _seed + mul; } else if( bit_seed.charAt(j) == '0') { } else { return; } mul = mul / 2; } seed = _seed; } } } public void print() { final int len = w()*h(); for(int i = 0; i < w*h; ++i) { if( i % w() == 0 && i != 0 ) out.print("\n"); out.print(get(i)); out.print(out_sep); } out.print("\n\n"); print_count = print_count + 1; } public void print_count() { out.print("count = "); out.print(print_count); out.println(); print_count = 0; } protected int w() { return w; } protected int h() { return h; } protected void _tmp( int tmp ) { this.tmp = tmp; } } import java.util.Random; import java.io.PrintStream; public class Matrix extends Mat { private static long seed = 0b10011001011010011001101001100110; private Random rnd = new Random( seed ); private static int print_count = 0; private static PrintStream out = System.out; private static String out_sep = ";"; private int w; private int h; protected int tmp; public Matrix(int w, int h) { super(w * h); this.w = w; this.h = h; } protected void random_init() { for(int x = 0; x < w; ++x) { for(int y = 0; y < h; ++y) { set(rnd.nextInt(), x, y); } } } public boolean equals(Matrix m) { if( !(m instanceof Mat) ) return false; return super.equals(m); } protected void randomise() { rnd = new Random(seed); random_init(); } public long random_read() { long r = 1; for(int i = 0; i < len(); ++i) r *= get(i); return r; } protected void set_seed_by_bitstring(String bit_seed) { if( bit_seed.charAt(0) == '0' ) { if( bit_seed.charAt(1) == 'b' ) { int i = 2; long mul = 2; for( int x = bit_seed.length() - 2; x >= 0; --x ) mul *= 2; long _seed = 0; for(int j = 2; j < bit_seed.length(); ++j) { if( bit_seed.charAt(j) == '1' ) { _seed = _seed + mul; } else if( bit_seed.charAt(j) == '0') { } else { return; } mul = mul / 2; } seed = _seed; } } } public void print() { final int len = w()*h(); for(int i = 0; i < w*h; ++i) { if( i % w() == 0 && i != 0 ) out.print("\n"); out.print(get(i)); out.print(out_sep); } out.print("\n\n"); print_count = print_count + 1; } public void print_count() { out.print("count = "); out.print(print_count); out.println(); print_count = 0; } protected int w() { return w; } protected int h() { return h; } protected void _tmp( int tmp ) { this.tmp = tmp; } } ARRAY_DEPTH = 2; the source of images of script; sharing images of my contact from [ 09.05.2022 ] char purpose as a simple learing about where on->0; opon BITZERO success printed : random class: { } virtual image projected of someone from another universe: dest -> random num pattern; his taktic: adding 10101010101010101010101 01010101010101010101010101010 disactivating automatic reenclosement adding 10101001100101100101010101010110 purposing }, {} ,{ never exeding a file length of 160214840 bytes of .random file line length <= 06?886? bit_length = 4047; OPON JAVA DELETED: tk -> 0 exept pon full string equalized by iconic string raisedfromsomewhere universal find( x, y, z ) : false|nor|true second and third long bit value in same line corrected by hand after static recognized moton repetition ; 01100110101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010 011010101010011001101001101001101010101010101001101010011010101010101010101010101010101010101010101001101010101010101010101010011010100101101001101010101010101010101001101010100110011010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010011010101010011010101010101010101010101010101010101010101001101001101010101001011010101010101010101010101010101001101010100110101010101010100110101010101010101010101010101001101010101010011010101010011010101010101010101010101010101010101010101010011010011010100101101010101001101010101010100101011010100101101010011010101010101010101010101010100110101010101010101010101010101010101010101010101010011010101010101010101010101010101010101010011001100110101010101001101001101010100110101010101001101010100110011001101001101010011010100110101010101010101010101010101010101010101010100110101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010100000000000000000000000000000000000000000000000000001111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010 if one photon meet a true re sent by moon then delta_t always equal if one moton e then true e-e = 0.0000000000000000001010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010000000000000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111111111111111111111111111111111111101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010i then delta_t never qualizable if one qube is filled by the light then delta_t ever stable as long as sun a?s if one lw0101010110100110101010011010100110101001011001101001100110101010101010100110101010101010101010101010101010101010100110101010100 then boredom generated if one photon meets p0: r0.nextInt(9, 90874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743259087432950874329508743295087432950874329508743295087432950874329508743259087432950874329508743295087432950874329508743295087432950874329508743259087432950874329508743295087432950874329508743295087432950874329508743259087432950874329508743295087432950874329508743295087432950874329508743259087432950874329508743295087432950874329508743295087432950874329508743259087432950874329508743295087432950874329508743295087432950874329508743259087432950874329508743295087432950874329508743295087432950874329508743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432590874325908743259087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874325908743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743295087432950874329508743) - r0.nextInt(8, 4534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534534?944444444444444444444444444444444444444444444499440404040404040404040404040404979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797979797040404040404040404040404040404040404040404040408 + r0.nextInt(7, !=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!) -> 0b000000000000000000000000000 /*#* private static long[][] pwq = {{ }, {} ,{ }, {} , { }, {} , { {}; }, {} , { }, {} , { }, {} , { }, {} , { }, {} , { }, {} , { }, {} , { }, {} , { }, {} , { 0b10101010101010101001011010011001, 01101010101001101010101001011010, 011010101010100110011010011010, 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010100000100000, 1010101010101010101010101010101010101010101010101010101010101010101010101010000000000100000000100000, 1000000000000000000000010101010101010101010101010101010101010101010100000000010101010101010101010000, 1000000000000000100000000000001010101010101010101010101010100000000010100100000001000010000010101010, 1000000000010000000000000000101010101010101010101010101000000001010101010101010101010101010101010101, 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 1000000000000000010101010101010101010101010101010101010101010101010101010101010101010101010101010101, 1000000000000100000000000000001000000000000000101010101010101010101010101010101010101010101010101010, 0111111111111111010101010101010101010101010101010101010101010101010101010101010101010101010101010101, 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 0111111111111111101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 011111111111111111111111111111111111111111111111111111000000000000000000000000000000000000000000000000, 101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 10101010101010101010101010101010101010101010101001, 101010101010101010101010101010101010101010101010101010101010101, 100000000000000000000000000000000001, 011111111111111111111111111111111110, 100000000000000000000000000000000001, 101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 10101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 101010101010101010101010101010101010101010101010101010101010101010101010101010101010101, 10101010101010101010101010101010101010101010101010101010101010101010101011111111111111, 101010101010101010101010101010101010101010101010101010101010101010101010101010000000000000000000000000000000000000000001, 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101, 01111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111, 101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101, 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 10101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010, 101010101010101010101010101010101010101010101010101010101010101010101010101010101010101, 01111111111111111111111111111111, 10101010101010101010101010101010101010, 10101010101010101010101010101010101010101010101010101010101010101, 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 */ t0 - t1 == t1 - t2 == t_delta "16_______6_______8" data packages for protecting children > have been approved and even have an approved CSR .. just waiting for @alisenchung to type /integrate .. Thanks for the heads up; I'll merge with Alisen's changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedImage.png Type: image/png Size: 170680 bytes Desc: pastedImage.png URL: From jkoskeladev at gmail.com Fri May 20 19:23:05 2022 From: jkoskeladev at gmail.com (Jade Koskela) Date: Fri, 20 May 2022 12:23:05 -0700 Subject: SSPI Bridge Bug In-Reply-To: References: Message-ID: Resurrected. Hi what happened with this? Looking at the github I don't see this is fixed. Still seeing errors. On Tue, Sep 29, 2020 at 6:08 PM Weijun Wang wrote: > Ah, yes. Will fix it soon. > > Thanks, > Max > > > On Sep 29, 2020, at 7:46 PM, Jade Koskela wrote: > > > > Hi, > > > > New contributor here. I have found a bug in sspi_bridge that requires a > small change to fix. > > This causes failures to connect with Postgres JDBC using sspi_bridge. > > > > This line in sspi_bridge should be: > > > > < || l2 < l1 && l2 != l1) { > > --- > > > || l2 < l1 && l2 != r1) { > > > > Thanks, > > Jade > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkoskeladev at gmail.com Fri May 20 19:27:01 2022 From: jkoskeladev at gmail.com (Jade Koskela) Date: Fri, 20 May 2022 12:27:01 -0700 Subject: SSPI Bridge Bug In-Reply-To: References: Message-ID: Oh nvmd, I see it was only backported to 16+. On Fri, May 20, 2022 at 12:23 PM Jade Koskela wrote: > Resurrected. > > Hi what happened with this? Looking at the github I don't see this is > fixed. Still seeing errors. > > On Tue, Sep 29, 2020 at 6:08 PM Weijun Wang > wrote: > >> Ah, yes. Will fix it soon. >> >> Thanks, >> Max >> >> > On Sep 29, 2020, at 7:46 PM, Jade Koskela >> wrote: >> > >> > Hi, >> > >> > New contributor here. I have found a bug in sspi_bridge that requires a >> small change to fix. >> > This causes failures to connect with Postgres JDBC using sspi_bridge. >> > >> > This line in sspi_bridge should be: >> > >> > < || l2 < l1 && l2 != l1) { >> > --- >> > > || l2 < l1 && l2 != r1) { >> > >> > Thanks, >> > Jade >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.java.net Mon May 23 08:47:57 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 23 May 2022 08:47:57 GMT Subject: Integrated: 8286715: Generalize MemorySegment::ofBuffer In-Reply-To: References: Message-ID: On Fri, 13 May 2022 12:33:10 GMT, Maurizio Cimadamore wrote: > This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`. > This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function. > > We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`. > So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`. > > In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case. This pull request has now been integrated. Changeset: 89a1d055 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/89a1d055d93ad57bcec7c1accb3f53b4c30f594d Stats: 95 lines in 8 files changed: 55 ins; 1 del; 39 mod 8286715: Generalize MemorySegment::ofBuffer Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/jdk/pull/8701 From weijun at openjdk.java.net Mon May 23 13:37:43 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 23 May 2022 13:37:43 GMT Subject: Integrated: 8286908: ECDSA signature should not return parameters In-Reply-To: References: Message-ID: On Tue, 17 May 2022 19:56:22 GMT, Weijun Wang wrote: > Let ECDSA's `engineGetParameters()` always return null. At the same time, remove the remembered `sigParams` field. One behavior change is that after calling `setParameter()`, one can call `init()` again with a key using different parameters. I think this should be allowed since we are reusing the signature object with a brand new key. > > `setParameter` is kept unchanged to be able to deal with certificates still having parameters after the signature algorithm object identifier. See https://bugs.openjdk.java.net/browse/JDK-8225745. > > Also added SHA1withECDSA to the no-NULL list in `KnownOIDs`. > > All security-related tests passed. This pull request has now been integrated. Changeset: 8040aa00 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/8040aa0073e7ea22b2fdff5bddff10c244e116ef Stats: 109 lines in 4 files changed: 60 ins; 36 del; 13 mod 8286908: ECDSA signature should not return parameters Reviewed-by: ascarpino, hchao, valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/8758 From rriggs at openjdk.java.net Mon May 23 18:37:51 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 23 May 2022 18:37:51 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: References: <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com> Message-ID: <6_CLgH6C3qE24sCkgD23wyfRgiSBgVTNZwFNKOFpFXI=.88e2c0c7-a2b9-4dcd-888a-2fe11e414d3f@github.com> On Tue, 10 May 2022 19:24:24 GMT, Mark Powers wrote: >> src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777: >> >>> 775: if (!printStackPropertiesSet && VM.initLevel() >= 1) { >>> 776: printStackWhenAccessFails = GetBooleanAction. >>> 777: privilegedGetProperty("sun.reflect.debugModuleAccessChecks"); >> >> Running with `-Dsun.reflect.debugModuleAccessChecks` should set printStackWhenAccessFails to true, not false. > > You are right. The old way maps the null string to true, and the new way maps it to false. I did not notice that. At this point, I see no value in making the "true".equals and "false".equals changes. Too much can break. I'll reverse these changes. This change still needs to be reversed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From duke at openjdk.java.net Mon May 23 18:58:34 2022 From: duke at openjdk.java.net (Mark Powers) Date: Mon, 23 May 2022 18:58:34 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2] In-Reply-To: References: Message-ID: > JDK-6725221 Standardize obtaining boolean properties with defaults Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Alan and Jamil comments - Merge - reverse true.equals and false.equals changes - Merge - Merge - first iteration ------------- Changes: https://git.openjdk.java.net/jdk/pull/8559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8559&range=01 Stats: 9 lines in 3 files changed: 1 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8559/head:pull/8559 PR: https://git.openjdk.java.net/jdk/pull/8559 From duke at openjdk.java.net Mon May 23 19:03:51 2022 From: duke at openjdk.java.net (Mark Powers) Date: Mon, 23 May 2022 19:03:51 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2] In-Reply-To: <6_CLgH6C3qE24sCkgD23wyfRgiSBgVTNZwFNKOFpFXI=.88e2c0c7-a2b9-4dcd-888a-2fe11e414d3f@github.com> References: <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com> <6_CLgH6C3qE24sCkgD23wyfRgiSBgVTNZwFNKOFpFXI=.88e2c0c7-a2b9-4dcd-888a-2fe11e414d3f@github.com> Message-ID: On Mon, 23 May 2022 18:34:41 GMT, Roger Riggs wrote: >> You are right. The old way maps the null string to true, and the new way maps it to false. I did not notice that. At this point, I see no value in making the "true".equals and "false".equals changes. Too much can break. I'll reverse these changes. > > This change still needs to be reversed. The change has been reversed. We had an internal discussion about IntelliJ's unboxing recommendation, and decided to let unboxing be a matter of personal preference. Those changes have been reversed too. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From rriggs at openjdk.java.net Mon May 23 20:00:01 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 23 May 2022 20:00:01 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 18:58:34 GMT, Mark Powers wrote: >> JDK-6725221 Standardize obtaining boolean properties with defaults > > Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Alan and Jamil comments > - Merge > - reverse true.equals and false.equals changes > - Merge > - Merge > - first iteration LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8559 From aivanov at openjdk.java.net Mon May 23 20:06:57 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 23 May 2022 20:06:57 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base [v3] In-Reply-To: References: Message-ID: <3E93xe0v68L9AHsT3c5D58_5OdaSDEGtdg5ih7TTkfk=.45bed80f-be56-49e8-9dfb-a7fa70b9ea23@github.com> > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Update copyright to 2022 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8768/files - new: https://git.openjdk.java.net/jdk/pull/8768/files/0669cdc1..fa2caaec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01-02 Stats: 102 lines in 102 files changed: 0 ins; 0 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/8768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768 PR: https://git.openjdk.java.net/jdk/pull/8768 From mullan at openjdk.java.net Mon May 23 20:31:15 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 23 May 2022 20:31:15 GMT Subject: RFR: 8287109: Distrust.java failed with CertificateExpiredException In-Reply-To: References: Message-ID: On Mon, 23 May 2022 20:14:37 GMT, Rajan Halade wrote: > Incorporated patch from my @seanjmullan and removed expired root chains. LGTM although someone else should probably have a look over this since I contributed the fix. test/jdk/sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java line 183: > 181: } catch (CertificateException ce) { > 182: // expired TLS certificates should not be treated as failure > 183: if(expired(ce)) { add space after "if". ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8856 From rhalade at openjdk.java.net Mon May 23 20:31:14 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 23 May 2022 20:31:14 GMT Subject: RFR: 8287109: Distrust.java failed with CertificateExpiredException Message-ID: Incorporated patch from my @seanjmullan and removed expired root chains. ------------- Commit messages: - Reformat code - Update ProblemList - 8287109: Distrust.java failed with CertificateExpiredException Changes: https://git.openjdk.java.net/jdk/pull/8856/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8856&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287109 Stats: 173 lines in 4 files changed: 21 ins; 149 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8856.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8856/head:pull/8856 PR: https://git.openjdk.java.net/jdk/pull/8856 From rhalade at openjdk.java.net Mon May 23 20:36:58 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Mon, 23 May 2022 20:36:58 GMT Subject: Integrated: 8287109: Distrust.java failed with CertificateExpiredException In-Reply-To: References: Message-ID: On Mon, 23 May 2022 20:14:37 GMT, Rajan Halade wrote: > Incorporated patch from my @seanjmullan and removed expired root chains. This pull request has now been integrated. Changeset: 5b7d066c Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/5b7d066ca5cb68e07a704d3ce13283761c1cf3ad Stats: 173 lines in 4 files changed: 21 ins; 149 del; 3 mod 8287109: Distrust.java failed with CertificateExpiredException Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/8856 From aivanov at openjdk.java.net Mon May 23 20:46:23 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 23 May 2022 20:46:23 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code [v2] In-Reply-To: References: Message-ID: <6pmdug3Hpy1LPgcb-OIdMP6XuOWpWYngOju7mFPdDV4=.a68d1c15-58a3-4ffa-b94d-a1a14666f9eb@github.com> > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge master - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the a' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'the the' in source code - 8284209: Replace remaining usages of 'an? an?' in source code - 8284209: Replace remaining usages of 'a the' in source code - ... and 2 more: https://git.openjdk.java.net/jdk/compare/5b7d066c...fab0a4bb ------------- Changes: https://git.openjdk.java.net/jdk/pull/8771/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=01 Stats: 50 lines in 40 files changed: 0 ins; 2 del; 48 mod Patch: https://git.openjdk.java.net/jdk/pull/8771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771 PR: https://git.openjdk.java.net/jdk/pull/8771 From valeriep at openjdk.java.net Mon May 23 21:03:15 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 23 May 2022 21:03:15 GMT Subject: RFR: 8286211: Update PCSC-Lite for Suse Linux to 1.9.5 Message-ID: Need to update the 3 header files due to expiring business approval for 3rd party. The header files contain tabs which jcheck disallows, so I have to replace them with spaces. Thanks, Valerie ------------- Commit messages: - Replaced tab with spaces in order to pass jcheck. - 8286211: Update PCSC-Lite for Suse Linux to 1.9.5 Changes: https://git.openjdk.java.net/jdk/pull/8853/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8853&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286211 Stats: 221 lines in 4 files changed: 2 ins; 14 del; 205 mod Patch: https://git.openjdk.java.net/jdk/pull/8853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8853/head:pull/8853 PR: https://git.openjdk.java.net/jdk/pull/8853 From valeriep at openjdk.java.net Mon May 23 21:22:46 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 23 May 2022 21:22:46 GMT Subject: RFR: 8286211: Update PCSC-Lite for Suse Linux to 1.9.5 [v2] In-Reply-To: References: Message-ID: > Need to update the 3 header files due to expiring business approval for 3rd party. > > The header files contain tabs which jcheck disallows, so I have to replace them with spaces. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Fix indentation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8853/files - new: https://git.openjdk.java.net/jdk/pull/8853/files/8344ddb5..42c9df2a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8853&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8853&range=00-01 Stats: 192 lines in 3 files changed: 0 ins; 1 del; 191 mod Patch: https://git.openjdk.java.net/jdk/pull/8853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8853/head:pull/8853 PR: https://git.openjdk.java.net/jdk/pull/8853 From valeriep at openjdk.java.net Mon May 23 21:44:39 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 23 May 2022 21:44:39 GMT Subject: RFR: 8286211: Update PCSC-Lite for Suse Linux to 1.9.5 [v3] In-Reply-To: References: Message-ID: > Need to update the 3 header files due to expiring business approval for 3rd party. > > The header files contain tabs which jcheck disallows, so I have to replace them with spaces. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Added a link for COPYING as on the pcsc-lite website ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8853/files - new: https://git.openjdk.java.net/jdk/pull/8853/files/42c9df2a..32b75b6a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8853&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8853&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8853/head:pull/8853 PR: https://git.openjdk.java.net/jdk/pull/8853 From weijun at openjdk.java.net Mon May 23 21:54:51 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 23 May 2022 21:54:51 GMT Subject: RFR: 8286211: Update PCSC-Lite for Suse Linux to 1.9.5 [v3] In-Reply-To: References: Message-ID: <0og235R0QJfBjjLlF1_YQFMXbEX59x4GWPWzOPV-HSU=.3449bbf1-67db-461e-af6c-d8bc3f7f27b0@github.com> On Mon, 23 May 2022 21:44:39 GMT, Valerie Peng wrote: >> Need to update the 3 header files due to expiring business approval for 3rd party. >> >> The header files contain tabs which jcheck disallows, so I have to replace them with spaces. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Added a link for COPYING as on the pcsc-lite website LGTM. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8853 From aivanov at openjdk.java.net Tue May 24 09:52:29 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 24 May 2022 09:52:29 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code [v3] In-Reply-To: References: Message-ID: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Update copyright to 2022 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8771/files - new: https://git.openjdk.java.net/jdk/pull/8771/files/fab0a4bb..4d529f79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=01-02 Stats: 24 lines in 24 files changed: 0 ins; 0 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/8771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771 PR: https://git.openjdk.java.net/jdk/pull/8771 From lancea at openjdk.java.net Tue May 24 09:58:42 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 24 May 2022 09:58:42 GMT Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code [v3] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 09:52:29 GMT, Alexey Ivanov wrote: >> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? >> >> It's the last issue in the series, and it still touches different areas of the code. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright to 2022 Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8771 From aivanov at openjdk.java.net Tue May 24 11:28:50 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 24 May 2022 11:28:50 GMT Subject: Integrated: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. This pull request has now been integrated. Changeset: e0d361ce Author: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/e0d361cea91d3dd1450aece73f660b4abb7ce5fa Stats: 303 lines in 162 files changed: 0 ins; 11 del; 292 mod 8284191: Replace usages of 'a the' in hotspot and java.base Reviewed-by: lancea, wetmore, naoto, iris, kevinw, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From subscriptions at bensmyth.com Tue May 24 15:20:46 2022 From: subscriptions at bensmyth.com (Ben Smyth) Date: Tue, 24 May 2022 17:20:46 +0200 Subject: JSSE: SSLEngine reporting HandshakeStatus.FINISHED, disabling NewSessionTicket Message-ID: TL;DR: Why does a client report HandshakeStatus.FINISHED twice? Can production of NewSessionTicket be disabled? A client (respectively server) becomes ready to encrypt application data upon completing their side of handshaking: "Once a side has sent its Finished message and has received and validated the Finished message from its peer, it may begin to send and receive Application Data over the connection" (RFC8446); a client completes handshaking upon wrapping a FINISHED message and a server completes upon unwrapping such a message. (There's an exception for 0-RTT data, and another for a server operating with reduced security.) Javadoc advises HandshakeStatus.FINISHED is reported when "a call to SSLEngine.wrap() / unwrap() ... finishes a handshake." As expected, * OpenJDK SSLEngine.wrap() reports HandshakeStatus.FINISHED on wrapping a client's (TLS) FINISHED message. By comparison, rather than report (server) handshake completion upon unwrapping a client's (TLS) FINISHED message, HandshakeStatus.NEED_WRAP is reported, a NewSessionTicket is produced on wrapping and * OpenJDK SSLEngine.wrap() reports HandshakeStatus.FINISHED on wrapping a server's (TLS) NewSessionTicket message. Upon receipt of which, * OpenJDK SSLEngine.unwrap() reports HandshakeStatus.FINISHED on unwrapping a server's (TLS) NewSessionTicket message. What does finishing a handshake mean in SSLEngine parlance? (I don't understand why a client should report finishing twice.) Can production of NewSessionTicket be disabled? -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.java.net Tue May 24 16:23:59 2022 From: duke at openjdk.java.net (Mark Powers) Date: Tue, 24 May 2022 16:23:59 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 18:58:34 GMT, Mark Powers wrote: >> JDK-6725221 Standardize obtaining boolean properties with defaults > > Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Alan and Jamil comments > - Merge > - reverse true.equals and false.equals changes > - Merge > - Merge > - first iteration Mach5 tier1 and tier2 completed without any failures. I don't know what to make of the pre-submit failures - lang and hotspot? ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From mullan at openjdk.java.net Tue May 24 16:36:48 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 24 May 2022 16:36:48 GMT Subject: RFR: 8287246: Check for required DSA parameters instead of letting KeyFactory =?UTF-8?B?cHJvdmnigKY=?= Message-ID: Please review this fix to the XML Signature implementation to check for null or missing DSA parameters and throw a MarshalException before trying to create a DSA public key from its XML encoding. This will allow the code to fail earlier and not depend on the underlying provider to detect illegal or missing parameters. ------------- Commit messages: - Check for required DSA parameters instead of letting KeyFactory provider do it. Changes: https://git.openjdk.java.net/jdk/pull/8870/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8870&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287246 Stats: 30 lines in 1 file changed: 0 ins; 13 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/8870.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8870/head:pull/8870 PR: https://git.openjdk.java.net/jdk/pull/8870 From wetmore at openjdk.java.net Tue May 24 18:14:56 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 24 May 2022 18:14:56 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 16:20:10 GMT, Mark Powers wrote: > Mach5 tier1 and tier2 completed without any failures. I don't know what to make of the pre-submit failures - lang and hotspot? IIUC, these are due to Loom failures in some of the other platforms supported by OpenJDK but not by Oracle. They are being resolved. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From duke at openjdk.java.net Tue May 24 18:20:00 2022 From: duke at openjdk.java.net (Mark Powers) Date: Tue, 24 May 2022 18:20:00 GMT Subject: Integrated: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: References: Message-ID: <6NZWhFHhhJI3m2-DVm8Jzfla_Z7hPbnhGf4H8cBpM6c=.9e3988f9-cefd-4399-9e83-6ef6ae5ad29e@github.com> On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote: > JDK-6725221 Standardize obtaining boolean properties with defaults This pull request has now been integrated. Changeset: 6cc4bb11 Author: Mark Powers Committer: Bradford Wetmore URL: https://git.openjdk.java.net/jdk/commit/6cc4bb1169f34bc091cad3e2deec37cd5585e8d5 Stats: 9 lines in 3 files changed: 1 ins; 1 del; 7 mod 6725221: Standardize obtaining boolean properties with defaults Reviewed-by: prr, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From aivanov at openjdk.java.net Tue May 24 20:12:09 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 24 May 2022 20:12:09 GMT Subject: Integrated: 8284209: Replace remaining usages of 'a the' in source code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > It's the last issue in the series, and it still touches different areas of the code. This pull request has now been integrated. Changeset: 9b7e42c0 Author: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/9b7e42c0f078db778dda1011d85cd92e3e4eb979 Stats: 74 lines in 40 files changed: 0 ins; 2 del; 72 mod 8284209: Replace remaining usages of 'a the' in source code Reviewed-by: lancea, wetmore, dfuchs, iris, jjg, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/8771 From valeriep at openjdk.java.net Tue May 24 21:36:00 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 24 May 2022 21:36:00 GMT Subject: Integrated: 8286211: Update PCSC-Lite for Suse Linux to 1.9.5 In-Reply-To: References: Message-ID: On Mon, 23 May 2022 19:31:02 GMT, Valerie Peng wrote: > Need to update the 3 header files due to expiring business approval for 3rd party. > > The header files contain tabs which jcheck disallows, so I have to replace them with spaces. > > Thanks, > Valerie This pull request has now been integrated. Changeset: d792cbcc Author: Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/d792cbcc063c426fbf8add8697cbafc9b0e3fc3b Stats: 197 lines in 3 files changed: 2 ins; 15 del; 180 mod 8286211: Update PCSC-Lite for Suse Linux to 1.9.5 Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/8853 From xuelei at openjdk.java.net Wed May 25 15:28:34 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 25 May 2022 15:28:34 GMT Subject: RFR: 8286045: Use ForceGC for cleaner test cases Message-ID: Hi, May I have the test case update reviewed? This patch is trying to use ForceGC for cleaner test cases. As would make the test more stable and easier to maintain. Thanks, Xuelei ------------- Commit messages: - 8286045: Use ForceGC for cleaner test cases Changes: https://git.openjdk.java.net/jdk/pull/8885/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8885&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286045 Stats: 57 lines in 3 files changed: 19 ins; 28 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/8885.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8885/head:pull/8885 PR: https://git.openjdk.java.net/jdk/pull/8885 From rriggs at openjdk.java.net Wed May 25 17:25:13 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 25 May 2022 17:25:13 GMT Subject: RFR: 8286045: Use ForceGC for cleaner test cases In-Reply-To: References: Message-ID: <69CjJ1xKBNqFF_K26yK7CSRsObTJuZEXg0A2hLU_7Fg=.fa00448d-0bba-42ea-8e6a-8266bb4145df@github.com> On Wed, 25 May 2022 15:20:45 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have the test case update reviewed? > > This patch is trying to use ForceGC for cleaner test cases. As would make the test more stable and easier to maintain. > > Thanks, > Xuelei The usage looks fine. (But ForceGC is a heavyweight blunt instrument. It creates a new Cleaner for every instance and an instance can only be used once. Also, its minimum wait/sleep time is 1 second, that's a loooong time.). ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8885 From weijun at openjdk.java.net Wed May 25 17:29:40 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 25 May 2022 17:29:40 GMT Subject: RFR: 8287246: DSAKeyValue should check for missing params instead of relying on KeyFactory provider In-Reply-To: References: Message-ID: On Tue, 24 May 2022 16:29:02 GMT, Sean Mullan wrote: > Please review this fix to the XML Signature implementation to check for null or missing DSA parameters and throw a MarshalException before trying to create a DSA public key from its XML encoding. This will allow the code to fail earlier and not depend on the underlying provider to detect illegal or missing parameters. src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java line 306: > 304: // Recommendation as they might be known from application context, > 305: // but this implementation does not support that, so they are > 306: // required. Can you provide more details on why "this implementation" does not support that? Is it because we don't have an API for that or we haven't defined any property for that? src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java line 306: > 304: // Recommendation as they might be known from application context, > 305: // but this implementation does not support that, so they are > 306: // required. Can you provide more details on why "this implementation" does not support that? Is it because we don't have an API for that or we haven't defined any property for that? ------------- PR: https://git.openjdk.java.net/jdk/pull/8870 From weijun at openjdk.java.net Wed May 25 18:25:48 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 25 May 2022 18:25:48 GMT Subject: RFR: 8287246: DSAKeyValue should check for missing params instead of relying on KeyFactory provider In-Reply-To: References: Message-ID: On Tue, 24 May 2022 16:29:02 GMT, Sean Mullan wrote: > Please review this fix to the XML Signature implementation to check for null or missing DSA parameters and throw a MarshalException before trying to create a DSA public key from its XML encoding. This will allow the code to fail earlier and not depend on the underlying provider to detect illegal or missing parameters. Looks good to me. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8870 From mullan at openjdk.java.net Wed May 25 19:03:25 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 25 May 2022 19:03:25 GMT Subject: RFR: 8287246: DSAKeyValue should check for missing params instead of relying on KeyFactory provider [v2] In-Reply-To: References: Message-ID: <3biZDfjY-uMsGupTFjOmmK6UR80zpHkzTHh2VhsaRvs=.dee07da8-d289-4f57-8e87-e7f7a27ad7b4@github.com> > Please review this fix to the XML Signature implementation to check for null or missing DSA parameters and throw a MarshalException before trying to create a DSA public key from its XML encoding. This will allow the code to fail earlier and not depend on the underlying provider to detect illegal or missing parameters. Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: Clarify why we don't support missing DSA params. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8870/files - new: https://git.openjdk.java.net/jdk/pull/8870/files/e53e205c..d3d9ab00 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8870&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8870&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8870.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8870/head:pull/8870 PR: https://git.openjdk.java.net/jdk/pull/8870 From xuelei at openjdk.java.net Wed May 25 21:27:45 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 25 May 2022 21:27:45 GMT Subject: RFR: 8286045: Use ForceGC for cleaner test cases In-Reply-To: <69CjJ1xKBNqFF_K26yK7CSRsObTJuZEXg0A2hLU_7Fg=.fa00448d-0bba-42ea-8e6a-8266bb4145df@github.com> References: <69CjJ1xKBNqFF_K26yK7CSRsObTJuZEXg0A2hLU_7Fg=.fa00448d-0bba-42ea-8e6a-8266bb4145df@github.com> Message-ID: On Wed, 25 May 2022 17:23:06 GMT, Roger Riggs wrote: > (But ForceGC is a heavyweight blunt instrument. It creates a new Cleaner for every instance and an instance can only be used once. Also, its minimum wait/sleep time is 1 second, that's a loooong time.). I thought about something similar when I read the ForceGC implementation. I may file an enhancement for ForceGC later. ------------- PR: https://git.openjdk.java.net/jdk/pull/8885 From duke at openjdk.java.net Wed May 25 23:21:12 2022 From: duke at openjdk.java.net (Mark Powers) Date: Wed, 25 May 2022 23:21:12 GMT Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v4] In-Reply-To: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com> References: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com> Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8285263 Minor cleanup could be done in java.security > > JDK-8273046 is the umbrella bug for this bug. The changes were too large for a single code review, so it was decided to split into smaller chunks. This is one such chunk: > > open/src/java.base/share/classes/java/security Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - fourth iteration - Merge - Merge - third iteration - Merge - Merge - second iteration - Merge - Merge - first iteration ------------- Changes: https://git.openjdk.java.net/jdk/pull/8319/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8319&range=03 Stats: 628 lines in 95 files changed: 25 ins; 140 del; 463 mod Patch: https://git.openjdk.java.net/jdk/pull/8319.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8319/head:pull/8319 PR: https://git.openjdk.java.net/jdk/pull/8319 From mullan at openjdk.java.net Thu May 26 12:40:30 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 26 May 2022 12:40:30 GMT Subject: Integrated: 8287246: DSAKeyValue should check for missing params instead of relying on KeyFactory provider In-Reply-To: References: Message-ID: On Tue, 24 May 2022 16:29:02 GMT, Sean Mullan wrote: > Please review this fix to the XML Signature implementation to check for null or missing DSA parameters and throw a MarshalException before trying to create a DSA public key from its XML encoding. This will allow the code to fail earlier and not depend on the underlying provider to detect illegal or missing parameters. This pull request has now been integrated. Changeset: f235955e Author: Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/f235955eefb1141a2e72116dfcf345e40416f059 Stats: 30 lines in 1 file changed: 0 ins; 12 del; 18 mod 8287246: DSAKeyValue should check for missing params instead of relying on KeyFactory provider Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/8870 From xuelei at openjdk.java.net Thu May 26 18:04:38 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 26 May 2022 18:04:38 GMT Subject: Integrated: 8286045: Use ForceGC for cleaner test cases In-Reply-To: References: Message-ID: On Wed, 25 May 2022 15:20:45 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have the test case update reviewed? > > This patch is trying to use ForceGC for cleaner test cases. As would make the test more stable and easier to maintain. > > Thanks, > Xuelei This pull request has now been integrated. Changeset: 7eb15593 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/7eb15593e18a923bbc18c8d596cff87d87019640 Stats: 57 lines in 3 files changed: 19 ins; 28 del; 10 mod 8286045: Use ForceGC for cleaner test cases Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/8885 From duke at openjdk.java.net Thu May 26 20:06:17 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 26 May 2022 20:06:17 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v6] In-Reply-To: References: Message-ID: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - 8282662: Revert wrong copyright year change - 8282662: Revert ProxyGenerator - 8282662: Revert ProxyGenerator - 8282662: Revert dubious changes in MethodType - 8282662: Revert dubious changes - 8282662: Use List/Set.of() factory methods to save memory ------------- Changes: https://git.openjdk.java.net/jdk/pull/7729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=05 Stats: 12 lines in 4 files changed: 1 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From djelinski at openjdk.java.net Fri May 27 14:10:01 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 27 May 2022 14:10:01 GMT Subject: RFR: 8277307: Pre shared key sent under both session_ticket and pre_shared_key extensions Message-ID: Session ticket extension should only contain pre-TLS1.3 stateless session tickets; it should not be used for sending TLS1.3 pre-shared keys. ------------- Commit messages: - Send empty ticket when resuming TLS1.3 Changes: https://git.openjdk.java.net/jdk/pull/8922/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8922&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277307 Stats: 21 lines in 2 files changed: 14 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8922.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8922/head:pull/8922 PR: https://git.openjdk.java.net/jdk/pull/8922 From duke at openjdk.java.net Sat May 28 05:58:29 2022 From: duke at openjdk.java.net (duke) Date: Sat, 28 May 2022 05:58:29 GMT Subject: Withdrawn: 8284192: SSLSocketReset test should expect EOFException on client side In-Reply-To: References: Message-ID: On Fri, 1 Apr 2022 20:53:20 GMT, Rajan Halade wrote: > Updated test code to expect EOFException on client side and did other cleanup to improve test code. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8080 From duke at openjdk.java.net Tue May 31 07:40:56 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 31 May 2022 07:40:56 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v7] In-Reply-To: References: Message-ID: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - 8282662: Revert wrong copyright year change - 8282662: Revert ProxyGenerator - 8282662: Revert ProxyGenerator - 8282662: Revert dubious changes in MethodType - 8282662: Revert dubious changes - 8282662: Use List/Set.of() factory methods to save memory ------------- Changes: https://git.openjdk.java.net/jdk/pull/7729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=06 Stats: 12 lines in 4 files changed: 1 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From redestad at openjdk.java.net Tue May 31 09:40:27 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 31 May 2022 09:40:27 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v7] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 07:40:56 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - 8282662: Revert wrong copyright year change > - 8282662: Revert ProxyGenerator > - 8282662: Revert ProxyGenerator > - 8282662: Revert dubious changes in MethodType > - 8282662: Revert dubious changes > - 8282662: Use List/Set.of() factory methods to save memory Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From rriggs at openjdk.java.net Tue May 31 13:13:47 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 31 May 2022 13:13:47 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v7] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 07:40:56 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - 8282662: Revert wrong copyright year change > - 8282662: Revert ProxyGenerator > - 8282662: Revert ProxyGenerator > - 8282662: Revert dubious changes in MethodType > - 8282662: Revert dubious changes > - 8282662: Use List/Set.of() factory methods to save memory Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From coffeys at openjdk.java.net Tue May 31 13:50:46 2022 From: coffeys at openjdk.java.net (Sean Coffey) Date: Tue, 31 May 2022 13:50:46 GMT Subject: RFR: 8277307: Pre shared key sent under both session_ticket and pre_shared_key extensions In-Reply-To: References: Message-ID: On Fri, 27 May 2022 13:20:24 GMT, Daniel Jeli?ski wrote: > Session ticket extension should only contain pre-TLS1.3 stateless session tickets; it should not be used for sending TLS1.3 pre-shared keys. src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 410: > 408: || chc.resumingSession.getPskIdentity() == null > 409: || !Arrays.asList(ProtocolVersion.PROTOCOLS_10_12) > 410: .contains(chc.resumingSession.getProtocolVersion())) { would `chc.resumingSession.getProtocolVersion().useTLS13PlusSpec()` read better for your last condition ? Might save on Array allocations also ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8922 From duke at openjdk.java.net Tue May 31 19:30:07 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 31 May 2022 19:30:07 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v8] In-Reply-To: References: Message-ID: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - 8282662: Revert wrong copyright year change - 8282662: Revert ProxyGenerator - 8282662: Revert ProxyGenerator - 8282662: Revert dubious changes in MethodType - 8282662: Revert dubious changes - 8282662: Use List/Set.of() factory methods to save memory ------------- Changes: https://git.openjdk.java.net/jdk/pull/7729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=07 Stats: 13 lines in 5 files changed: 1 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From rriggs at openjdk.java.net Tue May 31 19:36:44 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 31 May 2022 19:36:44 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v8] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 19:30:07 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - 8282662: Revert wrong copyright year change > - 8282662: Revert ProxyGenerator > - 8282662: Revert ProxyGenerator > - 8282662: Revert dubious changes in MethodType > - 8282662: Revert dubious changes > - 8282662: Use List/Set.of() factory methods to save memory Why the force push? They are discouraged, making it harder to review. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Tue May 31 21:01:59 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 31 May 2022 21:01:59 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v8] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 19:33:15 GMT, Roger Riggs wrote: >> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - 8282662: Revert wrong copyright year change >> - 8282662: Revert ProxyGenerator >> - 8282662: Revert ProxyGenerator >> - 8282662: Revert dubious changes in MethodType >> - 8282662: Revert dubious changes >> - 8282662: Use List/Set.of() factory methods to save memory > > Why the force push? They are discouraged, making it harder to review. @RogerRiggs I've rebased my changes onto master to incorporate the latest changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From rriggs at openjdk.java.net Tue May 31 21:07:50 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 31 May 2022 21:07:50 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v8] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 19:30:07 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - 8282662: Revert wrong copyright year change > - 8282662: Revert ProxyGenerator > - 8282662: Revert ProxyGenerator > - 8282662: Revert dubious changes in MethodType > - 8282662: Revert dubious changes > - 8282662: Use List/Set.of() factory methods to save memory Merging is preferable, it doesn't disturb the history. Usually an explicit merge is not necessary; Skara will indicate when an automatic merge is needed due to conflicts. If you want to run your own tests then use a merge, not rebase. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/7729