From weijun.wang at oracle.com Fri Apr 1 22:15:41 2022 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Fri, 1 Apr 2022 22:15:41 +0000 Subject: Proposal: Extend Windows KeyStore support to include access to the local machine location In-Reply-To: References: Message-ID: Hi Mat, We have 2 main concerns: 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear there and automatically chosen by a key manager. It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. And we have no plan to add other types like ADDRESSBOOK. Thanks, Weijun > On Mar 31, 2022, at 5:16 PM, Mat Carter wrote: > > Current support for KeyStores on Windows is limited to the current user location [1] > > There has been previous request for local machine support [2] along with discussion in the security-dev mailing list [3], further discussions have occurred on stackoverflow in the past [4] and [5] > > Using JNI you can access local machine locations but then you are duplicating much of the existing native functionality; this also adds the requirement that developers need to know C/C++ and the Windows cryptography API. > > Given the above I propose that we add native support for local machine KeyStore locations > > Users can currently access two physical key stores (in the current user location): > > "Windows-MY": .Default > "Windows-ROOT": .Default.LocalMachine, .SmartCard > > Adding the local machine location opens up access to a further two physical key stores ? > > "Windows-MY": .Default > "Windows-ROOT": .Default.AuthRoot, .GroupPolicy, .Enterprise, .SmartCard > > Please let me know if there are any existing efforts to bring this functionality to Java, or references to prior decisions on this subject > > Thanks in advance > Mat Carter > > [1] https://docs.microsoft.com/en-us/windows/win32/seccrypto/system-store-locations > [2] https://bugs.openjdk.java.net/browse/JDK-6782021 > [3] http://mail.openjdk.java.net/pipermail/security-dev/2018-August/017832.html > [4] https://stackoverflow.com/questions/70200603/accessing-windows-local-machine-certificates-from-a-windows-service-written-in-j > [5] https://stackoverflow.com/questions/3612962/access-local-machine-certificate-store-in-java > > > Sent from Outlook From david.lloyd at redhat.com Tue Apr 5 13:52:05 2022 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 5 Apr 2022 08:52:05 -0500 Subject: A possible JEP to replace SecurityManager after JEP 411 Message-ID: Here at Red Hat there have been serious discussions about the impacts of security manager removal on our users, and whether there is an actual value impact, and if so, whether it can be mitigated or reversed somehow. We are interested in exploring whether we can come up with a way in which vendors and projects that wish to continue using SecurityManager (or something like it) would be able to do so, while still removing the majority of the ongoing maintenance burden from the OpenJDK project. Before we make a decision on whether or not we think there is sufficient justification for working up a formal JEP, we have decided that the best first step would be to socialize the idea in a more general form so that we can know whether the upstream OpenJDK team would even be amenable *at all* to the solution (or something like it), particularly in light of the observation that previous threads about retaining SecurityManager in any form have been looked upon in a fairly negative light. The primary idea behind this proposal is that, while all of the points in JEP 411 relating to the lack of what most experts might refer to as "actual security" are certainly true, the SecurityManager mechanism itself does nevertheless have some inherent value. The challenge, then, is to strike a balance between the value provided by retaining some semblance of the mechanism versus the costs inherent in retaining it; we would want as much of the former as possible, for as little of the latter as possible. So, here's the idea. It is assumed (for the sake of common understanding) that as things stand, all of the classes and members marked as "deprecated for removal" as a part of JEP 411 are intended to be completely removed without replacement at the end of the term of deprecation. The proposals here are based on this assumption. The center of this proposal is that, at the end of the term of deprecation, all of the deprecated classes, members, and behavior are still removed (including, and especially, AccessController and Policy and related classes) /except/ as mentioned here: * Rather than completely removing SecurityManager, * The SecurityManager class becomes abstract and non-deprecated, with all of its methods being removed, except as follows * SecurityManager.getSecurityContext() becomes abstract (this is the one that returns Object, *not* the stack walking one) * SecurityManager.checkPermission() (both of them) become abstract * Rather than removing the SecurityManager-related methods from System, * System.getSecurityManager() is retained and de-deprecated * [Optional] System.setSecurityManager() is retained and de-deprecated (we would want to explore whether it is feasible to replace this (and the system property lookup mechanism) using ServiceLoader, if bootstrap allows it) * [Optional] Rather than /immediately/ removing all of AccessController, * Retain its deprecation-for-removal status * Retain only doPrivileged(PrivilegedAction) and doPrivileged(PrivilegedExceptionAction) as simple pass-throughs (no JVM semantics other than being present on the call stack like any method) since they are pervasively used, to allow frameworks time to transition to (for example) a third-party alternative. The burden of permission verification would lie completely with the security manager implementation. The JDK would not have a 'SecurityManager' implementation of any kind, outside of the internal test suite. The other part of this proposal can come in one of two possible flavors. ### Option 1: Authorization interfaces Each point in the JDK where there presently is a permission check is classified into an authorization category of related operations. An interface is introduced for each category which contains the methods encapsulating the relevant check, in a package that is deemed most appropriate for that particular grouping. For example, there might be a 'SocketAuthorization' interface in the 'java.net' package, with methods like 'checkConnect(SocketAddress from, SocketAddress to)' and 'checkAccept(SocketAddress addr)'. At the point where a permission check previously would take place, a check like this is performed instead: if (System.getSecurityManager() instanceof SocketAuthorization sa) { sa.checkAccept(addr); } Any public or protected method with such a check should include @throws Javadoc explaining that a SecurityException may be thrown. The Permission subclasses previously used specifically by these operation sites *may* in this case be deprecated for removal immediately or at some point in the future, if desired. It is the sole responsibility of the SecurityManager implementer to implement the various necessary interfaces, and any third-party authorization interfaces that would also be relevant. ### Option 2: Retain permission system Under this option, the existing authorization checks are mostly retained, however, since the SecurityManager class only has a general 'checkPermission()' method, the logic previously found in the 'SecurityManager' class which expands specific check calls into general 'checkPermission()' calls (for example, calls to 'checkConnect' for sockets) would necessarily become the responsibility of the site of the permission check. Some work would be undertaken to refactor this code accordingly. With this solution, the corresponding Permission subclasses would be retained indefinitely. In either case it is the responsibility of the implementer of SecurityManager to utilize these checks appropriately for authorization decisions, based on whatever factors are deemed appropriate, which may include contextual information such as a currently-authenticated identity or the call stack, or (for example) a context object utilizing the ScopeLocal mechanism. ### Other changes It would be worth exploring whether the SecurityManager installation could be refitted to use the ServiceLoader mechanism (for example at first call to getSecurityManager()) based on the class loader of the application class or module path. This would allow the 'System.setSecurityManager' method, and support for the corresponding system property, to be removed at the end of the term of deprecation. Testing Neither solution would ease the burden of testing from the JDK quite as much as complete removal, of course. The necessary testing for the individual checks should be limited to ensuring that the permission check calls are happening with correct arguments and that any thrown SecurityException is propagated. The policy for testing SecurityManager installation would depend on whether, and to what extent, the more recent changes restricting the installation of the security manager are reversed. Other testing issues may arise as well. -- - DML ? he/him From Matthew.Carter at microsoft.com Tue Apr 5 15:20:46 2022 From: Matthew.Carter at microsoft.com (Mat Carter) Date: Tue, 5 Apr 2022 15:20:46 +0000 Subject: Proposal: Extend Windows KeyStore support to include access to the local machine location In-Reply-To: References: Message-ID: Hi Weijun Thank you for the feedback, I'd like to address point 2 first as I think this might also address point 1 >> 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear? >>?there and automatically chosen by a key manager. >> >>?It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including? >>?new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. I deliberately kept implementation details out of the initial email to focus on the security aspects, but this point makes an assumption that the results of using "Windows-MY" or "Windows-ROOT" would change with this new functionality; this is not what we're proposing. Specifically we're proposing adding two new strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE" such that developers can now access the key stores in the local machine. To be clear, the implementation would make no attempt to "merge" results when enumerating or to search both locations via a single key store instance; i.e. you can only create and instance for accessing either keystore but not both. I think this addresses point 1 also, but if not then I have a follow on question: >> 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is >> trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. Our initial analysis leads us to believe that we'll not need to introduce new code paths to handle new certificates; i.e. the only code changes are how the key store is opened, subsequent calls to access certificates is handled by the existing code. Given the above assumption, your concerns laid out in point 1 and if your concern is not mitigated with our notes for point 2: is it the case that you expect new "types" of certificates to be accessible via local machine that weren't via current user and that some/all of these certs are "bad" (and would need new code paths to handle them)? While we are talking about implementation, there's another aspect we'd like to introduce/discuss: this is to allow developers to access the key stores with read only permissions, thus allowing enumeration and reading without requiring administrative permissions be granted to the application (thus increasing security) Thanks in advance Mat Sent from Outlook From: Wei-Jun Wang Sent: Friday, April 1, 2022 3:15 PM To: Mat Carter Cc: security-dev at openjdk.java.net Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location ? Hi Mat, We have 2 main concerns: 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear there and automatically chosen by a key manager. It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. And we have no plan to add other types like ADDRESSBOOK. Thanks, Weijun > On Mar 31, 2022, at 5:16 PM, Mat Carter wrote: > > Current support for KeyStores on Windows is limited to the current user location [1] > > There has been previous request for local machine support [2] along with discussion in the security-dev mailing list [3], further discussions have occurred on stackoverflow in the past [4] and [5] > > Using JNI you can access local machine locations but then you are duplicating much of the existing native functionality; this also adds the requirement that developers need to know C/C++ and the Windows cryptography API. > > Given the above I propose that we add native support for local machine KeyStore locations > > Users can currently access two physical key stores (in the current user location): > > "Windows-MY": .Default > "Windows-ROOT": .Default.LocalMachine, .SmartCard > > Adding the local machine location opens up access to a further two physical key stores ? > > "Windows-MY": .Default > "Windows-ROOT": .Default.AuthRoot, .GroupPolicy, .Enterprise, .SmartCard > > Please let me know if there are any existing efforts to bring this functionality to Java, or references to prior decisions on this subject > > Thanks in advance > Mat Carter > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fseccrypto%2Fsystem-store-locations&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hWj0cEVRachk47aqIKJYIwiaqTcACjWGn38AzmutX9I%3D&reserved=0 > [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-6782021&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TdXrBjrjqPniADcJiFnwQfi5uaCnI9BzgCPPJe%2FAhGA%3D&reserved=0 > [3] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fsecurity-dev%2F2018-August%2F017832.html&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=O4hI%2BTje%2FjtJTWosTLSNzVlQUW8s%2BoeoWMA27EaAHUc%3D&reserved=0 > [4] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F70200603%2Faccessing-windows-local-machine-certificates-from-a-windows-service-written-in-j&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FNqqbV%2BIircmaoas%2F%2BUX%2F%2BQpWVq9fpoV%2F4lCNB77ZzE%3D&reserved=0 > [5] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F3612962%2Faccess-local-machine-certificate-store-in-java&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JiEifjvBN%2B8ahoft9xdJhLwy1DEjkAWLHIVB1Oojnsk%3D&reserved=0 > > > Sent from Outlook From ecki at zusammenkunft.net Tue Apr 5 18:20:46 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 5 Apr 2022 18:20:46 +0000 Subject: Proposal: Extend Windows KeyStore support to include access to the local machine location In-Reply-To: References: Message-ID: BTW, since this is Windows specific anyway and since we have also a combining virtual Keystore, why not allow a new naming scheme which allows to access any of the Keystores? like ?Windows-ROOT/ADdressbook?? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Mat Carter Gesendet: Dienstag, April 5, 2022 5:22 PM An: Wei-Jun Wang Cc: security-dev at openjdk.java.net Betreff: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location Hi Weijun Thank you for the feedback, I'd like to address point 2 first as I think this might also address point 1 >> 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear >> there and automatically chosen by a key manager. >> >> It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including >> new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. I deliberately kept implementation details out of the initial email to focus on the security aspects, but this point makes an assumption that the results of using "Windows-MY" or "Windows-ROOT" would change with this new functionality; this is not what we're proposing. Specifically we're proposing adding two new strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE" such that developers can now access the key stores in the local machine. To be clear, the implementation would make no attempt to "merge" results when enumerating or to search both locations via a single key store instance; i.e. you can only create and instance for accessing either keystore but not both. I think this addresses point 1 also, but if not then I have a follow on question: >> 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is >> trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. Our initial analysis leads us to believe that we'll not need to introduce new code paths to handle new certificates; i.e. the only code changes are how the key store is opened, subsequent calls to access certificates is handled by the existing code. Given the above assumption, your concerns laid out in point 1 and if your concern is not mitigated with our notes for point 2: is it the case that you expect new "types" of certificates to be accessible via local machine that weren't via current user and that some/all of these certs are "bad" (and would need new code paths to handle them)? While we are talking about implementation, there's another aspect we'd like to introduce/discuss: this is to allow developers to access the key stores with read only permissions, thus allowing enumeration and reading without requiring administrative permissions be granted to the application (thus increasing security) Thanks in advance Mat Sent from Outlook From: Wei-Jun Wang Sent: Friday, April 1, 2022 3:15 PM To: Mat Carter Cc: security-dev at openjdk.java.net Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location Hi Mat, We have 2 main concerns: 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear there and automatically chosen by a key manager. It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. And we have no plan to add other types like ADDRESSBOOK. Thanks, Weijun > On Mar 31, 2022, at 5:16 PM, Mat Carter wrote: > > Current support for KeyStores on Windows is limited to the current user location [1] > > There has been previous request for local machine support [2] along with discussion in the security-dev mailing list [3], further discussions have occurred on stackoverflow in the past [4] and [5] > > Using JNI you can access local machine locations but then you are duplicating much of the existing native functionality; this also adds the requirement that developers need to know C/C++ and the Windows cryptography API. > > Given the above I propose that we add native support for local machine KeyStore locations > > Users can currently access two physical key stores (in the current user location): > > "Windows-MY": .Default > "Windows-ROOT": .Default.LocalMachine, .SmartCard > > Adding the local machine location opens up access to a further two physical key stores ? > > "Windows-MY": .Default > "Windows-ROOT": .Default.AuthRoot, .GroupPolicy, .Enterprise, .SmartCard > > Please let me know if there are any existing efforts to bring this functionality to Java, or references to prior decisions on this subject > > Thanks in advance > Mat Carter > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fseccrypto%2Fsystem-store-locations&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hWj0cEVRachk47aqIKJYIwiaqTcACjWGn38AzmutX9I%3D&reserved=0 > [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-6782021&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TdXrBjrjqPniADcJiFnwQfi5uaCnI9BzgCPPJe%2FAhGA%3D&reserved=0 > [3] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fsecurity-dev%2F2018-August%2F017832.html&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=O4hI%2BTje%2FjtJTWosTLSNzVlQUW8s%2BoeoWMA27EaAHUc%3D&reserved=0 > [4] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F70200603%2Faccessing-windows-local-machine-certificates-from-a-windows-service-written-in-j&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FNqqbV%2BIircmaoas%2F%2BUX%2F%2BQpWVq9fpoV%2F4lCNB77ZzE%3D&reserved=0 > [5] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F3612962%2Faccess-local-machine-certificate-store-in-java&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JiEifjvBN%2B8ahoft9xdJhLwy1DEjkAWLHIVB1Oojnsk%3D&reserved=0 > > > Sent from Outlook -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.java.net Wed Apr 6 00:03:38 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 6 Apr 2022 00:03:38 GMT Subject: RFR: 8284368: Remove finalizer method in jdk.crypto.cryptoki In-Reply-To: <1vD9umu7E2oG6FfQQG3btY-Hqpjnq8r0jgvY2QrY83M=.9d946ead-a837-4bdc-adf4-4f4e029c1078@github.com> References: <1vD9umu7E2oG6FfQQG3btY-Hqpjnq8r0jgvY2QrY83M=.9d946ead-a837-4bdc-adf4-4f4e029c1078@github.com> Message-ID: On Tue, 5 Apr 2022 19:55:55 GMT, Xue-Lei Andrew Fan wrote: > Please review the update to remove finalizer method in the jdk.crypto.cryptoki module. It is one of the efforts to clean up the use of finalizer method in JDK. Looks good. Thanks! ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8112 From valeriep at openjdk.java.net Wed Apr 6 00:22:07 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 6 Apr 2022 00:22:07 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() 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~ ------------- Commit messages: - 8209038: Clarify the javadoc of Cipher.getParameters() Changes: https://git.openjdk.java.net/jdk/pull/8117/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8117&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8209038 Stats: 254 lines in 2 files changed: 2 ins; 5 del; 247 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 Wed Apr 6 00:27:40 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 6 Apr 2022 00:27:40 GMT Subject: RFR: 8284291: sun/security/krb5/auto/Renew.java fails intermittently on Windows 11 In-Reply-To: References: <7cLC6wodHE-fIdkYIcrtWyuR-JDBncmnBM9KUpAluK4=.96ca7029-35c7-4b42-bf18-5d81a7c1dc03@github.com> Message-ID: On Tue, 5 Apr 2022 08:23:39 GMT, Andrey Turbanov wrote: >> `Thread.sleep()` seems not very precise on some systems. Update this test to check the current time continously. > > 50 repeats. No failures. Thank you! @turbanoff Thanks for the code review. At the same time, I'm still curious why this could happen on your machine. If after `Thread.sleep(7000)` but the difference of `System.currentTimeMillis()` is less than 5000, then there must be a serious bug in either of the methods. How about the difference between `System.nanoTime()`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8098 From peter.firmstone at zeus.net.au Wed Apr 6 01:18:21 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 6 Apr 2022 11:18:21 +1000 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: Message-ID: <0fdd20f4-084c-1bdb-fcb7-8dc99db02781@zeus.net.au> Thanks David, I'd certainly support such a proposal and encourage OpenJDK to consider exploring it. Perhaps also consider; no privileges should be granted unless a privileged call is made, this simplifies the the stack walk, such that it's only required when a privileged call is made. With a policy tool that generates policy files, it allows the developer to turn off all features that are not required, which improves security. Something that bothered me about SocketPermission was that it didn't allow granting permission to subnets, or ranges of IP addresses. It always bothered me that data parsing isn't controlled with permissions. For data parsing the remote authenticated subject represents the source of the data, if the data source cannot be authenticated, then data cannot be parsed.?? Of? course when parsing is done it needs to be validated, but authentication goes a long way to filtering out potential attack vectors. -- Regards, Peter On 5/04/2022 11:52 pm, David Lloyd wrote: > Here at Red Hat there have been serious discussions about the impacts > of security manager removal on our users, and whether there is an > actual value impact, and if so, whether it can be mitigated or > reversed somehow. We are interested in exploring whether we can come > up with a way in which vendors and projects that wish to continue > using SecurityManager (or something like it) would be able to do so, > while still removing the majority of the ongoing maintenance burden > from the OpenJDK project. > > Before we make a decision on whether or not we think there is > sufficient justification for working up a formal JEP, we have decided > that the best first step would be to socialize the idea in a more > general form so that we can know whether the upstream OpenJDK team > would even be amenable *at all* to the solution (or something like > it), particularly in light of the observation that previous threads > about retaining SecurityManager in any form have been looked upon in a > fairly negative light. > > The primary idea behind this proposal is that, while all of the points > in JEP 411 relating to the lack of what most experts might refer to as > "actual security" are certainly true, the SecurityManager mechanism > itself does nevertheless have some inherent value. The challenge, > then, is to strike a balance between the value provided by retaining > some semblance of the mechanism versus the costs inherent in retaining > it; we would want as much of the former as possible, for as little of > the latter as possible. > > So, here's the idea. It is assumed (for the sake of common > understanding) that as things stand, all of the classes and members > marked as "deprecated for removal" as a part of JEP 411 are intended > to be completely removed without replacement at the end of the term of > deprecation. The proposals here are based on this assumption. > > The center of this proposal is that, at the end of the term of > deprecation, all of the deprecated classes, members, and behavior are > still removed (including, and especially, AccessController and Policy > and related classes) /except/ as mentioned here: > > * Rather than completely removing SecurityManager, > * The SecurityManager class becomes abstract and non-deprecated, > with all of its methods being removed, except as follows > * SecurityManager.getSecurityContext() becomes abstract (this is > the one that returns Object, *not* the stack walking one) > * SecurityManager.checkPermission() (both of them) become abstract > * Rather than removing the SecurityManager-related methods from System, > * System.getSecurityManager() is retained and de-deprecated > * [Optional] System.setSecurityManager() is retained and > de-deprecated (we would want to explore whether it is feasible to > replace this (and the system property lookup mechanism) using > ServiceLoader, if bootstrap allows it) > * [Optional] Rather than /immediately/ removing all of AccessController, > * Retain its deprecation-for-removal status > * Retain only doPrivileged(PrivilegedAction) and > doPrivileged(PrivilegedExceptionAction) as simple pass-throughs (no > JVM semantics other than being present on the call stack like any > method) since they are pervasively used, to allow frameworks time to > transition to (for example) a third-party alternative. > > The burden of permission verification would lie completely with the > security manager implementation. The JDK would not have a > 'SecurityManager' implementation of any kind, outside of the internal > test suite. > > The other part of this proposal can come in one of two possible flavors. > > ### Option 1: Authorization interfaces > > Each point in the JDK where there presently is a permission check is > classified into an authorization category of related operations. An > interface is introduced for each category which contains the methods > encapsulating the relevant check, in a package that is deemed most > appropriate for that particular grouping. For example, there might be > a 'SocketAuthorization' interface in the 'java.net' package, with > methods like 'checkConnect(SocketAddress from, SocketAddress to)' and > 'checkAccept(SocketAddress addr)'. > > At the point where a permission check previously would take place, a > check like this is performed instead: > > if (System.getSecurityManager() instanceof SocketAuthorization sa) { > sa.checkAccept(addr); > } > > Any public or protected method with such a check should include > @throws Javadoc explaining that a SecurityException may be thrown. > > The Permission subclasses previously used specifically by these > operation sites *may* in this case be deprecated for removal > immediately or at some point in the future, if desired. > > It is the sole responsibility of the SecurityManager implementer to > implement the various necessary interfaces, and any third-party > authorization interfaces that would also be relevant. > > ### Option 2: Retain permission system > > Under this option, the existing authorization checks are mostly > retained, however, since the SecurityManager class only has a general > 'checkPermission()' method, the logic previously found in the > 'SecurityManager' class which expands specific check calls into > general 'checkPermission()' calls (for example, calls to > 'checkConnect' for sockets) would necessarily become the > responsibility of the site of the permission check. Some work would > be undertaken > to refactor this code accordingly. > > With this solution, the corresponding Permission subclasses would be > retained indefinitely. > > In either case it is the responsibility of the implementer of > SecurityManager to utilize these checks appropriately for > authorization decisions, based on whatever factors are deemed > appropriate, which may include contextual information such as a > currently-authenticated identity or the call stack, or (for example) a > context object utilizing the ScopeLocal mechanism. > > ### Other changes > > It would be worth exploring whether the SecurityManager installation > could be refitted to use the ServiceLoader mechanism (for example at > first call to getSecurityManager()) based on the class loader of the > application class or module path. This would allow the > 'System.setSecurityManager' method, and support for the corresponding > system property, to be removed at the end of the term of deprecation. > > Testing > > Neither solution would ease the burden of testing from the JDK quite > as much as complete removal, of course. The necessary testing for the > individual checks should be limited to ensuring that the permission > check calls are happening with correct arguments and that any thrown > SecurityException is propagated. The policy for testing > SecurityManager installation would depend on whether, and to what > extent, the more recent changes restricting the installation of the > security manager are reversed. Other testing issues may arise as > well. > From aturbanov at openjdk.java.net Wed Apr 6 06:23:06 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Apr 2022 06:23:06 GMT Subject: RFR: 8284415: Collapse identical catch branches in security libs Message-ID: <5q2_gdZ1cY16oQ0583XLLn70PWtfTfzHm0hcW0-ZKL8=.510889b4-1f49-4a2c-8c6f-da19d6fd29ce@github.com> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". It simplifies code. Reduces duplication. Found by IntelliJ IDEA inspection `Identical 'catch' branches in 'try' statement` ------------- Commit messages: - [PATCH] Collapse identical catch branches in security libs - [PATCH] Collapse identical catch branches in security libs Changes: https://git.openjdk.java.net/jdk/pull/8068/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8068&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284415 Stats: 197 lines in 32 files changed: 1 ins; 124 del; 72 mod Patch: https://git.openjdk.java.net/jdk/pull/8068.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8068/head:pull/8068 PR: https://git.openjdk.java.net/jdk/pull/8068 From dfuchs at openjdk.java.net Wed Apr 6 10:23:45 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 6 Apr 2022 10:23:45 GMT Subject: RFR: JDK-8284353 : Update java/net and sun/net/www tests to eliminate dependency on sun.net.www.MessageHeader In-Reply-To: References: Message-ID: On Tue, 5 Apr 2022 10:27:54 GMT, Mahendra Chhipa wrote: > Updated java/net and sun/net/www tests to remove dependency on sun.net.www.MessageHeader. Looks reasonable to me, but please make sure the tests are stable before pushing. The proxy/tunnel classes have exhibited some instability in the past and it would be good to make sure they remain stable with proposed changes. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8105 From coffeys at openjdk.java.net Wed Apr 6 14:24:39 2022 From: coffeys at openjdk.java.net (Sean Coffey) Date: Wed, 6 Apr 2022 14:24:39 GMT Subject: RFR: 8284415: Collapse identical catch branches in security libs In-Reply-To: <5q2_gdZ1cY16oQ0583XLLn70PWtfTfzHm0hcW0-ZKL8=.510889b4-1f49-4a2c-8c6f-da19d6fd29ce@github.com> References: <5q2_gdZ1cY16oQ0583XLLn70PWtfTfzHm0hcW0-ZKL8=.510889b4-1f49-4a2c-8c6f-da19d6fd29ce@github.com> Message-ID: <7_pciSQ0ZTk8xBO4IC13BrW4JIMVH7StRkczF3fWJz0=.3250b851-a6a3-4224-9550-912f7478efcb@github.com> On Fri, 1 Apr 2022 07:32:21 GMT, Andrey Turbanov wrote: > Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". > It simplifies code. Reduces duplication. > Found by IntelliJ IDEA inspection `Identical 'catch' branches in 'try' statement` Looks fine! ------------- Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8068 From xuelei at openjdk.java.net Wed Apr 6 15:25:39 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 6 Apr 2022 15:25:39 GMT Subject: RFR: 8284415: Collapse identical catch branches in security libs In-Reply-To: <5q2_gdZ1cY16oQ0583XLLn70PWtfTfzHm0hcW0-ZKL8=.510889b4-1f49-4a2c-8c6f-da19d6fd29ce@github.com> References: <5q2_gdZ1cY16oQ0583XLLn70PWtfTfzHm0hcW0-ZKL8=.510889b4-1f49-4a2c-8c6f-da19d6fd29ce@github.com> Message-ID: On Fri, 1 Apr 2022 07:32:21 GMT, Andrey Turbanov wrote: > Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". > It simplifies code. Reduces duplication. > Found by IntelliJ IDEA inspection `Identical 'catch' branches in 'try' statement` Looks good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8068 From xuelei at openjdk.java.net Wed Apr 6 16:04:35 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 6 Apr 2022 16:04:35 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() In-Reply-To: References: Message-ID: 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~ src/java.base/share/classes/javax/crypto/Cipher.java line 1051: > 1049: * Returns the parameters used with this cipher. > 1050: * > 1051: *

If this cipher has been previously initialized with parameters, > If this cipher has been previously initialized with parameters, this method returns the same parameters. Previously, "may" is used ("may be the same ..."). This change looks too strict for compatibility. I had a look at the AES implementation, the parameters initialized with init() could be filtered and modified before saving the parameters related class fields. src/java.base/share/classes/javax/crypto/Cipher.java line 1053: > 1051: *

If this cipher has been previously initialized with parameters, > 1052: * this method returns the same parameters. Otherwise, this method may > 1053: * return a combination of user-supplied, default and randomly generated > ... a combination of user-supplied, default and randomly generated parameter values ... Other than init(), which APIs could impact the user-supplied parameters? Is it the getInstance()? Is it OK to just use the provider-specific default values instead, by replacing the "a combination of user-supplied, default and randomly generated ..."? ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From xuelei at openjdk.java.net Wed Apr 6 17:12:46 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 6 Apr 2022 17:12:46 GMT Subject: Integrated: 8284368: Remove finalizer method in jdk.crypto.cryptoki In-Reply-To: <1vD9umu7E2oG6FfQQG3btY-Hqpjnq8r0jgvY2QrY83M=.9d946ead-a837-4bdc-adf4-4f4e029c1078@github.com> References: <1vD9umu7E2oG6FfQQG3btY-Hqpjnq8r0jgvY2QrY83M=.9d946ead-a837-4bdc-adf4-4f4e029c1078@github.com> Message-ID: On Tue, 5 Apr 2022 19:55:55 GMT, Xue-Lei Andrew Fan wrote: > Please review the update to remove finalizer method in the jdk.crypto.cryptoki 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: 77388eaf Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/77388eaf2595f5785bb0945ccecf84c4916031e7 Stats: 27 lines in 2 files changed: 7 ins; 20 del; 0 mod 8284368: Remove finalizer method in jdk.crypto.cryptoki Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/8112 From mstjohns at comcast.net Wed Apr 6 17:43:03 2022 From: mstjohns at comcast.net (Mike StJohns) Date: Wed, 6 Apr 2022 13:43:03 -0400 Subject: RFR: 8284415: Collapse identical catch branches in security libs In-Reply-To: References: Message-ID: <57D20FA9-991B-41E6-A06E-F8EE2D5ECC2C@comcast.net> Before you approve this, why would you rethrow just the message rather than the actual original cause? Seems like you?re losing debug info including the type of the original exception for no good reason. Mike Sent from my iPad > On Apr 6, 2022, at 11:26, Xue-Lei Andrew Fan wrote: > > ?On Fri, 1 Apr 2022 07:32:21 GMT, Andrey Turbanov wrote: > >> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". >> It simplifies code. Reduces duplication. >> Found by IntelliJ IDEA inspection `Identical 'catch' branches in 'try' statement` > > Looks good to me. > > ------------- > > Marked as reviewed by xuelei (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/8068 From naoto at openjdk.java.net Wed Apr 6 17:52:08 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 6 Apr 2022 17:52:08 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test Message-ID: This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. ------------- Commit messages: - 8283698: Refactor Locale constructors used in src/test Changes: https://git.openjdk.java.net/jdk/pull/8130/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8130&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283698 Stats: 750 lines in 182 files changed: 3 ins; 3 del; 744 mod Patch: https://git.openjdk.java.net/jdk/pull/8130.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8130/head:pull/8130 PR: https://git.openjdk.java.net/jdk/pull/8130 From xueleifan at tencent.com Wed Apr 6 18:34:34 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Wed, 6 Apr 2022 18:34:34 +0000 Subject: [Internet]Re: RFR: 8284415: Collapse identical catch branches in security libs In-Reply-To: <57D20FA9-991B-41E6-A06E-F8EE2D5ECC2C@comcast.net> References: <57D20FA9-991B-41E6-A06E-F8EE2D5ECC2C@comcast.net> Message-ID: I think it is a good point, Mike. Some of the exception constructors do not accept cause parameters, for example UnrecoverableKeyException. And some others do, for example InvalidKeyException. I would like to keep original cause. I read this patch as a format clean-up. It is fine to me to have an additional update to take the causes back. But I appreciate if Andrey could take care of the update in the PR as well. Xuelei > On Apr 6, 2022, at 10:43 AM, Mike StJohns wrote: > > Before you approve this, why would you rethrow just the message rather than the actual original cause? Seems like you?re losing debug info including the type of the original exception for no good reason. > > Mike > > Sent from my iPad > >> On Apr 6, 2022, at 11:26, Xue-Lei Andrew Fan wrote: >> >> ?On Fri, 1 Apr 2022 07:32:21 GMT, Andrey Turbanov wrote: >> >>> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". >>> It simplifies code. Reduces duplication. >>> Found by IntelliJ IDEA inspection `Identical 'catch' branches in 'try' statement` >> >> Looks good to me. >> >> ------------- >> >> Marked as reviewed by xuelei (Reviewer). >> >> PR: https://git.openjdk.java.net/jdk/pull/8068 > > From valeriep at openjdk.java.net Wed Apr 6 19:20:42 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 6 Apr 2022 19:20:42 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 15:48:26 GMT, Xue-Lei Andrew Fan 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~ > > src/java.base/share/classes/javax/crypto/Cipher.java line 1051: > >> 1049: * Returns the parameters used with this cipher. >> 1050: * >> 1051: *

If this cipher has been previously initialized with parameters, > >> If this cipher has been previously initialized with parameters, this method returns the same parameters. > > Previously, "may" is used ("may be the same ..."). This change looks too strict for compatibility. I had a look at the AES implementation, the parameters initialized with init() could be filtered and modified before saving the parameters related class fields. Can you be more specific like which block of code that you are referring to as the filtering and modification? I'd expect the intention is to use the parameter specified. Otherwise an exception should be thrown if the specified parameter is invalid. Only when no parameter is specified, the provider would try to generate the parameters using whatever values it has or got. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From iris at openjdk.java.net Wed Apr 6 19:36:40 2022 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 6 Apr 2022 19:36:40 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From david.lloyd at redhat.com Wed Apr 6 19:37:38 2022 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 6 Apr 2022 14:37:38 -0500 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: <0fdd20f4-084c-1bdb-fcb7-8dc99db02781@zeus.net.au> References: <0fdd20f4-084c-1bdb-fcb7-8dc99db02781@zeus.net.au> Message-ID: Thanks for responding Peter, I've commented inline below. On Tue, Apr 5, 2022 at 8:19 PM Peter Firmstone wrote: > > Thanks David, > > I'd certainly support such a proposal and encourage OpenJDK to consider > exploring it. > > Perhaps also consider; no privileges should be granted unless a > privileged call is made, this simplifies the the stack walk, such that > it's only required when a privileged call is made. I think this is a reasonable requirement for an implementation. If we move forward with this however, the proposal would explicitly not specify how privileges are established or propagated; that would be implementation-defined. > With a policy tool that generates policy files, it allows the developer > to turn off all features that are not required, which improves security. Policy is specifically excluded from the proposal and would be implementation-defined. This should grant significantly more flexibility to meet the authorization needs of the end user. For example, one implementation could be designed to perform authorization checks based on the call stack, like AccessController does today. Another implementation might authorize based on an authenticated user identity and not be concerned with the call stack at all. Other implementations might do both. > Something that bothered me about SocketPermission was that it didn't > allow granting permission to subnets, or ranges of IP addresses. > > It always bothered me that data parsing isn't controlled with permissions. > > For data parsing the remote authenticated subject represents the source > of the data, if the data source cannot be authenticated, then data > cannot be parsed. Of course when parsing is done it needs to be > validated, but authentication goes a long way to filtering out potential > attack vectors. By removing the bulk of the specification from the JDK, the implementation is more free to define how permissions are granted and checked (for example, by authorizing by CIDR ranges rather than by single addresses). Both proposal options would allow for the possibility of adding more authorization checks in the future in a reasonably backwards compatible way, though I think in practice it is unlikely (except maybe in the context of new features that might benefit from such checks). The reason that this is a "proposal to propose" rather than an actual proposal is because we ourselves do not have a clear answer as to whether the costs even of this simplified compromise solution are low enough, compared to the expected value return, to justify the work necessary to produce a formal proposal and prototype. If the upstream consensus is "no, we're not likely to approve this", we're going to consider having to plead our case when we decide whether we want to devote that effort as an additional cost. And we really do have to balance cost and benefit *to us* as well as to the OpenJDK team. When suggesting new features it's always tempting to try and "boil the ocean", especially when inspiration strikes and one is tempted to incorporate dozens of new and interesting ideas. But in this particular case, the real benefit comes from figuring out what we can *remove* versus what must be kept: the more we can remove, the simpler the change would be, and the more likely it will be that we can justify the labor involved in making the change - and, I think, the more likely that the proposal would be palatable to the upstream OpenJDK maintainers. As a final note, I don't think that any context-based authorization based system would really suffice for handling tainted data, unfortunately. For some languages, tainted data is handled at a language level. We would not set out to solve that problem with this proposal, though I think we would all agree that this is a real problem and I think it's safe to speculate that Red Hat would likely be in favor of any effort to tackle it. -- - DML ? he/him From xuelei at openjdk.java.net Wed Apr 6 19:45:40 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 6 Apr 2022 19:45:40 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 19:17:38 GMT, Valerie Peng wrote: >> src/java.base/share/classes/javax/crypto/Cipher.java line 1051: >> >>> 1049: * Returns the parameters used with this cipher. >>> 1050: * >>> 1051: *

If this cipher has been previously initialized with parameters, >> >>> If this cipher has been previously initialized with parameters, this method returns the same parameters. >> >> Previously, "may" is used ("may be the same ..."). This change looks too strict for compatibility. I had a look at the AES implementation, the parameters initialized with init() could be filtered and modified before saving the parameters related class fields. > > Can you be more specific like which block of code that you are referring to as the filtering and modification? > I'd expect the intention is to use the parameter specified. Otherwise an exception should be thrown if the specified parameter is invalid. Only when no parameter is specified, the provider would try to generate the parameters using whatever values it has or got. I read the following methods in com.sun.crypto.provider.CipherCore: void init(int opmode, Key key, AlgorithmParameterSpec params, SecureRandom random) where the 'params' are converted to IV byte array for further processing. void init(int opmode, Key key, AlgorithmParameters params, SecureRandom random) where the spec is retrieved from the 'params', and then pass the call to the init() method above. AlgorithmParameters getParameters(String algName) { where the returned parameters are re-constructed. It may be fine to use a strict spec, but there is a chance to have compatibility impact unless we check the implementation carefully. It may not worthy the risks as a behavioral update may be not necessary for developers. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From valeriep at openjdk.java.net Wed Apr 6 19:51:46 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 6 Apr 2022 19:51:46 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() In-Reply-To: References: Message-ID: <17UlP2PIZ3DEMjUNy95_mJ0HteRN3g3CP3rBSbfpYN4=.dfc6c034-46d3-4293-ae0d-2d459d0c1ce6@github.com> On Wed, 6 Apr 2022 16:00:10 GMT, Xue-Lei Andrew Fan 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~ > > src/java.base/share/classes/javax/crypto/Cipher.java line 1053: > >> 1051: *

If this cipher has been previously initialized with parameters, >> 1052: * this method returns the same parameters. Otherwise, this method may >> 1053: * return a combination of user-supplied, default and randomly generated > >> ... a combination of user-supplied, default and randomly generated parameter values ... > > Other than init(), which APIs could impact the user-supplied parameters? Is it the getInstance()? > > Is it OK to just use the provider-specific default values instead, by replacing the "a combination of user-supplied, default and randomly generated ..."? I am thinking just init() as it takes parameters. Let me take a second look at various Cipher algorithm implementations and see if this can be further pared down. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From aturbanov at openjdk.java.net Wed Apr 6 21:04:42 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Apr 2022 21:04:42 GMT Subject: RFR: 8284415: Collapse identical catch branches in security libs In-Reply-To: <5q2_gdZ1cY16oQ0583XLLn70PWtfTfzHm0hcW0-ZKL8=.510889b4-1f49-4a2c-8c6f-da19d6fd29ce@github.com> References: <5q2_gdZ1cY16oQ0583XLLn70PWtfTfzHm0hcW0-ZKL8=.510889b4-1f49-4a2c-8c6f-da19d6fd29ce@github.com> Message-ID: <2i76zuadoDs5TlF0PfJbyX0J9jMWNGidpKHKDl6mPk4=.ad50b28c-a3e0-4a15-b41d-012d46966312@github.com> On Fri, 1 Apr 2022 07:32:21 GMT, Andrey Turbanov wrote: > Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". > It simplifies code. Reduces duplication. > Found by IntelliJ IDEA inspection `Identical 'catch' branches in 'try' statement` I think changing behavior (like adding cause) requires at least writing regression test. I would like to not do this under this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8068 From wetmore at openjdk.java.net Wed Apr 6 23:22:41 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 6 Apr 2022 23:22:41 GMT Subject: RFR: 8284415: Collapse identical catch branches in security libs In-Reply-To: <5q2_gdZ1cY16oQ0583XLLn70PWtfTfzHm0hcW0-ZKL8=.510889b4-1f49-4a2c-8c6f-da19d6fd29ce@github.com> References: <5q2_gdZ1cY16oQ0583XLLn70PWtfTfzHm0hcW0-ZKL8=.510889b4-1f49-4a2c-8c6f-da19d6fd29ce@github.com> Message-ID: <6CibHE5awfvrs92Cp8ZfDp4UQi9P6pQ4oKCJcDZpGV4=.87849ea1-be7c-4b0e-905c-8d60a08632d1@github.com> On Fri, 1 Apr 2022 07:32:21 GMT, Andrey Turbanov wrote: > Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". > It simplifies code. Reduces duplication. > Found by IntelliJ IDEA inspection `Identical 'catch' branches in 'try' statement` Other that the 1 copyright issue, LGTM. I didn't notice any expect behavioral changes between the new and old code. src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java line 788: > 786: > 787: } > 788: } catch (KrbException | IOException e) { Please update copyright date. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8068 From joehw at openjdk.java.net Thu Apr 7 00:13:45 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 7 Apr 2022 00:13:45 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81: > 79: > 80: /** > 81: * Parse a name like "fr_FR" into Locale.of("fr", "FR", ""); Locale.France? ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From joehw at openjdk.java.net Thu Apr 7 00:20:31 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 7 Apr 2022 00:20:31 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. test/jdk/java/text/Format/DateFormat/NonGregorianFormatTest.java line 131: > 129: > 130: // Tests with the Japanese imperial calendar > 131: Locale calendarLocale = Locale.of("ja", "JP", "JP"); Locale.JAPAN? ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From joehw at openjdk.java.net Thu Apr 7 00:31:55 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 7 Apr 2022 00:31:55 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63: > 61: Locale.of("it", "IT", "EURO"), > 62: Locale.forLanguageTag("de-AT"), > 63: Locale.forLanguageTag("fr-CH"), Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways. test/jdk/java/text/Format/common/Bug6215962.java line 58: > 56: check(mf1, mf2, false); > 57: > 58: mf1 = new MessageFormat("{0}", Locale.of("ja", "JP")); Locale.JAPAN? ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From naoto at openjdk.java.net Thu Apr 7 01:19:35 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 7 Apr 2022 01:19:35 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 00:09:58 GMT, Joe Wang wrote: >> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. > > test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81: > >> 79: >> 80: /** >> 81: * Parse a name like "fr_FR" into Locale.of("fr", "FR", ""); > > Locale.France? The test code parses the input string (eg. "fr_FR") into 3 elements, `name`, `country`, and `variant`, then create a `Locale` using those 3 elements. Changing it to `Locale.FRANCE` does not seem right here. > test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63: > >> 61: Locale.of("it", "IT", "EURO"), >> 62: Locale.forLanguageTag("de-AT"), >> 63: Locale.forLanguageTag("fr-CH"), > > Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways. `Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it validates the input language tag, while `Locale.of()` doesn't as well as Locale constructors. > test/jdk/java/text/Format/common/Bug6215962.java line 58: > >> 56: check(mf1, mf2, false); >> 57: >> 58: mf1 = new MessageFormat("{0}", Locale.of("ja", "JP")); > > Locale.JAPAN? The test intends to compare the generated `MessageFormat` objects (`mf2` & `mf1`) from using a constant `Locale.JAPAN` and the factory method. So I believe leaving it as `Locale.of()` makes sense. ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From xuelei at openjdk.java.net Thu Apr 7 04:17:59 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Apr 2022 04:17:59 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss 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. ------------- Commit messages: - 8284490: Remove finalizer method in java.security.jgss Changes: https://git.openjdk.java.net/jdk/pull/8136/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284490 Stats: 40 lines in 3 files changed: 20 ins; 15 del; 5 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 joehw at openjdk.java.net Thu Apr 7 04:51:38 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 7 Apr 2022 04:51:38 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: <0Zxp9nACKCy12wn8Viwd5lYHz3KXojuy02cZLiz8Wiw=.f1a9f3b3-8cfb-4845-87e7-bef9b69ada8a@github.com> On Thu, 7 Apr 2022 01:16:27 GMT, Naoto Sato wrote: >> test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81: >> >>> 79: >>> 80: /** >>> 81: * Parse a name like "fr_FR" into Locale.of("fr", "FR", ""); >> >> Locale.France? > > The test code parses the input string (eg. "fr_FR") into 3 elements, `name`, `country`, and `variant`, then create a `Locale` using those 3 elements. Changing it to `Locale.FRANCE` does not seem right here. I see. ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From joehw at openjdk.java.net Thu Apr 7 04:59:39 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 7 Apr 2022 04:59:39 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From joehw at openjdk.java.net Thu Apr 7 04:59:40 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 7 Apr 2022 04:59:40 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 01:16:32 GMT, Naoto Sato wrote: >> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63: >> >>> 61: Locale.of("it", "IT", "EURO"), >>> 62: Locale.forLanguageTag("de-AT"), >>> 63: Locale.forLanguageTag("fr-CH"), >> >> Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways. > > `Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it validates the input language tag, while `Locale.of()` doesn't as well as Locale constructors. Ok, I didn't realize the existing method is preferred over the new method in creating a Locale. The javadoc does state that it does not make any syntactic checks. That's good to know. ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From peter.firmstone at zeus.net.au Thu Apr 7 07:08:22 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 7 Apr 2022 17:08:22 +1000 Subject: RFR: 8284490: Remove finalizer method in java.security.jgss In-Reply-To: References: Message-ID: Looks good to me, removes credentials when phantom reachable, doesn't do anything that would prevent it from becoming reachable.? You removed the GNSSException that wasn't thrown. Regards, Peter. On 7/04/2022 2:17 pm, 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. > > ------------- > > Commit messages: > - 8284490: Remove finalizer method in java.security.jgss > > Changes: https://git.openjdk.java.net/jdk/pull/8136/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8284490 > Stats: 40 lines in 3 files changed: 20 ins; 15 del; 5 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 aturbanov at openjdk.java.net Thu Apr 7 07:52:29 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 7 Apr 2022 07:52:29 GMT Subject: RFR: 8284415: Collapse identical catch branches in security libs [v2] In-Reply-To: <5q2_gdZ1cY16oQ0583XLLn70PWtfTfzHm0hcW0-ZKL8=.510889b4-1f49-4a2c-8c6f-da19d6fd29ce@github.com> References: <5q2_gdZ1cY16oQ0583XLLn70PWtfTfzHm0hcW0-ZKL8=.510889b4-1f49-4a2c-8c6f-da19d6fd29ce@github.com> Message-ID: > Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". > It simplifies code. Reduces duplication. > Found by IntelliJ IDEA inspection `Identical 'catch' branches in 'try' statement` Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8284415: Collapse identical catch branches in security libs update one more copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8068/files - new: https://git.openjdk.java.net/jdk/pull/8068/files/3dd769bc..1e7109d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8068&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8068&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8068.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8068/head:pull/8068 PR: https://git.openjdk.java.net/jdk/pull/8068 From aturbanov at openjdk.java.net Thu Apr 7 10:03:45 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 7 Apr 2022 10:03:45 GMT Subject: RFR: 8284415: Collapse identical catch branches in security libs [v2] In-Reply-To: References: <5q2_gdZ1cY16oQ0583XLLn70PWtfTfzHm0hcW0-ZKL8=.510889b4-1f49-4a2c-8c6f-da19d6fd29ce@github.com> Message-ID: On Thu, 7 Apr 2022 07:52:29 GMT, Andrey Turbanov wrote: >> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". >> It simplifies code. Reduces duplication. >> Found by IntelliJ IDEA inspection `Identical 'catch' branches in 'try' statement` > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8284415: Collapse identical catch branches in security libs > update one more copyright Thank you for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8068 From aturbanov at openjdk.java.net Thu Apr 7 10:03:45 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 7 Apr 2022 10:03:45 GMT Subject: Integrated: 8284415: Collapse identical catch branches in security libs In-Reply-To: <5q2_gdZ1cY16oQ0583XLLn70PWtfTfzHm0hcW0-ZKL8=.510889b4-1f49-4a2c-8c6f-da19d6fd29ce@github.com> References: <5q2_gdZ1cY16oQ0583XLLn70PWtfTfzHm0hcW0-ZKL8=.510889b4-1f49-4a2c-8c6f-da19d6fd29ce@github.com> Message-ID: On Fri, 1 Apr 2022 07:32:21 GMT, Andrey Turbanov wrote: > Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". > It simplifies code. Reduces duplication. > Found by IntelliJ IDEA inspection `Identical 'catch' branches in 'try' statement` This pull request has now been integrated. Changeset: 8e58d4a5 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/8e58d4a58925c79fcdd2efa62cc2a6affd6326b1 Stats: 198 lines in 32 files changed: 1 ins; 124 del; 73 mod 8284415: Collapse identical catch branches in security libs Reviewed-by: coffeys, xuelei, wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/8068 From duke at openjdk.java.net Thu Apr 7 10:22:54 2022 From: duke at openjdk.java.net (Mahendra Chhipa) Date: Thu, 7 Apr 2022 10:22:54 GMT Subject: Integrated: JDK-8284353 : Update java/net and sun/net/www tests to eliminate dependency on sun.net.www.MessageHeader In-Reply-To: References: Message-ID: <4iiKEvKVttrdCo-0AUXdisd_hU_rn94NRFFpPL3fEEs=.bbc60aef-05d3-49f3-8149-cc576d3a1109@github.com> On Tue, 5 Apr 2022 10:27:54 GMT, Mahendra Chhipa wrote: > Updated java/net and sun/net/www tests to remove dependency on sun.net.www.MessageHeader. This pull request has now been integrated. Changeset: ec73c61d Author: Mahendra Chhipa Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/ec73c61d8fe5de15a42fc14aaf8ebe3ac9ffcae5 Stats: 104 lines in 12 files changed: 40 ins; 6 del; 58 mod 8284353: Update java/net and sun/net/www tests to eliminate dependency on sun.net.www.MessageHeader Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/8105 From dfuchs at openjdk.java.net Thu Apr 7 10:54:40 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 7 Apr 2022 10:54:40 GMT Subject: RFR: 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. src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSCredElement.java line 74: > 72: name = srcName; > 73: > 74: Cleaner.create().register(this, this::dispose); This will create a memory leak: `this` will never be garbage collected if it's referenced by the cleaner action. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From jnimeh at openjdk.java.net Thu Apr 7 14:45:44 2022 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 7 Apr 2022 14:45:44 GMT Subject: RFR: JDK-8234128 jarsigner will not show not-signed-by-alias warning if an intermediate cert is in this keystore In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers wrote: > https://bugs.openjdk.java.net/browse/JDK-8234128 > > My initial attempt had too many bad side-effects. This latest fix only tries to suppress the warning message. test/jdk/sun/security/tools/jarsigner/warnings/AliasNotInStoreTest2.java line 50: > 48: > 49: createAlias(CA_KEY_ALIAS, "-ext", "bc"); > 50: createAlias(FIRST_KEY_ALIAS); Is this creating a 3-cert chain (signer -> intermediate -> trust anchor) or just a 2-cert chain (signer -> trust anchor)? I ask because the bug description specifies that it requires a missing signer alias but an intermediate CA being present (and I assume the TA as well). This looks like it's creating a 2-cert chain. From looking at the loop in intKeyStoreForOneSigner perhaps it doesn't matter and a 2-cert is just as good as a 3-cert chain. ------------- PR: https://git.openjdk.java.net/jdk/pull/7751 From duke at openjdk.java.net Thu Apr 7 15:09:42 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 7 Apr 2022 15:09:42 GMT Subject: RFR: JDK-8234128 jarsigner will not show not-signed-by-alias warning if an intermediate cert is in this keystore In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers wrote: > https://bugs.openjdk.java.net/browse/JDK-8234128 > > My initial attempt had too many bad side-effects. This latest fix only tries to suppress the warning message. I recall that Max said the intermediate was not necessary. Maybe he can chime in. ------------- PR: https://git.openjdk.java.net/jdk/pull/7751 From jnimeh at openjdk.java.net Thu Apr 7 15:14:37 2022 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Thu, 7 Apr 2022 15:14:37 GMT Subject: RFR: JDK-8234128 jarsigner will not show not-signed-by-alias warning if an intermediate cert is in this keystore In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers wrote: > https://bugs.openjdk.java.net/browse/JDK-8234128 > > My initial attempt had too many bad side-effects. This latest fix only tries to suppress the warning message. Looks good to me. Yeah, the loop seems like it would behave the same way with or without the intermediate CA cert for the purposes of the warning message. I'm good with it. ------------- Marked as reviewed by jnimeh (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7751 From rriggs at openjdk.java.net Thu Apr 7 15:32:39 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 7 Apr 2022 15:32:39 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 10:51:13 GMT, Daniel Fuchs 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. > > src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSCredElement.java line 74: > >> 72: name = srcName; >> 73: >> 74: Cleaner.create().register(this, this::dispose); > > This will create a memory leak: `this` will never be garbage collected if it's referenced by the cleaner action. The cleaner gets triggered when the instance is unreachable, no values from that instance can be modified or referenced. Any information needed for the cleanup must be in a separate object. In this case, that is pCred and cStub. Typically, new nested class is defined that holds the pCred and cStub and has a run() method that calls `cStub.releaseCred(pCred)`. But the package access to non-final `pCred` raises a flag about when its mutated. If its mutated after the cleaner is created, the cleaner will release the wrong cred. If the GSSCredElement is itself just a holder of the credentials, then perhaps the cleaner should be triggered on the instance that is referring to the GSSCredElement being unreachable. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From xuelei at openjdk.java.net Thu Apr 7 15:51:43 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Apr 2022 15:51:43 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 10:51:13 GMT, Daniel Fuchs 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. > > src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSCredElement.java line 74: > >> 72: name = srcName; >> 73: >> 74: Cleaner.create().register(this, this::dispose); > > This will create a memory leak: `this` will never be garbage collected if it's referenced by the cleaner action. Yes. I'm working on an update, and more code changes (including immutable objects) may be placed. Thank you @dfuch and @RogerRiggs for the good catch. I totally forgot about the object reference problems while using Cleaner. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From duke at openjdk.java.net Thu Apr 7 15:57:43 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 7 Apr 2022 15:57:43 GMT Subject: Integrated: JDK-8234128 jarsigner will not show not-signed-by-alias warning if an intermediate cert is in this keystore In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers wrote: > https://bugs.openjdk.java.net/browse/JDK-8234128 > > My initial attempt had too many bad side-effects. This latest fix only tries to suppress the warning message. This pull request has now been integrated. Changeset: d6f01e9d Author: Mark Powers Committer: Jamil Nimeh URL: https://git.openjdk.java.net/jdk/commit/d6f01e9d6f35fb235d9b9fb674867c9760b1c1d1 Stats: 101 lines in 2 files changed: 99 ins; 0 del; 2 mod 8234128: jarsigner will not show not-signed-by-alias warning if an intermediate cert is in this keystore Reviewed-by: jnimeh ------------- PR: https://git.openjdk.java.net/jdk/pull/7751 From xuelei at openjdk.java.net Thu Apr 7 16:33:18 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Apr 2022 16:33:18 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v2] 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: the object reference issue for Cleaner ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8136/files - new: https://git.openjdk.java.net/jdk/pull/8136/files/c87b8f5f..22d1bed5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=00-01 Stats: 50 lines in 4 files changed: 29 ins; 2 del; 19 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 valeriep at openjdk.java.net Thu Apr 7 17:38:40 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 7 Apr 2022 17:38:40 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v2] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 15:48:50 GMT, Xue-Lei Andrew Fan wrote: >> src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSCredElement.java line 74: >> >>> 72: name = srcName; >>> 73: >>> 74: Cleaner.create().register(this, this::dispose); >> >> This will create a memory leak: `this` will never be garbage collected if it's referenced by the cleaner action. > > Yes. I'm working on an update, and more code changes (including immutable objects) may be placed. Thank you @dfuch and @RogerRiggs for the good catch. I totally forgot about the object reference problems while using Cleaner. Hmm, the earlier JCE change would also needs to be updated as it calls a cleanup method on the to-be-cleaned object. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From xuelei at openjdk.java.net Thu Apr 7 17:57:43 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Apr 2022 17:57:43 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v2] In-Reply-To: References: Message-ID: <-gE-r1BzMLQczURwUsjAYPYlFQZpHy31MBD2KwlU19M=.cb4af448-b91c-4b14-ad90-cee618cb2e30@github.com> On Thu, 7 Apr 2022 17:35:47 GMT, Valerie Peng wrote: > Hmm, the earlier JCE change would also needs to be updated as it calls a cleanup method on the to-be-cleaned object. Yes, I will check the cleaner used in the security components and make sure there is object reference problems. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From ecki at zusammenkunft.net Thu Apr 7 18:53:54 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 7 Apr 2022 18:53:54 +0000 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: Message-ID: Hello, I think this proposal be very powerful, it allows completely new models (like custom sandboxed VMs) while still removing many of the complicated classes. I am all for it, but it does limit the actual work saved since the doPriveleged and checkPermission sites are the thing which is the actual Maintenance effort which should be saved, right? I like the interface check permission option, it makes the types explicit (I remember this method from the Jboss logger), but I am afraid proponents of removing SM won?t be too happy about redesigning all check places, so the check method seems to be the least resistance, even though it?s much less clean.. (I would volunteer to help with it, for what it?s worth) Gru? Bernd -- https://bernd.eckenfels.net ________________________________ From: security-dev on behalf of David Lloyd Sent: Tuesday, April 5, 2022 3:52:05 PM To: OpenJDK Security Subject: A possible JEP to replace SecurityManager after JEP 411 Here at Red Hat there have been serious discussions about the impacts of security manager removal on our users, and whether there is an actual value impact, and if so, whether it can be mitigated or reversed somehow. We are interested in exploring whether we can come up with a way in which vendors and projects that wish to continue using SecurityManager (or something like it) would be able to do so, while still removing the majority of the ongoing maintenance burden from the OpenJDK project. Before we make a decision on whether or not we think there is sufficient justification for working up a formal JEP, we have decided that the best first step would be to socialize the idea in a more general form so that we can know whether the upstream OpenJDK team would even be amenable *at all* to the solution (or something like it), particularly in light of the observation that previous threads about retaining SecurityManager in any form have been looked upon in a fairly negative light. The primary idea behind this proposal is that, while all of the points in JEP 411 relating to the lack of what most experts might refer to as "actual security" are certainly true, the SecurityManager mechanism itself does nevertheless have some inherent value. The challenge, then, is to strike a balance between the value provided by retaining some semblance of the mechanism versus the costs inherent in retaining it; we would want as much of the former as possible, for as little of the latter as possible. So, here's the idea. It is assumed (for the sake of common understanding) that as things stand, all of the classes and members marked as "deprecated for removal" as a part of JEP 411 are intended to be completely removed without replacement at the end of the term of deprecation. The proposals here are based on this assumption. The center of this proposal is that, at the end of the term of deprecation, all of the deprecated classes, members, and behavior are still removed (including, and especially, AccessController and Policy and related classes) /except/ as mentioned here: * Rather than completely removing SecurityManager, * The SecurityManager class becomes abstract and non-deprecated, with all of its methods being removed, except as follows * SecurityManager.getSecurityContext() becomes abstract (this is the one that returns Object, *not* the stack walking one) * SecurityManager.checkPermission() (both of them) become abstract * Rather than removing the SecurityManager-related methods from System, * System.getSecurityManager() is retained and de-deprecated * [Optional] System.setSecurityManager() is retained and de-deprecated (we would want to explore whether it is feasible to replace this (and the system property lookup mechanism) using ServiceLoader, if bootstrap allows it) * [Optional] Rather than /immediately/ removing all of AccessController, * Retain its deprecation-for-removal status * Retain only doPrivileged(PrivilegedAction) and doPrivileged(PrivilegedExceptionAction) as simple pass-throughs (no JVM semantics other than being present on the call stack like any method) since they are pervasively used, to allow frameworks time to transition to (for example) a third-party alternative. The burden of permission verification would lie completely with the security manager implementation. The JDK would not have a 'SecurityManager' implementation of any kind, outside of the internal test suite. The other part of this proposal can come in one of two possible flavors. ### Option 1: Authorization interfaces Each point in the JDK where there presently is a permission check is classified into an authorization category of related operations. An interface is introduced for each category which contains the methods encapsulating the relevant check, in a package that is deemed most appropriate for that particular grouping. For example, there might be a 'SocketAuthorization' interface in the 'java.net' package, with methods like 'checkConnect(SocketAddress from, SocketAddress to)' and 'checkAccept(SocketAddress addr)'. At the point where a permission check previously would take place, a check like this is performed instead: if (System.getSecurityManager() instanceof SocketAuthorization sa) { sa.checkAccept(addr); } Any public or protected method with such a check should include @throws Javadoc explaining that a SecurityException may be thrown. The Permission subclasses previously used specifically by these operation sites *may* in this case be deprecated for removal immediately or at some point in the future, if desired. It is the sole responsibility of the SecurityManager implementer to implement the various necessary interfaces, and any third-party authorization interfaces that would also be relevant. ### Option 2: Retain permission system Under this option, the existing authorization checks are mostly retained, however, since the SecurityManager class only has a general 'checkPermission()' method, the logic previously found in the 'SecurityManager' class which expands specific check calls into general 'checkPermission()' calls (for example, calls to 'checkConnect' for sockets) would necessarily become the responsibility of the site of the permission check. Some work would be undertaken to refactor this code accordingly. With this solution, the corresponding Permission subclasses would be retained indefinitely. In either case it is the responsibility of the implementer of SecurityManager to utilize these checks appropriately for authorization decisions, based on whatever factors are deemed appropriate, which may include contextual information such as a currently-authenticated identity or the call stack, or (for example) a context object utilizing the ScopeLocal mechanism. ### Other changes It would be worth exploring whether the SecurityManager installation could be refitted to use the ServiceLoader mechanism (for example at first call to getSecurityManager()) based on the class loader of the application class or module path. This would allow the 'System.setSecurityManager' method, and support for the corresponding system property, to be removed at the end of the term of deprecation. Testing Neither solution would ease the burden of testing from the JDK quite as much as complete removal, of course. The necessary testing for the individual checks should be limited to ensuring that the permission check calls are happening with correct arguments and that any thrown SecurityException is propagated. The policy for testing SecurityManager installation would depend on whether, and to what extent, the more recent changes restricting the installation of the security manager are reversed. Other testing issues may arise as well. -- - DML ? he/him -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Apr 7 19:19:28 2022 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 7 Apr 2022 15:19:28 -0400 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: Message-ID: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> Hi David, Thanks for the feedback and spending some time on this proposal. Some specific comments below. On 4/5/22 9:52 AM, David Lloyd wrote: > Here at Red Hat there have been serious discussions about the impacts > of security manager removal on our users, and whether there is an > actual value impact, and if so, whether it can be mitigated or > reversed somehow. We are interested in exploring whether we can come > up with a way in which vendors and projects that wish to continue > using SecurityManager (or something like it) would be able to do so, > while still removing the majority of the ongoing maintenance burden > from the OpenJDK project. > > Before we make a decision on whether or not we think there is > sufficient justification for working up a formal JEP, we have decided > that the best first step would be to socialize the idea in a more > general form so that we can know whether the upstream OpenJDK team > would even be amenable *at all* to the solution (or something like > it), particularly in light of the observation that previous threads > about retaining SecurityManager in any form have been looked upon in a > fairly negative light. > > The primary idea behind this proposal is that, while all of the points > in JEP 411 relating to the lack of what most experts might refer to as > "actual security" are certainly true, the SecurityManager mechanism > itself does nevertheless have some inherent value. The challenge, > then, is to strike a balance between the value provided by retaining > some semblance of the mechanism versus the costs inherent in retaining > it; we would want as much of the former as possible, for as little of > the latter as possible. With this proposal, as I understand it, the JDK would still be responsible for maintaining and preserving essentially all of the existing calls to the Security Manager (SM). All new code and APIs would still need to be evaluated and determined if permission checks were needed as well as making appropriate specification changes to note the behavior when an SM is enabled (throwing a SecurityException, etc). Any missing checks would need to be treated as security issues. And we would still need to test the code and APIs to ensure that it worked properly and complied with the API specification. This would likely mean implementing and maintaining an internal SM implementation in OpenJDK. The proposal also includes retaining calls to doPrivileged (but later potentially replacing them with some other mechanism TBD). The JDK source code includes over 1000 calls to doPrivileged. Each of these need to be carefully reviewed to ensure that they do not contain security issues and any new code needs to be evaluated to see if new calls to doPrivileged are necessary. Retaining doPrivileged (or something similar) means that there can be domains of code with different permissions running within the VM, which retains much of the complexity of the current SM model. In this proposal, how privileges are established or propagated is implementation-specific. But how could applications or libraries depend on the APIs and still have some confidence that the code is behaving consistently and securely? Today, the cost of buying into the SM model is high for libraries and applications. Not many third party libraries support the SM and have modified their code to perform permission checks and call doPrivileged in the right places. If there were pluggable SMs each behaving differently, there would likely be less incentive. Although it sounds beneficial to be able to delegate the SM implementation to a 3rd-party, in reality, I think very few people would take the time to implement it securely, and instead would mostly leverage its power to do things that aren't at all security related. Sure, removing the default SM and Policy implementation reduces the complexity a little, but there would still be a fairly significant maintenance overhead and an additional drawback that it would make it more difficult for applications and libraries to depend on any type of consistent behavior. --Sean > So, here's the idea. It is assumed (for the sake of common > understanding) that as things stand, all of the classes and members > marked as "deprecated for removal" as a part of JEP 411 are intended > to be completely removed without replacement at the end of the term of > deprecation. The proposals here are based on this assumption. > > The center of this proposal is that, at the end of the term of > deprecation, all of the deprecated classes, members, and behavior are > still removed (including, and especially, AccessController and Policy > and related classes) /except/ as mentioned here: > > * Rather than completely removing SecurityManager, > * The SecurityManager class becomes abstract and non-deprecated, > with all of its methods being removed, except as follows > * SecurityManager.getSecurityContext() becomes abstract (this is > the one that returns Object, *not* the stack walking one) > * SecurityManager.checkPermission() (both of them) become abstract > * Rather than removing the SecurityManager-related methods from System, > * System.getSecurityManager() is retained and de-deprecated > * [Optional] System.setSecurityManager() is retained and > de-deprecated (we would want to explore whether it is feasible to > replace this (and the system property lookup mechanism) using > ServiceLoader, if bootstrap allows it) > * [Optional] Rather than /immediately/ removing all of AccessController, > * Retain its deprecation-for-removal status > * Retain only doPrivileged(PrivilegedAction) and > doPrivileged(PrivilegedExceptionAction) as simple pass-throughs (no > JVM semantics other than being present on the call stack like any > method) since they are pervasively used, to allow frameworks time to > transition to (for example) a third-party alternative. > > The burden of permission verification would lie completely with the > security manager implementation. The JDK would not have a > 'SecurityManager' implementation of any kind, outside of the internal > test suite. > > The other part of this proposal can come in one of two possible flavors. > > ### Option 1: Authorization interfaces > > Each point in the JDK where there presently is a permission check is > classified into an authorization category of related operations. An > interface is introduced for each category which contains the methods > encapsulating the relevant check, in a package that is deemed most > appropriate for that particular grouping. For example, there might be > a 'SocketAuthorization' interface in the 'java.net' package, with > methods like 'checkConnect(SocketAddress from, SocketAddress to)' and > 'checkAccept(SocketAddress addr)'. > > At the point where a permission check previously would take place, a > check like this is performed instead: > > if (System.getSecurityManager() instanceof SocketAuthorization sa) { > sa.checkAccept(addr); > } > > Any public or protected method with such a check should include > @throws Javadoc explaining that a SecurityException may be thrown. > > The Permission subclasses previously used specifically by these > operation sites *may* in this case be deprecated for removal > immediately or at some point in the future, if desired. > > It is the sole responsibility of the SecurityManager implementer to > implement the various necessary interfaces, and any third-party > authorization interfaces that would also be relevant. > > ### Option 2: Retain permission system > > Under this option, the existing authorization checks are mostly > retained, however, since the SecurityManager class only has a general > 'checkPermission()' method, the logic previously found in the > 'SecurityManager' class which expands specific check calls into > general 'checkPermission()' calls (for example, calls to > 'checkConnect' for sockets) would necessarily become the > responsibility of the site of the permission check. Some work would > be undertaken > to refactor this code accordingly. > > With this solution, the corresponding Permission subclasses would be > retained indefinitely. > > In either case it is the responsibility of the implementer of > SecurityManager to utilize these checks appropriately for > authorization decisions, based on whatever factors are deemed > appropriate, which may include contextual information such as a > currently-authenticated identity or the call stack, or (for example) a > context object utilizing the ScopeLocal mechanism. > > ### Other changes > > It would be worth exploring whether the SecurityManager installation > could be refitted to use the ServiceLoader mechanism (for example at > first call to getSecurityManager()) based on the class loader of the > application class or module path. This would allow the > 'System.setSecurityManager' method, and support for the corresponding > system property, to be removed at the end of the term of deprecation. > > Testing > > Neither solution would ease the burden of testing from the JDK quite > as much as complete removal, of course. The necessary testing for the > individual checks should be limited to ensuring that the permission > check calls are happening with correct arguments and that any thrown > SecurityException is propagated. The policy for testing > SecurityManager installation would depend on whether, and to what > extent, the more recent changes restricting the installation of the > security manager are reversed. Other testing issues may arise as > well. > From xuelei at openjdk.java.net Thu Apr 7 19:21:31 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Apr 2022 19:21:31 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v3] 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: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8136/files - new: https://git.openjdk.java.net/jdk/pull/8136/files/22d1bed5..23072ef7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 xuelei at openjdk.java.net Thu Apr 7 19:57:39 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Apr 2022 19:57:39 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method 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. Need an update, close the review for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From xuelei at openjdk.java.net Thu Apr 7 19:57:39 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Apr 2022 19:57:39 GMT Subject: Withdrawn: 8212136: Remove BaseSSLSocketImpl finalizer method In-Reply-To: References: Message-ID: <1uKK7ZcbLXkyDEJzjO_DvmMIon6f-RH5_HQ-Muo0ps8=.f4750834-543a-47a4-b6a5-e5d176cd1462@github.com> 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 been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From weijun at openjdk.java.net Thu Apr 7 20:03:31 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 7 Apr 2022 20:03:31 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v3] In-Reply-To: <-gE-r1BzMLQczURwUsjAYPYlFQZpHy31MBD2KwlU19M=.cb4af448-b91c-4b14-ad90-cee618cb2e30@github.com> References: <-gE-r1BzMLQczURwUsjAYPYlFQZpHy31MBD2KwlU19M=.cb4af448-b91c-4b14-ad90-cee618cb2e30@github.com> Message-ID: On Thu, 7 Apr 2022 17:54:35 GMT, Xue-Lei Andrew Fan wrote: >> Hmm, the earlier JCE change would also needs to be updated as it calls a cleanup method on the to-be-cleaned object. > >> Hmm, the earlier JCE change would also needs to be updated as it calls a cleanup method on the to-be-cleaned object. > > Yes, I will check the cleaner used in the security components and make sure there is object reference problems. I'm not sure if it's possible to write a test on the cleanup, but at least we can temporarily add a `println` line there and see if it ever gets called. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From xuelei at openjdk.java.net Thu Apr 7 20:17:28 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Apr 2022 20:17:28 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2] In-Reply-To: References: Message-ID: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> > 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 two additional commits since the last revision: - typo blank linke correction - revise the update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8065/files - new: https://git.openjdk.java.net/jdk/pull/8065/files/38700012..ccfc42da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8065&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8065&range=00-01 Stats: 30 lines in 1 file changed: 0 ins; 30 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 Thu Apr 7 20:17:29 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Apr 2022 20:17:29 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method 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. The socket close() call in the finalize() method may be blocked for the SSL implementation, which is not good for garbage collection. It should be safe by just remove the finalize() method. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From rriggs at openjdk.java.net Thu Apr 7 20:25:42 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 7 Apr 2022 20:25:42 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v3] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 19:21: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: > > Update copyright year LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8136 From xuelei at openjdk.java.net Thu Apr 7 21:21:40 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Apr 2022 21:21:40 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v3] In-Reply-To: References: <-gE-r1BzMLQczURwUsjAYPYlFQZpHy31MBD2KwlU19M=.cb4af448-b91c-4b14-ad90-cee618cb2e30@github.com> Message-ID: On Thu, 7 Apr 2022 20:00:00 GMT, Weijun Wang wrote: > I'm not sure if it's possible to write a test on the cleanup, but at least we can temporarily add a `println` line there and see if it ever gets called. I did not find a way to test cleanup yet. Yes, a temporary 'println" is what I can use for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From weijun at openjdk.java.net Thu Apr 7 21:45:51 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 7 Apr 2022 21:45:51 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v3] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 19:21: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: > > Update copyright year I see a problem. In `NativeGSSContext`, you only assign `cleanable` for one special ctor. In fact, the other 2 ctors (one for initiator and one for acceptor) are more useful. `pContext` is initialized to 0 in these 2 ctors and it's only assigned inside the native code after the context is established. There is no chance to dispose them anymore. I'm not sure what the best way to do this, but maybe you can put `stub` and `pContext` is a separate object and always try to clean it even if `pContext` is not assigned at the beginning. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From weijun at openjdk.java.net Thu Apr 7 22:03:32 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 7 Apr 2022 22:03:32 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v3] In-Reply-To: References: Message-ID: <2JsqKjAY0NmKM-EDikGDx-6mxrY7zUCdamNZyo4nuLw=.d91ff41d-50af-4b34-a0ef-7b2e65bc7d77@github.com> On Thu, 7 Apr 2022 19:21: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: > > Update copyright year At least for native JGSS, all those native functions that release objects can print out debug messages if `-Dsun.security.nativegss.debug=true`. You can see whether they are called without adding extra `println` calls. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From wetmore at openjdk.java.net Thu Apr 7 22:52:44 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 7 Apr 2022 22:52:44 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 20:11:25 GMT, Xue-Lei Andrew Fan wrote: > The socket close() call in the finalize() method may be blocked for the SSL implementation, which is not good for garbage collection. It should be safe by just removing the finalize() method. Can you provide more detail? I expected something more like your first attempt (`java.lang.ref.Cleaner`) that would properly close/send the close_notify message. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From xuelei at openjdk.java.net Thu Apr 7 23:12:40 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 7 Apr 2022 23:12:40 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 22:49:24 GMT, Bradford Wetmore wrote: > > The socket close() call in the finalize() method may be blocked for the SSL implementation, which is not good for garbage collection. It should be safe by just removing the finalize() method. `> > Can you provide more detail? I expected something more like your first attempt (`java.lang.ref.Cleaner`) that would properly close/send the close_notify message. Thanks! The 1st use of Cleaner refer to 'this' object, as result in that 'this' object cannot be phantom reachable and thus the cleaner cannot be triggered. As the close() is a method of 'this' object, the calling to close() in a cleaner will hold a reference to 'this' object, and make the cleaner failed (and memory leak). ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From peter.firmstone at zeus.net.au Thu Apr 7 23:38:33 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 8 Apr 2022 09:38:33 +1000 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> Message-ID: Hi Sean, In order to keep our code up to date with Java, we need to replace access control functionality.?? Current advise is that we will need to instrument the Java API, once finalizers have been removed. The sticking point is about the retention of permission checks, which haven't been deprecated by JEP411, OpenJDK does not wish to maintain permission checks. We currently use authentication and access control to prevent parsing untrusted data, or loading untrusted code. This task might be easier if each of the following only have one location (or well documented locations) to instrument in the Java language public API: 1. Network access 2. File access 3. Property access 4. ClassLoader access / creation. 5. Keystores and credentials. We also need ways to prevent the jvm from being instrumented, by an outside attacker. Instead of worrying about permission checks and calls to SecurityManager, OpenJDK devs just need to ensure they are using these standard control points / hooks. Regards, Peter. On 8/04/2022 5:19 am, Sean Mullan wrote: > Hi David, > > Thanks for the feedback and spending some time on this proposal. Some > specific comments below. > > On 4/5/22 9:52 AM, David Lloyd wrote: >> Here at Red Hat there have been serious discussions about the impacts >> of security manager removal on our users, and whether there is an >> actual value impact, and if so, whether it can be mitigated or >> reversed somehow. We are interested in exploring whether we can come >> up with a way in which vendors and projects that wish to continue >> using SecurityManager (or something like it) would be able to do so, >> while still removing the majority of the ongoing maintenance burden >> from the OpenJDK project. >> >> Before we make a decision on whether or not we think there is >> sufficient justification for working up a formal JEP, we have decided >> that the best first step would be to socialize the idea in a more >> general form so that we can know whether the upstream OpenJDK team >> would even be amenable *at all* to the solution (or something like >> it), particularly in light of the observation that previous threads >> about retaining SecurityManager in any form have been looked upon in a >> fairly negative light. >> >> The primary idea behind this proposal is that, while all of the points >> in JEP 411 relating to the lack of what most experts might refer to as >> "actual security" are certainly true, the SecurityManager mechanism >> itself does nevertheless have some inherent value. The challenge, >> then, is to strike a balance between the value provided by retaining >> some semblance of the mechanism versus the costs inherent in retaining >> it; we would want as much of the former as possible, for as little of >> the latter as possible. > > With this proposal, as I understand it, the JDK would still be > responsible for maintaining and preserving essentially all of the > existing calls to the Security Manager (SM). All new code and APIs > would still need to be evaluated and determined if permission checks > were needed as well as making appropriate specification changes to > note the behavior when an SM is enabled (throwing a SecurityException, > etc). Any missing checks would need to be treated as security issues. > And we would still need to test the code and APIs to ensure that it > worked properly and complied with the API specification. This would > likely mean implementing and maintaining an internal SM implementation > in OpenJDK. > > The proposal also includes retaining calls to doPrivileged (but later > potentially replacing them with some other mechanism TBD). The JDK > source code includes over 1000 calls to doPrivileged. Each of these > need to be carefully reviewed to ensure that they do not contain > security issues and any new code needs to be evaluated to see if new > calls to doPrivileged are necessary. > > Retaining doPrivileged (or something similar) means that there can be > domains of code with different permissions running within the VM, > which retains much of the complexity of the current SM model. > > In this proposal, how privileges are established or propagated is > implementation-specific. But how could applications or libraries > depend on the APIs and still have some confidence that the code is > behaving consistently and securely? > > Today, the cost of buying into the SM model is high for libraries and > applications. Not many third party libraries support the SM and have > modified their code to perform permission checks and call doPrivileged > in the right places. If there were pluggable SMs each behaving > differently, there would likely be less incentive. > > Although it sounds beneficial to be able to delegate the SM > implementation to a 3rd-party, in reality, I think very few people would > take the time to implement it securely, and instead would mostly > leverage its power to do things that aren't at all security related. > Sure, removing the default SM and Policy implementation reduces the > complexity a little, but there would still be a fairly significant > maintenance overhead and an additional drawback that it would make it > more difficult for applications and libraries to depend on any type of > consistent behavior. > > --Sean > > >> So, here's the idea. It is assumed (for the sake of common >> understanding) that as things stand, all of the classes and members >> marked as "deprecated for removal" as a part of JEP 411 are intended >> to be completely removed without replacement at the end of the term of >> deprecation.? The proposals here are based on this assumption. >> >> The center of this proposal is that, at the end of the term of >> deprecation, all of the deprecated classes, members, and behavior are >> still removed (including, and especially, AccessController and Policy >> and related classes) /except/ as mentioned here: >> >> ? * Rather than completely removing SecurityManager, >> ????? * The SecurityManager class becomes abstract and non-deprecated, >> with all of its methods being removed, except as follows >> ????? * SecurityManager.getSecurityContext() becomes abstract (this is >> the one that returns Object, *not* the stack walking one) >> ????? * SecurityManager.checkPermission() (both of them) become abstract >> ? * Rather than removing the SecurityManager-related methods from >> System, >> ????? * System.getSecurityManager() is retained and de-deprecated >> ????? * [Optional] System.setSecurityManager() is retained and >> de-deprecated (we would want to explore whether it is feasible to >> replace this (and the system property lookup mechanism) using >> ServiceLoader, if bootstrap allows it) >> ? * [Optional] Rather than /immediately/ removing all of >> AccessController, >> ????? * Retain its deprecation-for-removal status >> ????? * Retain only doPrivileged(PrivilegedAction) and >> doPrivileged(PrivilegedExceptionAction) as simple pass-throughs (no >> JVM semantics other than being present on the call stack like any >> method) since they are pervasively used, to allow frameworks time to >> transition to (for example) a third-party alternative. >> >> The burden of permission verification would lie completely with the >> security manager implementation.? The JDK would not have a >> 'SecurityManager' implementation of any kind, outside of the internal >> test suite. >> >> The other part of this proposal can come in one of two possible flavors. >> >> ### Option 1: Authorization interfaces >> >> Each point in the JDK where there presently is a permission check is >> classified into an authorization category of related operations. An >> interface is introduced for each category which contains the methods >> encapsulating the relevant check, in a package that is deemed most >> appropriate for that particular grouping.? For example, there might be >> a 'SocketAuthorization' interface in the 'java.net' package, with >> methods like 'checkConnect(SocketAddress from, SocketAddress to)' and >> 'checkAccept(SocketAddress addr)'. >> >> At the point where a permission check previously would take place, a >> check like this is performed instead: >> >> ???? if (System.getSecurityManager() instanceof SocketAuthorization >> sa) { >> ???????? sa.checkAccept(addr); >> ???? } >> >> Any public or protected method with such a check should include >> @throws Javadoc explaining that a SecurityException may be thrown. >> >> The Permission subclasses previously used specifically by these >> operation sites *may* in this case be deprecated for removal >> immediately or at some point in the future, if desired. >> >> It is the sole responsibility of the SecurityManager implementer to >> implement the various necessary interfaces, and any third-party >> authorization interfaces that would also be relevant. >> >> ### Option 2: Retain permission system >> >> Under this option, the existing authorization checks are mostly >> retained, however, since the SecurityManager class only has a general >> 'checkPermission()' method, the logic previously found in the >> 'SecurityManager' class which expands specific check calls into >> general 'checkPermission()' calls (for example, calls to >> 'checkConnect' for sockets) would necessarily become the >> responsibility of the site of the permission check.? Some work would >> be undertaken >> to refactor this code accordingly. >> >> With this solution, the corresponding Permission subclasses would be >> retained indefinitely. >> >> In either case it is the responsibility of the implementer of >> SecurityManager to utilize these checks appropriately for >> authorization decisions, based on whatever factors are deemed >> appropriate, which may include contextual information such as a >> currently-authenticated identity or the call stack, or (for example) a >> context object utilizing the ScopeLocal mechanism. >> >> ### Other changes >> >> It would be worth exploring whether the SecurityManager installation >> could be refitted to use the ServiceLoader mechanism (for example at >> first call to getSecurityManager()) based on the class loader of the >> application class or module path.? This would allow the >> 'System.setSecurityManager' method, and support for the corresponding >> system property, to be removed at the end of the term of deprecation. >> >> Testing >> >> Neither solution would ease the burden of testing from the JDK quite >> as much as complete removal, of course. The necessary testing for the >> individual checks should be limited to ensuring that the permission >> check calls are happening with correct arguments and that any thrown >> SecurityException is propagated.? The policy for testing >> SecurityManager installation would depend on whether, and to what >> extent, the more recent changes restricting the installation of the >> security manager are reversed.? Other testing issues may arise as >> well. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wetmore at openjdk.java.net Fri Apr 8 01:49:46 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 8 Apr 2022 01:49:46 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2] In-Reply-To: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> References: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> Message-ID: On Thu, 7 Apr 2022 20:17:28 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 two additional commits since the last revision: > > - typo blank linke correction > - revise the update Thanks for the explanation: this is my first exposure to the `java.lang.ref.Cleaner` API, so am getting up to speed. Sorry if these are dumb comments/questions. I see now what was being talked about in your other PR: https://github.com/openjdk/jdk/pull/8136 and to not use a reference to `this` which would keep it from being GC'd. I also see how you're keeping a cleaner object that has outside ("static") references to the actual things that need to be released, but don't we need to do the similar cleaning for the underlying Socket somehow? What do Sockets do to make sure the underlying file descriptors/native memory are properly released? That said, we still need to send the close_notify at the TLS layer, right? Simply removing the finalize() method is just going to silently shutdown the connection, and then the Socket is going to do whatever it does for finalization/Cleaning. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From xuelei at openjdk.java.net Fri Apr 8 06:56:40 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 8 Apr 2022 06:56:40 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2] In-Reply-To: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> References: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> Message-ID: <5_6f8JkmZHTg5ITqUdEhm5l3mNNTmxPKtht6ct3PMXU=.d58d95a1-9f88-45a0-9294-f29d75263934@github.com> On Thu, 7 Apr 2022 20:17:28 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 two additional commits since the last revision: > > - typo blank linke correction > - revise the update > Thanks for the explanation: this is my first exposure to the `java.lang.ref.Cleaner` API, so am getting up to speed. Sorry if these are dumb comments/questions. > > I see now what was being talked about in your other PR: #8136 and to not use a reference to `this` which would keep it from being GC'd. I also see how you're keeping a cleaner object that has outside ("static") references to the actual things that need to be released, but don't we need to do the similar cleaning for the underlying Socket somehow? What do Sockets do to make sure the underlying file descriptors/native memory are properly released? > The Socket implementation will take care of the file description/native memory release, I think. > That said, we still need to send the close_notify at the TLS layer, right? Simply removing the finalize() method is just going to silently shutdown the connection, and then the Socket is going to do whatever it does for finalization/Cleaning. It is expected to send the close_notify at the TLS layer. But the current code using finalizer, which is not reliable. The underlying socket may have been closed when the SSLSocket finalizing action is triggered. Generally, application should call close() method explicitly, otherwise the finalizer is not expect to work reliable. I was wondering it may be safe to remove the finalizer. I agree that adding a best effort cleanup may be better. I was wondering to check if it is possible to clean the socket in the socket creation factories so that the object reference issues could be resolved. But as socket is a kind of resource, application layer may make the clean up as well. Socket s = ... cleaner.register(this, s::close); I'm still looking for a solution to clean up resource by using a method of 'this'. Please advice if anyone has experiences. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From adinn at redhat.com Fri Apr 8 09:15:33 2022 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 8 Apr 2022 10:15:33 +0100 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> Message-ID: <095dd4fa-0dbd-1ea7-4395-793856630ab6@redhat.com> I'm 100% in agreement with Sean. This proposal leaves the OpenJDK team with just as much -- or possibly more -- code to maintain, test and design around while making the behaviour under the retained API less determinate, less reliable as a security enforcement mechanism and, in consequence, even less likely to be used than it is already. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill On 07/04/2022 20:19, Sean Mullan wrote: > Hi David, > > Thanks for the feedback and spending some time on this proposal. Some > specific comments below. > > On 4/5/22 9:52 AM, David Lloyd wrote: >> Here at Red Hat there have been serious discussions about the impacts >> of security manager removal on our users, and whether there is an >> actual value impact, and if so, whether it can be mitigated or >> reversed somehow. We are interested in exploring whether we can come >> up with a way in which vendors and projects that wish to continue >> using SecurityManager (or something like it) would be able to do so, >> while still removing the majority of the ongoing maintenance burden >> from the OpenJDK project. >> >> Before we make a decision on whether or not we think there is >> sufficient justification for working up a formal JEP, we have decided >> that the best first step would be to socialize the idea in a more >> general form so that we can know whether the upstream OpenJDK team >> would even be amenable *at all* to the solution (or something like >> it), particularly in light of the observation that previous threads >> about retaining SecurityManager in any form have been looked upon in a >> fairly negative light. >> >> The primary idea behind this proposal is that, while all of the points >> in JEP 411 relating to the lack of what most experts might refer to as >> "actual security" are certainly true, the SecurityManager mechanism >> itself does nevertheless have some inherent value. The challenge, >> then, is to strike a balance between the value provided by retaining >> some semblance of the mechanism versus the costs inherent in retaining >> it; we would want as much of the former as possible, for as little of >> the latter as possible. > > With this proposal, as I understand it, the JDK would still be > responsible for maintaining and preserving essentially all of the > existing calls to the Security Manager (SM). All new code and APIs would > still need to be evaluated and determined if permission checks were > needed as well as making appropriate specification changes to note the > behavior when an SM is enabled (throwing a SecurityException, etc). Any > missing checks would need to be treated as security issues. And we would > still need to test the code and APIs to ensure that it worked properly > and complied with the API specification. This would likely mean > implementing and maintaining an internal SM implementation in OpenJDK. > > The proposal also includes retaining calls to doPrivileged (but later > potentially replacing them with some other mechanism TBD). The JDK > source code includes over 1000 calls to doPrivileged. Each of these need > to be carefully reviewed to ensure that they do not contain security > issues and any new code needs to be evaluated to see if new calls to > doPrivileged are necessary. > > Retaining doPrivileged (or something similar) means that there can be > domains of code with different permissions running within the VM, which > retains much of the complexity of the current SM model. > > In this proposal, how privileges are established or propagated is > implementation-specific. But how could applications or libraries depend > on the APIs and still have some confidence that the code is behaving > consistently and securely? > > Today, the cost of buying into the SM model is high for libraries and > applications. Not many third party libraries support the SM and have > modified their code to perform permission checks and call doPrivileged > in the right places. If there were pluggable SMs each behaving > differently, there would likely be less incentive. > > Although it sounds beneficial to be able to delegate the SM > implementation to a 3rd-party, in reality, I think very few people would > take the time to implement it securely, and instead would mostly > leverage its power to do things that aren't at all security related. > Sure, removing the default SM and Policy implementation reduces the > complexity a little, but there would still be a fairly significant > maintenance overhead and an additional drawback that it would make it > more difficult for applications and libraries to depend on any type of > consistent behavior. > > --Sean > > >> So, here's the idea. It is assumed (for the sake of common >> understanding) that as things stand, all of the classes and members >> marked as "deprecated for removal" as a part of JEP 411 are intended >> to be completely removed without replacement at the end of the term of >> deprecation.? The proposals here are based on this assumption. >> >> The center of this proposal is that, at the end of the term of >> deprecation, all of the deprecated classes, members, and behavior are >> still removed (including, and especially, AccessController and Policy >> and related classes) /except/ as mentioned here: >> >> ? * Rather than completely removing SecurityManager, >> ????? * The SecurityManager class becomes abstract and non-deprecated, >> with all of its methods being removed, except as follows >> ????? * SecurityManager.getSecurityContext() becomes abstract (this is >> the one that returns Object, *not* the stack walking one) >> ????? * SecurityManager.checkPermission() (both of them) become abstract >> ? * Rather than removing the SecurityManager-related methods from System, >> ????? * System.getSecurityManager() is retained and de-deprecated >> ????? * [Optional] System.setSecurityManager() is retained and >> de-deprecated (we would want to explore whether it is feasible to >> replace this (and the system property lookup mechanism) using >> ServiceLoader, if bootstrap allows it) >> ? * [Optional] Rather than /immediately/ removing all of >> AccessController, >> ????? * Retain its deprecation-for-removal status >> ????? * Retain only doPrivileged(PrivilegedAction) and >> doPrivileged(PrivilegedExceptionAction) as simple pass-throughs (no >> JVM semantics other than being present on the call stack like any >> method) since they are pervasively used, to allow frameworks time to >> transition to (for example) a third-party alternative. >> >> The burden of permission verification would lie completely with the >> security manager implementation.? The JDK would not have a >> 'SecurityManager' implementation of any kind, outside of the internal >> test suite. >> >> The other part of this proposal can come in one of two possible flavors. >> >> ### Option 1: Authorization interfaces >> >> Each point in the JDK where there presently is a permission check is >> classified into an authorization category of related operations. An >> interface is introduced for each category which contains the methods >> encapsulating the relevant check, in a package that is deemed most >> appropriate for that particular grouping.? For example, there might be >> a 'SocketAuthorization' interface in the 'java.net' package, with >> methods like 'checkConnect(SocketAddress from, SocketAddress to)' and >> 'checkAccept(SocketAddress addr)'. >> >> At the point where a permission check previously would take place, a >> check like this is performed instead: >> >> ???? if (System.getSecurityManager() instanceof SocketAuthorization sa) { >> ???????? sa.checkAccept(addr); >> ???? } >> >> Any public or protected method with such a check should include >> @throws Javadoc explaining that a SecurityException may be thrown. >> >> The Permission subclasses previously used specifically by these >> operation sites *may* in this case be deprecated for removal >> immediately or at some point in the future, if desired. >> >> It is the sole responsibility of the SecurityManager implementer to >> implement the various necessary interfaces, and any third-party >> authorization interfaces that would also be relevant. >> >> ### Option 2: Retain permission system >> >> Under this option, the existing authorization checks are mostly >> retained, however, since the SecurityManager class only has a general >> 'checkPermission()' method, the logic previously found in the >> 'SecurityManager' class which expands specific check calls into >> general 'checkPermission()' calls (for example, calls to >> 'checkConnect' for sockets) would necessarily become the >> responsibility of the site of the permission check.? Some work would >> be undertaken >> to refactor this code accordingly. >> >> With this solution, the corresponding Permission subclasses would be >> retained indefinitely. >> >> In either case it is the responsibility of the implementer of >> SecurityManager to utilize these checks appropriately for >> authorization decisions, based on whatever factors are deemed >> appropriate, which may include contextual information such as a >> currently-authenticated identity or the call stack, or (for example) a >> context object utilizing the ScopeLocal mechanism. >> >> ### Other changes >> >> It would be worth exploring whether the SecurityManager installation >> could be refitted to use the ServiceLoader mechanism (for example at >> first call to getSecurityManager()) based on the class loader of the >> application class or module path.? This would allow the >> 'System.setSecurityManager' method, and support for the corresponding >> system property, to be removed at the end of the term of deprecation. >> >> Testing >> >> Neither solution would ease the burden of testing from the JDK quite >> as much as complete removal, of course. The necessary testing for the >> individual checks should be limited to ensuring that the permission >> check calls are happening with correct arguments and that any thrown >> SecurityException is propagated.? The policy for testing >> SecurityManager installation would depend on whether, and to what >> extent, the more recent changes restricting the installation of the >> security manager are reversed.? Other testing issues may arise as >> well. >> > From peter.firmstone at zeus.net.au Fri Apr 8 10:19:10 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 8 Apr 2022 20:19:10 +1000 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: <095dd4fa-0dbd-1ea7-4395-793856630ab6@redhat.com> References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <095dd4fa-0dbd-1ea7-4395-793856630ab6@redhat.com> Message-ID: <2e0ad150-b025-dcb4-06a1-585efe360af6@zeus.net.au> Thanks for trying David. :) Regards, Peter. On 8/04/2022 7:15 pm, Andrew Dinn wrote: > I'm 100% in agreement with Sean. This proposal leaves the OpenJDK team > with just as much -- or possibly more -- code to maintain, test and > design around while making the behaviour under the retained API less > determinate, less reliable as a security enforcement mechanism and, in > consequence, even less likely to be used than it is already. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > > On 07/04/2022 20:19, Sean Mullan wrote: >> Hi David, >> >> Thanks for the feedback and spending some time on this proposal. Some >> specific comments below. >> >> On 4/5/22 9:52 AM, David Lloyd wrote: >>> Here at Red Hat there have been serious discussions about the impacts >>> of security manager removal on our users, and whether there is an >>> actual value impact, and if so, whether it can be mitigated or >>> reversed somehow. We are interested in exploring whether we can come >>> up with a way in which vendors and projects that wish to continue >>> using SecurityManager (or something like it) would be able to do so, >>> while still removing the majority of the ongoing maintenance burden >>> from the OpenJDK project. >>> >>> Before we make a decision on whether or not we think there is >>> sufficient justification for working up a formal JEP, we have decided >>> that the best first step would be to socialize the idea in a more >>> general form so that we can know whether the upstream OpenJDK team >>> would even be amenable *at all* to the solution (or something like >>> it), particularly in light of the observation that previous threads >>> about retaining SecurityManager in any form have been looked upon in a >>> fairly negative light. >>> >>> The primary idea behind this proposal is that, while all of the points >>> in JEP 411 relating to the lack of what most experts might refer to as >>> "actual security" are certainly true, the SecurityManager mechanism >>> itself does nevertheless have some inherent value. The challenge, >>> then, is to strike a balance between the value provided by retaining >>> some semblance of the mechanism versus the costs inherent in retaining >>> it; we would want as much of the former as possible, for as little of >>> the latter as possible. >> >> With this proposal, as I understand it, the JDK would still be >> responsible for maintaining and preserving essentially all of the >> existing calls to the Security Manager (SM). All new code and APIs >> would still need to be evaluated and determined if permission checks >> were needed as well as making appropriate specification changes to >> note the behavior when an SM is enabled (throwing a >> SecurityException, etc). Any missing checks would need to be treated >> as security issues. And we would still need to test the code and APIs >> to ensure that it worked properly and complied with the API >> specification. This would likely mean implementing and maintaining an >> internal SM implementation in OpenJDK. >> >> The proposal also includes retaining calls to doPrivileged (but later >> potentially replacing them with some other mechanism TBD). The JDK >> source code includes over 1000 calls to doPrivileged. Each of these >> need to be carefully reviewed to ensure that they do not contain >> security issues and any new code needs to be evaluated to see if new >> calls to doPrivileged are necessary. >> >> Retaining doPrivileged (or something similar) means that there can be >> domains of code with different permissions running within the VM, >> which retains much of the complexity of the current SM model. >> >> In this proposal, how privileges are established or propagated is >> implementation-specific. But how could applications or libraries >> depend on the APIs and still have some confidence that the code is >> behaving consistently and securely? >> >> Today, the cost of buying into the SM model is high for libraries and >> applications. Not many third party libraries support the SM and have >> modified their code to perform permission checks and call >> doPrivileged in the right places. If there were pluggable SMs each >> behaving differently, there would likely be less incentive. >> >> Although it sounds beneficial to be able to delegate the SM >> implementation to a 3rd-party, in reality, I think very few people would >> take the time to implement it securely, and instead would mostly >> leverage its power to do things that aren't at all security related. >> Sure, removing the default SM and Policy implementation reduces the >> complexity a little, but there would still be a fairly significant >> maintenance overhead and an additional drawback that it would make it >> more difficult for applications and libraries to depend on any type >> of consistent behavior. >> >> --Sean >> >> >>> So, here's the idea. It is assumed (for the sake of common >>> understanding) that as things stand, all of the classes and members >>> marked as "deprecated for removal" as a part of JEP 411 are intended >>> to be completely removed without replacement at the end of the term of >>> deprecation.? The proposals here are based on this assumption. >>> >>> The center of this proposal is that, at the end of the term of >>> deprecation, all of the deprecated classes, members, and behavior are >>> still removed (including, and especially, AccessController and Policy >>> and related classes) /except/ as mentioned here: >>> >>> ? * Rather than completely removing SecurityManager, >>> ????? * The SecurityManager class becomes abstract and non-deprecated, >>> with all of its methods being removed, except as follows >>> ????? * SecurityManager.getSecurityContext() becomes abstract (this is >>> the one that returns Object, *not* the stack walking one) >>> ????? * SecurityManager.checkPermission() (both of them) become >>> abstract >>> ? * Rather than removing the SecurityManager-related methods from >>> System, >>> ????? * System.getSecurityManager() is retained and de-deprecated >>> ????? * [Optional] System.setSecurityManager() is retained and >>> de-deprecated (we would want to explore whether it is feasible to >>> replace this (and the system property lookup mechanism) using >>> ServiceLoader, if bootstrap allows it) >>> ? * [Optional] Rather than /immediately/ removing all of >>> AccessController, >>> ????? * Retain its deprecation-for-removal status >>> ????? * Retain only doPrivileged(PrivilegedAction) and >>> doPrivileged(PrivilegedExceptionAction) as simple pass-throughs (no >>> JVM semantics other than being present on the call stack like any >>> method) since they are pervasively used, to allow frameworks time to >>> transition to (for example) a third-party alternative. >>> >>> The burden of permission verification would lie completely with the >>> security manager implementation.? The JDK would not have a >>> 'SecurityManager' implementation of any kind, outside of the internal >>> test suite. >>> >>> The other part of this proposal can come in one of two possible >>> flavors. >>> >>> ### Option 1: Authorization interfaces >>> >>> Each point in the JDK where there presently is a permission check is >>> classified into an authorization category of related operations. An >>> interface is introduced for each category which contains the methods >>> encapsulating the relevant check, in a package that is deemed most >>> appropriate for that particular grouping.? For example, there might be >>> a 'SocketAuthorization' interface in the 'java.net' package, with >>> methods like 'checkConnect(SocketAddress from, SocketAddress to)' and >>> 'checkAccept(SocketAddress addr)'. >>> >>> At the point where a permission check previously would take place, a >>> check like this is performed instead: >>> >>> ???? if (System.getSecurityManager() instanceof SocketAuthorization >>> sa) { >>> ???????? sa.checkAccept(addr); >>> ???? } >>> >>> Any public or protected method with such a check should include >>> @throws Javadoc explaining that a SecurityException may be thrown. >>> >>> The Permission subclasses previously used specifically by these >>> operation sites *may* in this case be deprecated for removal >>> immediately or at some point in the future, if desired. >>> >>> It is the sole responsibility of the SecurityManager implementer to >>> implement the various necessary interfaces, and any third-party >>> authorization interfaces that would also be relevant. >>> >>> ### Option 2: Retain permission system >>> >>> Under this option, the existing authorization checks are mostly >>> retained, however, since the SecurityManager class only has a general >>> 'checkPermission()' method, the logic previously found in the >>> 'SecurityManager' class which expands specific check calls into >>> general 'checkPermission()' calls (for example, calls to >>> 'checkConnect' for sockets) would necessarily become the >>> responsibility of the site of the permission check.? Some work would >>> be undertaken >>> to refactor this code accordingly. >>> >>> With this solution, the corresponding Permission subclasses would be >>> retained indefinitely. >>> >>> In either case it is the responsibility of the implementer of >>> SecurityManager to utilize these checks appropriately for >>> authorization decisions, based on whatever factors are deemed >>> appropriate, which may include contextual information such as a >>> currently-authenticated identity or the call stack, or (for example) a >>> context object utilizing the ScopeLocal mechanism. >>> >>> ### Other changes >>> >>> It would be worth exploring whether the SecurityManager installation >>> could be refitted to use the ServiceLoader mechanism (for example at >>> first call to getSecurityManager()) based on the class loader of the >>> application class or module path.? This would allow the >>> 'System.setSecurityManager' method, and support for the corresponding >>> system property, to be removed at the end of the term of deprecation. >>> >>> Testing >>> >>> Neither solution would ease the burden of testing from the JDK quite >>> as much as complete removal, of course. The necessary testing for the >>> individual checks should be limited to ensuring that the permission >>> check calls are happening with correct arguments and that any thrown >>> SecurityException is propagated.? The policy for testing >>> SecurityManager installation would depend on whether, and to what >>> extent, the more recent changes restricting the installation of the >>> security manager are reversed.? Other testing issues may arise as >>> well. >>> >> > From david.lloyd at redhat.com Fri Apr 8 13:03:58 2022 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 8 Apr 2022 08:03:58 -0500 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> Message-ID: Hi Sean, thanks for replying. I'll reply inline. On Thu, Apr 7, 2022 at 2:20 PM Sean Mullan wrote: > > With this proposal, as I understand it, the JDK would still be > responsible for maintaining and preserving essentially all of the > existing calls to the Security Manager (SM). I think we'd actually want to evaluate each case to decide whether to retain the permission check. But I didn't want to preemptively eliminate any check, especially considering that the `Permission` classes were not included in JEP 411. > All new code and APIs would > still need to be evaluated and determined if permission checks were > needed as well as making appropriate specification changes to note the > behavior when an SM is enabled (throwing a SecurityException, etc). Correct. > Any missing checks would need to be treated as security issues. This I disagree with: we are not proposing retention of this API for sandboxing purposes. In fact the only reason to keep the name `SecurityManager` is for compatibility purposes. Instead the API would exist to give containers and applications an extra layer of authorization which does not exist today. Hypothetically speaking, if even one authorization check is retained, then that is more than would exist if the API were removed. There would be no expectation that usage of this API conveys any kind of end to end security, and this would be explicitly conveyed in the API documentation. > And we would > still need to test the code and APIs to ensure that it worked properly > and complied with the API specification. This would likely mean > implementing and maintaining an internal SM implementation in OpenJDK. Only within the test suite, and this would be expected to be trivial implementations only: always allow vs always throw. > The proposal also includes retaining calls to doPrivileged (but later > potentially replacing them with some other mechanism TBD). No, this is incorrect; the proposal includes retaining the *methods*, not the calls; this is explicitly left off of the proposal. > The JDK source code includes over 1000 calls to doPrivileged. Each of these need > to be carefully reviewed to ensure that they do not contain security > issues and any new code needs to be evaluated to see if new calls to > doPrivileged are necessary. Under this proposal, it would be perfectly acceptable to eliminate these calls, and put the onus on the implementation to decide the circumstances of the invocation. The JDK would be under no obligation to provide any level of actual security - it would only be obligated to use the installed SecurityManager, if any, for authorization checks at some subset of the locations at which an authorization check currently takes place. > Retaining doPrivileged (or something similar) means that there can be > domains of code with different permissions running within the VM, which > retains much of the complexity of the current SM model. The only reason to retain these methods is the massive amount of existing code which is doing something along the lines of: if (System.getSecurityManager() != null) { doPrivileged(something); } else { something.run(); } It has nothing to do with what is in the JDK, which is why this item was marked "optional" in the initial proposal. > In this proposal, how privileges are established or propagated is > implementation-specific. But how could applications or libraries depend > on the APIs and still have some confidence that the code is behaving > consistently and securely? It is already an error to assume that code is behaving consistently and securely on the sole basis of the presence of a SecurityManager, and this would not change; the major difference is that the API would be able to explicitly document this fact. The value that the user gains from using a SecurityManager versus not using one would be that JDK operations would be authorization checked. > Today, the cost of buying into the SM model is high for libraries and > applications. Not many third party libraries support the SM and have > modified their code to perform permission checks and call doPrivileged > in the right places. If there were pluggable SMs each behaving > differently, there would likely be less incentive. The point of retaining these APIs isn't necessarily to increase usage; it is to provide some continuity for things which already expect some level of authorization from the JDK. We think that it is the case that this would add some value for our customers and users which offsets the value lost by the removal of SM. The question is, is the value enough to make our efforts to make this happen worthwhile? This is not only a question of the cost of developing the JEP and implementation effort, but also a question of how difficult it will be to gain enough acceptance of the idea in the upstream community that the change could potentially be integrated. > Although it sounds beneficial to be able to delegate the SM > implementation to a 3rd-party, in reality, I think very few people would > take the time to implement it securely, and instead would mostly > leverage its power to do things that aren't at all security related. The fact that it has the word "security" in the name is really just a historical curiosity, really. The APIs would be (and presently are) security-related but were *never* adequate for the purposes for which they were documented, i.e. sandboxing. We don't want it for sandboxing, but for having a point at which we can authorize some of these internal JDK operations in the same way we can authorize higher-level operations. Any suggestion of actual security by an implementation should specifically be disclaimed in the API documentation. In fact that should already be the case today, IMO. This is completely up to the implementation, as would be any other guarantees, just as with any other API. I hope this clarifies things. Like I said, "no" is an acceptable answer for us but I would be remiss if I didn't ensure that the "no" was based on an accurate understanding of what we are proposing, so hopefully this helps. -- - DML ? he/him From david.lloyd at redhat.com Fri Apr 8 13:07:15 2022 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 8 Apr 2022 08:07:15 -0500 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> Message-ID: Small correction: On Fri, Apr 8, 2022 at 8:03 AM David Lloyd wrote: > Instead the API would exist to give containers and applications an > extra layer of authorization which does not exist today. Of course I meant "which would not exist after JEP 411". -- - DML ? he/him From mullan at openjdk.java.net Fri Apr 8 13:48:09 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 8 Apr 2022 13:48:09 GMT Subject: RFR: 8284105: Update security libraries to use sealed classes Message-ID: Please review these changes to update the security libraries to use sealed classes. See JEP 409 for more details on sealed classes. No CSR is required as all the changes are to internal classes. A few classes that did not have subclasses were simply marked final instead of sealed. ------------- Commit messages: - Update security libraries to use sealed classes. Changes: https://git.openjdk.java.net/jdk/pull/8165/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8165&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284105 Stats: 50 lines in 20 files changed: 8 ins; 0 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/8165.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8165/head:pull/8165 PR: https://git.openjdk.java.net/jdk/pull/8165 From weijun at openjdk.java.net Fri Apr 8 13:53:41 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 8 Apr 2022 13:53:41 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v3] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 19:21: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: > > Update copyright year @bchristi-git showed me this test. You might try it on other objects: import org.ietf.jgss.GSSManager; import org.ietf.jgss.GSSName; import java.util.WeakHashMap; public class A1 { private static WeakHashMap whm = new WeakHashMap(); public static void main(String[] args) throws Exception { System.setProperty("sun.security.nativegss.debug", "true"); System.setProperty("sun.security.jgss.native", "true"); GSSName e = GSSManager.getInstance().createName("u1", GSSName.NT_USER_NAME); whm.put(e, null); e = null; for (int i = 0; i < 10; i++) { System.gc(); Thread.sleep(100); } if (whm.size() > 0) { throw new RuntimeException("GSSElementName still reachable"); } } } ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From sean.mullan at oracle.com Fri Apr 8 15:13:55 2022 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 8 Apr 2022 11:13:55 -0400 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> Message-ID: <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Ok, thanks for some clarification on the proposal. How many applications currently depend on the SM for this type of usage? What other alternate models have you considered? In general, I think authorization is best done at a higher layer within the application and not via low-level SM callouts. Authorize the subject first and if not acceptable, prevent the operation or API from being called in the first place. Once the operation is in motion, you have already taken a greater risk that something might go wrong. > I hope this clarifies things. Like I said, "no" is an acceptable > answer for us but I would be remiss if I didn't ensure that the "no" > was based on an accurate understanding of what we are proposing, so > hopefully this helps. It does help, but not enough to change my previous stance. --Sean On 4/8/22 9:03 AM, David Lloyd wrote: > Instead the API would exist to give containers and applications an > extra layer of authorization which does not exist today. > Hypothetically speaking, if even one authorization check is retained, > then that is more than would exist if the API were removed. There > would be no expectation that usage of this API conveys any kind of end > to end security, and this would be explicitly conveyed in the API > documentation. From naoto at openjdk.java.net Fri Apr 8 15:26:35 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 8 Apr 2022 15:26:35 GMT Subject: Integrated: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. This pull request has now been integrated. Changeset: d6b4693c Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/d6b4693c0527385f8999089b3f8b2120548efecb Stats: 750 lines in 182 files changed: 3 ins; 3 del; 744 mod 8283698: Refactor Locale constructors used in src/test Reviewed-by: iris, joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From darcy at openjdk.java.net Fri Apr 8 16:02:36 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 8 Apr 2022 16:02:36 GMT Subject: RFR: 8284105: Update security libraries to use sealed classes In-Reply-To: References: Message-ID: <1Pz5dX3pxN8Nvw5IDSsR2US5_TQ10HWWWApypC8OwYE=.79952e0b-8cc0-43fc-a6b4-1faaf629507a@github.com> On Fri, 8 Apr 2022 13:40:37 GMT, Sean Mullan wrote: > Please review these changes to update the security libraries to use sealed classes. See JEP 409 for more details on sealed classes. > > No CSR is required as all the changes are to internal classes. A few classes that did not have subclasses were simply marked final instead of sealed. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8165 From david.lloyd at redhat.com Fri Apr 8 16:04:10 2022 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 8 Apr 2022 11:04:10 -0500 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: On Fri, Apr 8, 2022 at 10:14 AM Sean Mullan wrote: > > Ok, thanks for some clarification on the proposal. > > How many applications currently depend on the SM for this type of usage? > What other alternate models have you considered? There are some number of customers and users within our user base who rely on SM for certain security certifications or requirements. The alternative would be to attempt to reframe these certifications or requirements on a case by case basis to exclude SM, which might or might not be less work than preserving it. > In general, I think authorization is best done at a higher layer within > the application and not via low-level SM callouts. Authorize the subject > first and if not acceptable, prevent the operation or API from being > called in the first place. Once the operation is in motion, you have > already taken a greater risk that something might go wrong. The low level authorization checks would be in addition to the high level checks that we already perform. But I understand your position. > > I hope this clarifies things. Like I said, "no" is an acceptable > > answer for us but I would be remiss if I didn't ensure that the "no" > > was based on an accurate understanding of what we are proposing, so > > hopefully this helps. > > It does help, but not enough to change my previous stance. OK, thanks for the feedback. -- - DML ? he/him From weijun at openjdk.java.net Fri Apr 8 16:20:46 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 8 Apr 2022 16:20:46 GMT Subject: RFR: 8284105: Update security libraries to use sealed classes In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:40:37 GMT, Sean Mullan wrote: > Please review these changes to update the security libraries to use sealed classes. See JEP 409 for more details on sealed classes. > > No CSR is required as all the changes are to internal classes. A few classes that did not have subclasses were simply marked final instead of sealed. It looks `KrbTgsRep.java`, `Krb5ProxyCredential.java`, `Builder.java`, `Vertex.java`, `Validator.java`, and `RSAKeyPairGenerator.java` can all be made package private. src/java.base/share/classes/sun/security/rsa/RSASignature.java line 50: > 48: * @author Andreas Sterbenz > 49: */ > 50: public abstract class RSASignature extends SignatureSpi { We can probably move the `RSASignature.encodeSignature` method to `RSAUtil` and this class can be package private. src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java line 64: > 62: */ > 63: > 64: public abstract class IntegerPolynomial implements IntegerFieldModuloP { Although we only have several implementations, I think this class is meant to be freely extendable for whatever new modulus. ------------- PR: https://git.openjdk.java.net/jdk/pull/8165 From xuelei at openjdk.java.net Fri Apr 8 16:31:34 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 8 Apr 2022 16:31:34 GMT Subject: RFR: 8284105: Update security libraries to use sealed classes In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:40:37 GMT, Sean Mullan wrote: > Please review these changes to update the security libraries to use sealed classes. See JEP 409 for more details on sealed classes. > > No CSR is required as all the changes are to internal classes. A few classes that did not have subclasses were simply marked final instead of sealed. It looks safe to me as if compiling and test passed. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8165 From bchristi at openjdk.java.net Fri Apr 8 19:03:38 2022 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 8 Apr 2022 19:03:38 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v3] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:50:25 GMT, Weijun Wang wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > @bchristi-git showed me this test. You might try it on other objects: > > import org.ietf.jgss.GSSManager; > import org.ietf.jgss.GSSName; > > import java.util.WeakHashMap; > > public class A1 { > private static WeakHashMap whm = new WeakHashMap(); > public static void main(String[] args) throws Exception { > System.setProperty("sun.security.nativegss.debug", "true"); > System.setProperty("sun.security.jgss.native", "true"); > GSSName e = GSSManager.getInstance().createName("u1", GSSName.NT_USER_NAME); > whm.put(e, null); > e = null; > for (int i = 0; i < 10; i++) { > System.gc(); > Thread.sleep(100); > } > if (whm.size() > 0) { > throw new RuntimeException("GSSName still reachable"); > } > } > } > > The test ensures the objects are GCed and there's no memory leak. You need to inspect the debug output to make sure native resources are released. The `NativeGSSContext` code still needs to be fixed. Thanks, @wangweij . Wherever practical, it would be good to include tests to confirm correct conversions from finalizer to Cleaner -- bugs can be subtle, and hard to spot. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From mullan at openjdk.java.net Fri Apr 8 19:52:58 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 8 Apr 2022 19:52:58 GMT Subject: RFR: 8284105: Update security libraries to use sealed classes In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 16:17:19 GMT, Weijun Wang wrote: > It looks `KrbTgsRep.java`, `Krb5ProxyCredential.java`, `Builder.java`, `Vertex.java`, `Validator.java`, and `RSAKeyPairGenerator.java` can all be made package private. Good point, although I would prefer to leave `Validator` as public for now until we are more sure of the compatibility risk as there have been external dependencies on it. It may be useful to apply the `sealed` modifier to package-private classes, but for this RFE that is not the goal, so I will remove the `sealed` modifier from these classes (if applicable) when I make them package-private. ------------- PR: https://git.openjdk.java.net/jdk/pull/8165 From mullan at openjdk.java.net Fri Apr 8 20:07:32 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 8 Apr 2022 20:07:32 GMT Subject: RFR: 8284105: Update security libraries to use sealed classes [v2] In-Reply-To: References: Message-ID: > Please review these changes to update the security libraries to use sealed classes. See JEP 409 for more details on sealed classes. > > No CSR is required as all the changes are to internal classes. A few classes that did not have subclasses were simply marked final instead of sealed. Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: Make some classes package-private instead of sealed. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8165/files - new: https://git.openjdk.java.net/jdk/pull/8165/files/52aa0ad6..c27b1ba0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8165&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8165&range=00-01 Stats: 93 lines in 8 files changed: 42 ins; 38 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8165.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8165/head:pull/8165 PR: https://git.openjdk.java.net/jdk/pull/8165 From mullan at openjdk.java.net Fri Apr 8 20:07:33 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 8 Apr 2022 20:07:33 GMT Subject: RFR: 8284105: Update security libraries to use sealed classes [v2] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 16:11:27 GMT, Weijun Wang wrote: >> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: >> >> Make some classes package-private instead of sealed. > > src/java.base/share/classes/sun/security/rsa/RSASignature.java line 50: > >> 48: * @author Andreas Sterbenz >> 49: */ >> 50: public abstract class RSASignature extends SignatureSpi { > > We can probably move the `RSASignature.encodeSignature` method to `RSAUtil` and this class can be package private. Ok. I'll also move `RSASignature.decodeSignature` to `RSAUtil` to maintain symmetry even though it isn't called outside the package. > src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java line 64: > >> 62: */ >> 63: >> 64: public abstract class IntegerPolynomial implements IntegerFieldModuloP { > > Although we only have several implementations, I think this class is meant to be freely extendable for whatever new modulus. We can always add new ones to the permits clause later. ------------- PR: https://git.openjdk.java.net/jdk/pull/8165 From weijun at openjdk.java.net Fri Apr 8 21:35:52 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 8 Apr 2022 21:35:52 GMT Subject: RFR: 8284105: Update security libraries to use sealed classes [v2] In-Reply-To: References: Message-ID: <7psyf3MeJPbBpWlSPXa58-9WEseYjNdmzj_5vs0-u6g=.578aa638-d774-42ac-9844-5b6efd618994@github.com> On Fri, 8 Apr 2022 20:07:32 GMT, Sean Mullan wrote: >> Please review these changes to update the security libraries to use sealed classes. See JEP 409 for more details on sealed classes. >> >> No CSR is required as all the changes are to internal classes. A few classes that did not have subclasses were simply marked final instead of sealed. > > Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: > > Make some classes package-private instead of sealed. Only one comment. Others look fine. src/java.security.jgss/share/classes/sun/security/krb5/KrbTgsRep.java line 43: > 41: * Kerberos client. > 42: */ > 43: final class KrbTgsRep extends KrbKdcRep { Make `KrbAsRep` final also to be symmetric. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8165 From wetmore at openjdk.java.net Fri Apr 8 22:58:53 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 8 Apr 2022 22:58:53 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2] In-Reply-To: <5_6f8JkmZHTg5ITqUdEhm5l3mNNTmxPKtht6ct3PMXU=.d58d95a1-9f88-45a0-9294-f29d75263934@github.com> References: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> <5_6f8JkmZHTg5ITqUdEhm5l3mNNTmxPKtht6ct3PMXU=.d58d95a1-9f88-45a0-9294-f29d75263934@github.com> Message-ID: On Fri, 8 Apr 2022 06:52:57 GMT, Xue-Lei Andrew Fan wrote: > The Socket implementation will take care of the file description/native memory release, I think. I've walked through the network code and understand it now. The Socket creation code calls into sun.nio.ch.NioSocketImpl.create():451, which then allocates the FileDescriptor fd and assigns it to the Socket, then registers a closer for that FileDescriptor which will be triggered by the Socket GC. When the Socket is reclaimed, the FileDescriptor is released, but not by referencing the Socket itself. > It is expected to send the close_notify at the TLS layer. But the current code using finalizer, which is not reliable. The underlying socket may have been closed when the SSLSocket finalizing action is triggered. Generally, application should call close() method explicitly, otherwise the finalizer is not expect to work reliable. I was wondering it may be safe to remove the finalizer. Yeah, I'm just not sure yet. > I agree that adding a best effort cleanup may be better. I was wondering to check if it is possible to clean the socket in the socket creation factories so that the object reference issues could be resolved. But as socket is a kind of resource, application layer may make the clean up as well. > I'm still looking for a solution to clean up resource by using a method of 'this'. Please advice if anyone has experiences. @AlanBateman, @dfuch, any great ideas here? ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From xuelei at openjdk.java.net Sat Apr 9 06:19:12 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 9 Apr 2022 06:19:12 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v4] 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 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: - add test cases - Merge - Update copyright year - the object reference issue for Cleaner - 8284490: Remove finalizer method in java.security.jgss ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8136/files - new: https://git.openjdk.java.net/jdk/pull/8136/files/23072ef7..464d3981 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=02-03 Stats: 3287 lines in 428 files changed: 1330 ins; 532 del; 1425 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 xuelei at openjdk.java.net Sat Apr 9 06:26:41 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 9 Apr 2022 06:26:41 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v3] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:50:25 GMT, Weijun Wang wrote: > You might try it on other objects: Nice idea to test object collection. I added two test cases. > The `NativeGSSContext` code still needs to be fixed. Could you have more details? I did not catch the comment about NativeGSSContext. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From alanb at openjdk.java.net Sat Apr 9 11:55:40 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 9 Apr 2022 11:55:40 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2] In-Reply-To: References: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> <5_6f8JkmZHTg5ITqUdEhm5l3mNNTmxPKtht6ct3PMXU=.d58d95a1-9f88-45a0-9294-f29d75263934@github.com> Message-ID: On Fri, 8 Apr 2022 22:55:07 GMT, Bradford Wetmore wrote: > @AlanBateman, @dfuch, @bchristi-git, any great ideas here? As you have found, if an open Socket is unreferenced then a cleaner can close the underlying socket (and release the file descriptor). The Cleaner is setup by the SocketImpl implementation. What is the existing behavior with the BaseSSLSocketImpl finalizer? Does it just close the socket or does it to the close_notify before closing the socket. If it does, and you want to keep that behavior, then you are probably into significant refactoring to avoid a reference to the BaseSSLSocketImpl. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From xuelei at openjdk.java.net Sat Apr 9 15:02:32 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 9 Apr 2022 15:02:32 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2] In-Reply-To: References: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> <5_6f8JkmZHTg5ITqUdEhm5l3mNNTmxPKtht6ct3PMXU=.d58d95a1-9f88-45a0-9294-f29d75263934@github.com> Message-ID: <91y6fK9OtKDJje4DBLEbkm1qkX9Unumx78bmXKi3j_4=.bf87239e-1361-4285-bcb2-30fd66772370@github.com> On Sat, 9 Apr 2022 11:52:01 GMT, Alan Bateman wrote: > What is the existing behavior with the BaseSSLSocketImpl finalizer? Does it just close the socket or does it to the close_notify before closing the socket. If it does, and you want to keep that behavior, then you are probably into significant refactoring to avoid a reference to the BaseSSLSocketImpl. The existing behavior is trying to close the socket and send the close_notify. As the socket closure has been done in the SocketImpl, I think BaseSSLSocketImpl could rely on to the SocketImpl cleaner. So the left for the cleaning is about the close_notify. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From weijun at openjdk.java.net Sat Apr 9 15:03:40 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 9 Apr 2022 15:03:40 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v3] In-Reply-To: References: Message-ID: On Sat, 9 Apr 2022 06:22:51 GMT, Xue-Lei Andrew Fan wrote: > Could you have more details? I did not catch the comment about NativeGSSContext. When `NativeGSSContext(GSSNameElement peer, GSSCredElement myCred, int time, GSSLibStub stub)` is called, `pContext` is 0 and you haven't registered the cleaner. Later, when `initSecContext()` is called, it calls into `cStub.initContext()` and this native method will set `pContext` if a context is established. Since you haven't registered the cleaner in the ctor, this native context will not be released at the end. So one solution is to add a `setNativeContext(long pContext)` method and when this method is called you register the cleaner. Now, inside the native method, instead of setting the `pContext` field directly you can call this setter method. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From wetmore at openjdk.java.net Sat Apr 9 17:04:31 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Sat, 9 Apr 2022 17:04:31 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2] In-Reply-To: <91y6fK9OtKDJje4DBLEbkm1qkX9Unumx78bmXKi3j_4=.bf87239e-1361-4285-bcb2-30fd66772370@github.com> References: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> <5_6f8JkmZHTg5ITqUdEhm5l3mNNTmxPKtht6ct3PMXU=.d58d95a1-9f88-45a0-9294-f29d75263934@github.com> <91y6fK9OtKDJje4DBLEbkm1qkX9Unumx78bmXKi3j_4=.bf87239e-1361-4285-bcb2-30fd66772370@github.com> Message-ID: On Sat, 9 Apr 2022 14:59:13 GMT, Xue-Lei Andrew Fan wrote: > The existing behavior is trying to close the socket and send the close_notify. As the socket closure has been done in the SocketImpl, I think BaseSSLSocketImpl could rely on to the SocketImpl cleaner. So the left for the cleaning is about the close_notify. @AlanBateman, just to clarify, send the close_notify first, then close the socket. >From the Socket's point of view, the encrypted close_notify message is just a few bytes of application data sent over the Socket's OutputStream. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From jjiang at openjdk.java.net Mon Apr 11 04:10:05 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Mon, 11 Apr 2022 04:10:05 GMT Subject: RFR: 8284641: Doc errors in sun.security.ssl.SSLSessionContextImpl Message-ID: JDK-8228396 turned stateless resumption on by default, but the JavaDoc was not modified accordingly. And a "{" is missing for @systemProperty jdk.tls.server.enableSessionTicketExtension. ------------- Commit messages: - 8284641: Doc errors in sun.security.ssl.SSLSessionContextImpl Changes: https://git.openjdk.java.net/jdk/pull/8173/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8173&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284641 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8173.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8173/head:pull/8173 PR: https://git.openjdk.java.net/jdk/pull/8173 From xuelei at openjdk.java.net Mon Apr 11 04:31:41 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 11 Apr 2022 04:31:41 GMT Subject: RFR: 8284641: Doc errors in sun.security.ssl.SSLSessionContextImpl In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 04:02:44 GMT, John Jiang wrote: > JDK-8228396 turned stateless resumption on by default, but the JavaDoc was not modified accordingly. > And a "{" is missing for @systemProperty jdk.tls.server.enableSessionTicketExtension. Nice catch. Thank you! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8173 From ssahoo at openjdk.java.net Mon Apr 11 06:19:41 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Mon, 11 Apr 2022 06:19:41 GMT Subject: RFR: 8284641: Doc errors in sun.security.ssl.SSLSessionContextImpl In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 04:02:44 GMT, John Jiang wrote: > JDK-8228396 turned stateless resumption on by default, but the JavaDoc was not modified accordingly. > And a "{" is missing for @systemProperty jdk.tls.server.enableSessionTicketExtension. Marked as reviewed by ssahoo (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8173 From jjiang at openjdk.java.net Mon Apr 11 06:43:39 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Mon, 11 Apr 2022 06:43:39 GMT Subject: Integrated: 8284641: Doc errors in sun.security.ssl.SSLSessionContextImpl In-Reply-To: References: Message-ID: <5dtLYmrEUuixuAtEORzhcrK6LSE9Q-X_yxhHzx-I4iE=.98bb20ab-5ecd-44b2-9e11-962b5f9e2fe6@github.com> On Mon, 11 Apr 2022 04:02:44 GMT, John Jiang wrote: > JDK-8228396 turned stateless resumption on by default, but the JavaDoc was not modified accordingly. > And a "{" is missing for @systemProperty jdk.tls.server.enableSessionTicketExtension. This pull request has now been integrated. Changeset: 40ddb755 Author: John Jiang URL: https://git.openjdk.java.net/jdk/commit/40ddb7558cd985d49aa5aaedae6c5145ba3d0ac0 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8284641: Doc errors in sun.security.ssl.SSLSessionContextImpl Reviewed-by: xuelei, ssahoo ------------- PR: https://git.openjdk.java.net/jdk/pull/8173 From dholmes at openjdk.java.net Mon Apr 11 10:40:36 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Apr 2022 10:40:36 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v24] In-Reply-To: References: Message-ID: <-3pH-9NVTEgTBaWbZ05s8pSHxZZIwMFUlgxPpqvke8s=.2a1299f4-6bc4-46b1-8cea-181fb17e6f6a@github.com> On Mon, 4 Apr 2022 14:57:30 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix TestLinkToNativeRBP VM changes look good. Thanks, David src/hotspot/share/prims/scopedMemoryAccess.cpp line 141: > 139: > 140: /* > 141: * This function performs a thread-local handshake against all threads running at the time Nit: thread-local?? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Mon Apr 11 12:07:34 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 11 Apr 2022 12:07:34 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v24] In-Reply-To: <-3pH-9NVTEgTBaWbZ05s8pSHxZZIwMFUlgxPpqvke8s=.2a1299f4-6bc4-46b1-8cea-181fb17e6f6a@github.com> References: <-3pH-9NVTEgTBaWbZ05s8pSHxZZIwMFUlgxPpqvke8s=.2a1299f4-6bc4-46b1-8cea-181fb17e6f6a@github.com> Message-ID: On Mon, 11 Apr 2022 10:33:54 GMT, David Holmes wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix TestLinkToNativeRBP > > src/hotspot/share/prims/scopedMemoryAccess.cpp line 141: > >> 139: >> 140: /* >> 141: * This function performs a thread-local handshake against all threads running at the time > > Nit: thread-local?? I was assuming the term "thread-local handshake" was a thing in the VM, as per: https://openjdk.java.net/jeps/312 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mullan at openjdk.java.net Mon Apr 11 12:53:31 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 11 Apr 2022 12:53:31 GMT Subject: RFR: 8284105: Update security libraries to use sealed classes [v3] In-Reply-To: References: Message-ID: > Please review these changes to update the security libraries to use sealed classes. See JEP 409 for more details on sealed classes. > > No CSR is required as all the changes are to internal classes. A few classes that did not have subclasses were simply marked final instead of sealed. Sean Mullan 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: - Make KrbAsRep final. - Merge - Make some classes package-private instead of sealed. - Update security libraries to use sealed classes. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8165/files - new: https://git.openjdk.java.net/jdk/pull/8165/files/c27b1ba0..2a1ab2b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8165&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8165&range=01-02 Stats: 4066 lines in 394 files changed: 1983 ins; 791 del; 1292 mod Patch: https://git.openjdk.java.net/jdk/pull/8165.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8165/head:pull/8165 PR: https://git.openjdk.java.net/jdk/pull/8165 From dfuchs at openjdk.java.net Mon Apr 11 14:27:39 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 11 Apr 2022 14:27:39 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v4] In-Reply-To: References: Message-ID: <_g2F6jY1F5LJpeq4PkwhPgegjZLEm0SPFcKYVxdRMP4=.de7f9dba-34e0-409c-8ebe-462cabb957c8@github.com> On Sat, 9 Apr 2022 06:19:12 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 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: > > - add test cases > - Merge > - Update copyright year > - the object reference issue for Cleaner > - 8284490: Remove finalizer method in java.security.jgss src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java line 188: > 186: printableType); > 187: > 188: cleanable = Krb5Util.cleaner.register(this, disposerFor(stub, pName)); I wonder if this line should be moved just after line 159? src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java line 307: > 305: } > 306: }; > 307: } There seem to be a potential optimization here, since you don't even need to create a Cleanable in the case where stub is null or pName is 0? Same for earlier duplication of the same code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From mullan at openjdk.java.net Mon Apr 11 15:45:49 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 11 Apr 2022 15:45:49 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() In-Reply-To: References: Message-ID: 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~ src/java.base/share/classes/javax/crypto/Cipher.java line 488: > 486: * A new {@code Cipher} object encapsulating the > 487: * {@code CipherSpi} implementation from the first > 488: * Provider that supports the specified algorithm is returned. Since "Provider" is capitalized, I think the intent was that this was the classname, so it should also probably be in an `@code` tag. Alternatively, you could change this to non-capitalized "provider" (w/o the @code tag) and I think it would still be readable (and my vote would be for this). src/java.base/share/classes/javax/crypto/Cipher.java line 655: > 653: * > 654: *

A new {@code Cipher} object encapsulating the > 655: * {@code CipherSpi} implementation from the specified Provider Since `Provider` here is a parameter, it is probably better to put this in an `@code` tag. src/java.base/share/classes/javax/crypto/Cipher.java line 2641: > 2639: * > 2640: * @param transformation the cipher transformation > 2641: * @return the maximum key length in bits or Integer.MAX_VALUE Integer.MAX_VALUE should be inside a `@code` tag. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From mullan at openjdk.java.net Mon Apr 11 18:05:41 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 11 Apr 2022 18:05:41 GMT Subject: Integrated: 8284105: Update security libraries to use sealed classes In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:40:37 GMT, Sean Mullan wrote: > Please review these changes to update the security libraries to use sealed classes. See JEP 409 for more details on sealed classes. > > No CSR is required as all the changes are to internal classes. A few classes that did not have subclasses were simply marked final instead of sealed. This pull request has now been integrated. Changeset: dc6ec2a4 Author: Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/dc6ec2a46720eaf0cc7ce36a732ba8d4679a50d5 Stats: 139 lines in 23 files changed: 50 ins; 38 del; 51 mod 8284105: Update security libraries to use sealed classes Reviewed-by: darcy, weijun, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/8165 From Matthew.Carter at microsoft.com Mon Apr 11 18:06:25 2022 From: Matthew.Carter at microsoft.com (Mat Carter) Date: Mon, 11 Apr 2022 18:06:25 +0000 Subject: Proposal: Extend Windows KeyStore support to include access to the local machine location In-Reply-To: References: Message-ID: Hi Weijun Did my answers address your concerns? Also do you have an opinion on Bernd's suggestion? Thanks in advance Mat Sent from Outlook ________________________________ From: security-dev on behalf of Bernd Eckenfels Sent: Tuesday, April 5, 2022 11:20 AM To: security-dev at openjdk.java.net Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location BTW, since this is Windows specific anyway and since we have also a combining virtual Keystore, why not allow a new naming scheme which allows to access any of the Keystores? like ?Windows-ROOT/ADdressbook?? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Mat Carter Gesendet: Dienstag, April 5, 2022 5:22 PM An: Wei-Jun Wang Cc: security-dev at openjdk.java.net Betreff: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location Hi Weijun Thank you for the feedback, I'd like to address point 2 first as I think this might also address point 1 >> 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear >> there and automatically chosen by a key manager. >> >> It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including >> new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. I deliberately kept implementation details out of the initial email to focus on the security aspects, but this point makes an assumption that the results of using "Windows-MY" or "Windows-ROOT" would change with this new functionality; this is not what we're proposing. Specifically we're proposing adding two new strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE" such that developers can now access the key stores in the local machine. To be clear, the implementation would make no attempt to "merge" results when enumerating or to search both locations via a single key store instance; i.e. you can only create and instance for accessing either keystore but not both. I think this addresses point 1 also, but if not then I have a follow on question: >> 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is >> trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. Our initial analysis leads us to believe that we'll not need to introduce new code paths to handle new certificates; i.e. the only code changes are how the key store is opened, subsequent calls to access certificates is handled by the existing code. Given the above assumption, your concerns laid out in point 1 and if your concern is not mitigated with our notes for point 2: is it the case that you expect new "types" of certificates to be accessible via local machine that weren't via current user and that some/all of these certs are "bad" (and would need new code paths to handle them)? While we are talking about implementation, there's another aspect we'd like to introduce/discuss: this is to allow developers to access the key stores with read only permissions, thus allowing enumeration and reading without requiring administrative permissions be granted to the application (thus increasing security) Thanks in advance Mat Sent from Outlook From: Wei-Jun Wang Sent: Friday, April 1, 2022 3:15 PM To: Mat Carter Cc: security-dev at openjdk.java.net Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location Hi Mat, We have 2 main concerns: 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear there and automatically chosen by a key manager. It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. And we have no plan to add other types like ADDRESSBOOK. Thanks, Weijun > On Mar 31, 2022, at 5:16 PM, Mat Carter wrote: > > Current support for KeyStores on Windows is limited to the current user location [1] > > There has been previous request for local machine support [2] along with discussion in the security-dev mailing list [3], further discussions have occurred on stackoverflow in the past [4] and [5] > > Using JNI you can access local machine locations but then you are duplicating much of the existing native functionality; this also adds the requirement that developers need to know C/C++ and the Windows cryptography API. > > Given the above I propose that we add native support for local machine KeyStore locations > > Users can currently access two physical key stores (in the current user location): > > "Windows-MY": .Default > "Windows-ROOT": .Default.LocalMachine, .SmartCard > > Adding the local machine location opens up access to a further two physical key stores ? > > "Windows-MY": .Default > "Windows-ROOT": .Default.AuthRoot, .GroupPolicy, .Enterprise, .SmartCard > > Please let me know if there are any existing efforts to bring this functionality to Java, or references to prior decisions on this subject > > Thanks in advance > Mat Carter > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fseccrypto%2Fsystem-store-locations&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hWj0cEVRachk47aqIKJYIwiaqTcACjWGn38AzmutX9I%3D&reserved=0 > [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-6782021&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TdXrBjrjqPniADcJiFnwQfi5uaCnI9BzgCPPJe%2FAhGA%3D&reserved=0 > [3] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fsecurity-dev%2F2018-August%2F017832.html&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=O4hI%2BTje%2FjtJTWosTLSNzVlQUW8s%2BoeoWMA27EaAHUc%3D&reserved=0 > [4] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F70200603%2Faccessing-windows-local-machine-certificates-from-a-windows-service-written-in-j&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FNqqbV%2BIircmaoas%2F%2BUX%2F%2BQpWVq9fpoV%2F4lCNB77ZzE%3D&reserved=0 > [5] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F3612962%2Faccess-local-machine-certificate-store-in-java&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JiEifjvBN%2B8ahoft9xdJhLwy1DEjkAWLHIVB1Oojnsk%3D&reserved=0 > > > Sent from Outlook -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Apr 11 18:45:12 2022 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Mon, 11 Apr 2022 18:45:12 +0000 Subject: Proposal: Extend Windows KeyStore support to include access to the local machine location In-Reply-To: References: Message-ID: Sorry for the late reply. Yes, your suggestions are good. We can support "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE". For read-only access to the keystores, we have already allowed writing and this probably will not change. If we do want to support read-only later, it could be a new name or a different LoadStoreParameters. As for Bernd's suggestion. Maybe DomainKeyStore can be used to combine existing keystores. I dare not add ADDRESSBOOK at the moment. Are certificates inside it fully trusted? Or you need to build a certpath to one of the root CAs to trust any of them? Thanks, Weijun > On Apr 11, 2022, at 2:06 PM, Mat Carter wrote: > > Hi Weijun > > Did my answers address your concerns? Also do you have an opinion on Bernd's suggestion? > > Thanks in advance > Mat > > Sent from Outlook > From: security-dev on behalf of Bernd Eckenfels > Sent: Tuesday, April 5, 2022 11:20 AM > To: security-dev at openjdk.java.net > Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location > > BTW, since this is Windows specific anyway and since we have also a combining virtual Keystore, why not allow a new naming scheme which allows to access any of the Keystores? like ?Windows-ROOT/ADdressbook?? > > Gruss > Bernd > > -- > http://bernd.eckenfels.net > Von: security-dev im Auftrag von Mat Carter > Gesendet: Dienstag, April 5, 2022 5:22 PM > An: Wei-Jun Wang > Cc: security-dev at openjdk.java.net > Betreff: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location > > Hi Weijun > > Thank you for the feedback, I'd like to address point 2 first as I think this might also address point 1 > > >> 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear > >> there and automatically chosen by a key manager. > >> > >> It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including > >> new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. > > I deliberately kept implementation details out of the initial email to focus on the security aspects, but this point makes an assumption that the results of using "Windows-MY" or "Windows-ROOT" would change with this new functionality; this is not what we're proposing. Specifically we're proposing adding two new strings "Windows-MY-LOCALMACHINE" and > "Windows-ROOT-LOCALMACHINE" such that developers can now access the key stores in the local machine. To be clear, the implementation would make no attempt to "merge" results when enumerating or to search both locations via a single key store instance; i.e. you can only create and instance for accessing either keystore but not both. > > I think this addresses point 1 also, but if not then I have a follow on question: > > >> 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is > >> trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. > > Our initial analysis leads us to believe that we'll not need to introduce new code paths to handle new certificates; i.e. the only code changes are how the key store is opened, subsequent calls to access certificates is handled by the existing code. > > Given the above assumption, your concerns laid out in point 1 and if your concern is not mitigated with our notes for point 2: is it the case that you expect new "types" of certificates to be accessible via local machine that weren't via current user and that some/all of these certs are "bad" (and would need new code paths to handle them)? > > While we are talking about implementation, there's another aspect we'd like to introduce/discuss: this is to allow developers to access the key stores with read only permissions, thus allowing enumeration and reading without requiring administrative permissions be granted to the application (thus increasing security) > > Thanks in advance > Mat > > Sent from Outlook > > > From: Wei-Jun Wang > Sent: Friday, April 1, 2022 3:15 PM > To: Mat Carter > Cc: security-dev at openjdk.java.net > Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location > > Hi Mat, > > We have 2 main concerns: > > 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. > > 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear there and automatically chosen by a key manager. > > It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. > > And we have no plan to add other types like ADDRESSBOOK. > > Thanks, > Weijun > > > On Mar 31, 2022, at 5:16 PM, Mat Carter wrote: > > > > Current support for KeyStores on Windows is limited to the current user location [1] > > > > There has been previous request for local machine support [2] along with discussion in the security-dev mailing list [3], further discussions have occurred on stackoverflow in the past [4] and [5] > > > > Using JNI you can access local machine locations but then you are duplicating much of the existing native functionality; this also adds the requirement that developers need to know C/C++ and the Windows cryptography API. > > > > Given the above I propose that we add native support for local machine KeyStore locations > > > > Users can currently access two physical key stores (in the current user location): > > > > "Windows-MY": .Default > > "Windows-ROOT": .Default.LocalMachine, .SmartCard > > > > Adding the local machine location opens up access to a further two physical key stores ? > > > > "Windows-MY": .Default > > "Windows-ROOT": .Default.AuthRoot, .GroupPolicy, .Enterprise, .SmartCard > > > > Please let me know if there are any existing efforts to bring this functionality to Java, or references to prior decisions on this subject > > > > Thanks in advance > > Mat Carter > > > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fseccrypto%2Fsystem-store-locations&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hWj0cEVRachk47aqIKJYIwiaqTcACjWGn38AzmutX9I%3D&reserved=0 > > [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-6782021&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TdXrBjrjqPniADcJiFnwQfi5uaCnI9BzgCPPJe%2FAhGA%3D&reserved=0 > > [3] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fsecurity-dev%2F2018-August%2F017832.html&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=O4hI%2BTje%2FjtJTWosTLSNzVlQUW8s%2BoeoWMA27EaAHUc%3D&reserved=0 > > [4] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F70200603%2Faccessing-windows-local-machine-certificates-from-a-windows-service-written-in-j&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FNqqbV%2BIircmaoas%2F%2BUX%2F%2BQpWVq9fpoV%2F4lCNB77ZzE%3D&reserved=0 > > [5] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F3612962%2Faccess-local-machine-certificate-store-in-java&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JiEifjvBN%2B8ahoft9xdJhLwy1DEjkAWLHIVB1Oojnsk%3D&reserved=0 > > > > > > Sent from Outlook From ecki at zusammenkunft.net Mon Apr 11 19:02:59 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 11 Apr 2022 19:02:59 +0000 Subject: Proposal: Extend Windows KeyStore support to include access to the local machine location In-Reply-To: References: Message-ID: Hello, if you can open/target specific stores dynamically it is up to the developer/user what they do with it (very similar to keystore files). Addressbook in my post was only an example (but a good one: imagine Java app wants to import the addressbook entries) Gruss Bernd -- https://bernd.eckenfels.net ________________________________ From: Wei-Jun Wang Sent: Monday, April 11, 2022 8:45:12 PM To: Mat Carter Cc: Bernd Eckenfels ; security-dev at openjdk.java.net Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location Sorry for the late reply. Yes, your suggestions are good. We can support "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE". For read-only access to the keystores, we have already allowed writing and this probably will not change. If we do want to support read-only later, it could be a new name or a different LoadStoreParameters. As for Bernd's suggestion. Maybe DomainKeyStore can be used to combine existing keystores. I dare not add ADDRESSBOOK at the moment. Are certificates inside it fully trusted? Or you need to build a certpath to one of the root CAs to trust any of them? Thanks, Weijun > On Apr 11, 2022, at 2:06 PM, Mat Carter wrote: > > Hi Weijun > > Did my answers address your concerns? Also do you have an opinion on Bernd's suggestion? > > Thanks in advance > Mat > > Sent from Outlook > From: security-dev on behalf of Bernd Eckenfels > Sent: Tuesday, April 5, 2022 11:20 AM > To: security-dev at openjdk.java.net > Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location > > BTW, since this is Windows specific anyway and since we have also a combining virtual Keystore, why not allow a new naming scheme which allows to access any of the Keystores? like ?Windows-ROOT/ADdressbook?? > > Gruss > Bernd > > -- > http://bernd.eckenfels.net > Von: security-dev im Auftrag von Mat Carter > Gesendet: Dienstag, April 5, 2022 5:22 PM > An: Wei-Jun Wang > Cc: security-dev at openjdk.java.net > Betreff: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location > > Hi Weijun > > Thank you for the feedback, I'd like to address point 2 first as I think this might also address point 1 > > >> 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear > >> there and automatically chosen by a key manager. > >> > >> It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including > >> new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. > > I deliberately kept implementation details out of the initial email to focus on the security aspects, but this point makes an assumption that the results of using "Windows-MY" or "Windows-ROOT" would change with this new functionality; this is not what we're proposing. Specifically we're proposing adding two new strings "Windows-MY-LOCALMACHINE" and > "Windows-ROOT-LOCALMACHINE" such that developers can now access the key stores in the local machine. To be clear, the implementation would make no attempt to "merge" results when enumerating or to search both locations via a single key store instance; i.e. you can only create and instance for accessing either keystore but not both. > > I think this addresses point 1 also, but if not then I have a follow on question: > > >> 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is > >> trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. > > Our initial analysis leads us to believe that we'll not need to introduce new code paths to handle new certificates; i.e. the only code changes are how the key store is opened, subsequent calls to access certificates is handled by the existing code. > > Given the above assumption, your concerns laid out in point 1 and if your concern is not mitigated with our notes for point 2: is it the case that you expect new "types" of certificates to be accessible via local machine that weren't via current user and that some/all of these certs are "bad" (and would need new code paths to handle them)? > > While we are talking about implementation, there's another aspect we'd like to introduce/discuss: this is to allow developers to access the key stores with read only permissions, thus allowing enumeration and reading without requiring administrative permissions be granted to the application (thus increasing security) > > Thanks in advance > Mat > > Sent from Outlook > > > From: Wei-Jun Wang > Sent: Friday, April 1, 2022 3:15 PM > To: Mat Carter > Cc: security-dev at openjdk.java.net > Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location > > Hi Mat, > > We have 2 main concerns: > > 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. > > 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear there and automatically chosen by a key manager. > > It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. > > And we have no plan to add other types like ADDRESSBOOK. > > Thanks, > Weijun > > > On Mar 31, 2022, at 5:16 PM, Mat Carter wrote: > > > > Current support for KeyStores on Windows is limited to the current user location [1] > > > > There has been previous request for local machine support [2] along with discussion in the security-dev mailing list [3], further discussions have occurred on stackoverflow in the past [4] and [5] > > > > Using JNI you can access local machine locations but then you are duplicating much of the existing native functionality; this also adds the requirement that developers need to know C/C++ and the Windows cryptography API. > > > > Given the above I propose that we add native support for local machine KeyStore locations > > > > Users can currently access two physical key stores (in the current user location): > > > > "Windows-MY": .Default > > "Windows-ROOT": .Default.LocalMachine, .SmartCard > > > > Adding the local machine location opens up access to a further two physical key stores ? > > > > "Windows-MY": .Default > > "Windows-ROOT": .Default.AuthRoot, .GroupPolicy, .Enterprise, .SmartCard > > > > Please let me know if there are any existing efforts to bring this functionality to Java, or references to prior decisions on this subject > > > > Thanks in advance > > Mat Carter > > > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fseccrypto%2Fsystem-store-locations&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hWj0cEVRachk47aqIKJYIwiaqTcACjWGn38AzmutX9I%3D&reserved=0 > > [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-6782021&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TdXrBjrjqPniADcJiFnwQfi5uaCnI9BzgCPPJe%2FAhGA%3D&reserved=0 > > [3] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fsecurity-dev%2F2018-August%2F017832.html&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=O4hI%2BTje%2FjtJTWosTLSNzVlQUW8s%2BoeoWMA27EaAHUc%3D&reserved=0 > > [4] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F70200603%2Faccessing-windows-local-machine-certificates-from-a-windows-service-written-in-j&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FNqqbV%2BIircmaoas%2F%2BUX%2F%2BQpWVq9fpoV%2F4lCNB77ZzE%3D&reserved=0 > > [5] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F3612962%2Faccess-local-machine-certificate-store-in-java&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Ce1886df700e44a0d94e108da142d2bf7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637844481503028351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JiEifjvBN%2B8ahoft9xdJhLwy1DEjkAWLHIVB1Oojnsk%3D&reserved=0 > > > > > > Sent from Outlook -------------- next part -------------- An HTML attachment was scrubbed... URL: From wetmore at openjdk.java.net Mon Apr 11 19:53:34 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Mon, 11 Apr 2022 19:53:34 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 Resettting the clock. Sorry for the delay. ------------- PR: https://git.openjdk.java.net/jdk/pull/7664 From Matthew.Carter at microsoft.com Mon Apr 11 21:02:15 2022 From: Matthew.Carter at microsoft.com (Mat Carter) Date: Mon, 11 Apr 2022 21:02:15 +0000 Subject: Proposal: Extend Windows KeyStore support to include access to the local machine location In-Reply-To: References: Message-ID: Thanks, Weijun Let's move ahead with the two new strings while we consider read-only access. As the current assignee can you update the JBS issue [1] with what we've agreed here. I have an implementation that I've been testing in 11u which can easily move to tip; if you are happy for me to make the changes then please ack here and re-assign the issue to me [1] https://bugs.openjdk.java.net/browse/JDK-6782021 Thanks Mat Sent from Outlook ________________________________ From: Wei-Jun Wang Sent: Monday, April 11, 2022 11:45 AM To: Mat Carter Cc: Bernd Eckenfels ; security-dev at openjdk.java.net Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location Sorry for the late reply. Yes, your suggestions are good. We can support "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE". For read-only access to the keystores, we have already allowed writing and this probably will not change. If we do want to support read-only later, it could be a new name or a different LoadStoreParameters. As for Bernd's suggestion. Maybe DomainKeyStore can be used to combine existing keystores. I dare not add ADDRESSBOOK at the moment. Are certificates inside it fully trusted? Or you need to build a certpath to one of the root CAs to trust any of them? Thanks, Weijun > On Apr 11, 2022, at 2:06 PM, Mat Carter wrote: > > Hi Weijun > > Did my answers address your concerns? Also do you have an opinion on Bernd's suggestion? > > Thanks in advance > Mat > > Sent from Outlook > From: security-dev on behalf of Bernd Eckenfels > Sent: Tuesday, April 5, 2022 11:20 AM > To: security-dev at openjdk.java.net > Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location > > BTW, since this is Windows specific anyway and since we have also a combining virtual Keystore, why not allow a new naming scheme which allows to access any of the Keystores? like ?Windows-ROOT/ADdressbook?? > > Gruss > Bernd > > -- > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbernd.eckenfels.net%2F&data=05%7C01%7CMatthew.Carter%40microsoft.com%7C9492ccb410834f633f4708da1beb6d02%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637852995228154570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qjRXhchorKHZFaQY4zuwXqSwVjmda7HkWJEN%2FtMeaT4%3D&reserved=0 > Von: security-dev im Auftrag von Mat Carter > Gesendet: Dienstag, April 5, 2022 5:22 PM > An: Wei-Jun Wang > Cc: security-dev at openjdk.java.net > Betreff: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location > > Hi Weijun > > Thank you for the feedback, I'd like to address point 2 first as I think this might also address point 1 > > >> 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear > >> there and automatically chosen by a key manager. > >> > >> It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including > >> new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. > > I deliberately kept implementation details out of the initial email to focus on the security aspects, but this point makes an assumption that the results of using "Windows-MY" or "Windows-ROOT" would change with this new functionality; this is not what we're proposing. Specifically we're proposing adding two new strings "Windows-MY-LOCALMACHINE" and > "Windows-ROOT-LOCALMACHINE" such that developers can now access the key stores in the local machine. To be clear, the implementation would make no attempt to "merge" results when enumerating or to search both locations via a single key store instance; i.e. you can only create and instance for accessing either keystore but not both. > > I think this addresses point 1 also, but if not then I have a follow on question: > > >> 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is > >> trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. > > Our initial analysis leads us to believe that we'll not need to introduce new code paths to handle new certificates; i.e. the only code changes are how the key store is opened, subsequent calls to access certificates is handled by the existing code. > > Given the above assumption, your concerns laid out in point 1 and if your concern is not mitigated with our notes for point 2: is it the case that you expect new "types" of certificates to be accessible via local machine that weren't via current user and that some/all of these certs are "bad" (and would need new code paths to handle them)? > > While we are talking about implementation, there's another aspect we'd like to introduce/discuss: this is to allow developers to access the key stores with read only permissions, thus allowing enumeration and reading without requiring administrative permissions be granted to the application (thus increasing security) > > Thanks in advance > Mat > > Sent from Outlook > > > From: Wei-Jun Wang > Sent: Friday, April 1, 2022 3:15 PM > To: Mat Carter > Cc: security-dev at openjdk.java.net > Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location > > Hi Mat, > > We have 2 main concerns: > > 1. In Java's KeyStore a certificate entry is called TrustedCertificateEntry. The name implies that the certificate is trusted for any purpose. We don't want some certificates that were not meant to be trusted shown up. > > 2. PrivateKeyEntry is (IMO) mainly used for client auth in TLS. We don't want new entries suddenly appear there and automatically chosen by a key manager. > > It looks OK to enhance Windows-ROOT to cover more root CA certs in your organization but including new entries in Windows-MY is a little dangerous. It's OK to introduce a new store type for MY in LOCAL_MACHINE. > > And we have no plan to add other types like ADDRESSBOOK. > > Thanks, > Weijun > > > On Mar 31, 2022, at 5:16 PM, Mat Carter wrote: > > > > Current support for KeyStores on Windows is limited to the current user location [1] > > > > There has been previous request for local machine support [2] along with discussion in the security-dev mailing list [3], further discussions have occurred on stackoverflow in the past [4] and [5] > > > > Using JNI you can access local machine locations but then you are duplicating much of the existing native functionality; this also adds the requirement that developers need to know C/C++ and the Windows cryptography API. > > > > Given the above I propose that we add native support for local machine KeyStore locations > > > > Users can currently access two physical key stores (in the current user location): > > > > "Windows-MY": .Default > > "Windows-ROOT": .Default.LocalMachine, .SmartCard > > > > Adding the local machine location opens up access to a further two physical key stores ? > > > > "Windows-MY": .Default > > "Windows-ROOT": .Default.AuthRoot, .GroupPolicy, .Enterprise, .SmartCard > > > > Please let me know if there are any existing efforts to bring this functionality to Java, or references to prior decisions on this subject > > > > Thanks in advance > > Mat Carter > > > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fseccrypto%2Fsystem-store-locations&data=05%7C01%7CMatthew.Carter%40microsoft.com%7C9492ccb410834f633f4708da1beb6d02%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637852995228154570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BfhJsjnkI0E4i%2Bu%2BEsoOPb0XAcspqJEx4ldXvG0N9ZM%3D&reserved=0 > > [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-6782021&data=05%7C01%7CMatthew.Carter%40microsoft.com%7C9492ccb410834f633f4708da1beb6d02%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637852995228154570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HWGFDBjvmr0z35nrGydY4HvPOEeaNIvNiFL9u4UHryw%3D&reserved=0 > > [3] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fsecurity-dev%2F2018-August%2F017832.html&data=05%7C01%7CMatthew.Carter%40microsoft.com%7C9492ccb410834f633f4708da1beb6d02%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637852995228154570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m8X1tuv%2BoGE8mJ2vUPa5lD7mNeqcwLtvJEyKfTGtUcA%3D&reserved=0 > > [4] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F70200603%2Faccessing-windows-local-machine-certificates-from-a-windows-service-written-in-j&data=05%7C01%7CMatthew.Carter%40microsoft.com%7C9492ccb410834f633f4708da1beb6d02%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637852995228154570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Pql1BXoK8ZvtwT%2FLh4YXbWJtXyQxreT8zbTJHyr%2BGq4%3D&reserved=0 > > [5] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F3612962%2Faccess-local-machine-certificate-store-in-java&data=05%7C01%7CMatthew.Carter%40microsoft.com%7C9492ccb410834f633f4708da1beb6d02%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637852995228154570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qBxR%2BSAWoewyqjgS5%2FPT3EXt%2FCx6%2F8CUQLt6IaUPQwU%3D&reserved=0 > > > > > > Sent from Outlook -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Apr 11 22:33:01 2022 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Mon, 11 Apr 2022 22:33:01 +0000 Subject: Proposal: Extend Windows KeyStore support to include access to the local machine location In-Reply-To: References: Message-ID: <61F25F5C-A740-425D-8230-DF7D865C7D5E@oracle.com> Added a comment and assigned the enhancement to you. Thanks. --Weijun > On Apr 11, 2022, at 5:02 PM, Mat Carter wrote: > > Thanks, Weijun > > Let's move ahead with the two new strings while we consider read-only access. As the current assignee can you update the JBS issue [1] with what we've agreed here. > > I have an implementation that I've been testing in 11u which can easily move to tip; if you are happy for me to make the changes then please ack here and re-assign the issue to me > > [1] https://bugs.openjdk.java.net/browse/JDK-6782021 > > > Thanks > Mat From duke at openjdk.java.net Tue Apr 12 00:34:19 2022 From: duke at openjdk.java.net (Mark Powers) Date: Tue, 12 Apr 2022 00:34:19 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss 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 ------------- Commit messages: - third iteration - Merge - Merge - Merge - second iteration - first iteration Changes: https://git.openjdk.java.net/jdk/pull/7746/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7746&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284688 Stats: 1009 lines in 73 files changed: 79 ins; 222 del; 708 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 robilad at openjdk.java.net Tue Apr 12 00:34:20 2022 From: robilad at openjdk.java.net (Dalibor Topic) Date: Tue, 12 Apr 2022 00:34:20 GMT Subject: RFR: 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 Hi, please send an e-mail to Dalibor.topic at oracle.com so that I can verify your account. ------------- PR: https://git.openjdk.java.net/jdk/pull/7746 From valeriep at openjdk.java.net Tue Apr 12 01:34:17 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 12 Apr 2022 01:34:17 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec Message-ID: This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring. The CSR will be filed once review is somewhat finished. Thanks, Valerie ------------- Commit messages: - 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec Changes: https://git.openjdk.java.net/jdk/pull/8191/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8191&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284553 Stats: 42 lines in 1 file changed: 13 ins; 10 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/8191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8191/head:pull/8191 PR: https://git.openjdk.java.net/jdk/pull/8191 From mstjohns at comcast.net Tue Apr 12 02:46:31 2022 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 11 Apr 2022 22:46:31 -0400 Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec In-Reply-To: References: Message-ID: <6c9afc60-e2fa-2309-43fb-5f511d183591@comcast.net> On 4/11/2022 9:34 PM, Valerie Peng wrote: > This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring. > > The CSR will be filed once review is somewhat finished. > > Thanks, > Valerie > > ------------- > > Commit messages: > - 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec > > Changes:https://git.openjdk.java.net/jdk/pull/8191/files > Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=8191&range=00 > Issue:https://bugs.openjdk.java.net/browse/JDK-8284553 > Stats: 42 lines in 1 file changed: 13 ins; 10 del; 19 mod > Patch:https://git.openjdk.java.net/jdk/pull/8191.diff > Fetch: git fetchhttps://git.openjdk.java.net/jdk pull/8191/head:pull/8191 > > PR:https://git.openjdk.java.net/jdk/pull/8191 Hi Valerie - I think deprecating DEFAULT? is wrong.? RFC8017 still has this definition: > RSAES-OAEP-params ::= SEQUENCE { > hashAlgorithm [0] HashAlgorithm DEFAULT sha1, > maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, > pSourceAlgorithm [2] PSourceAlgorithm DEFAULT pSpecifiedEmpty > } and DEFAULT is what you should be getting if you see an empty sequence in the param field.? It's DEFAULT in ASN1 terms, not DEFAULT in terms of what you should use going forward? to create signatures, and the ASN1 DEFAULT won't change. In any event, I can't find where RFC8017 says anything about deprecating the defaults.? AFAICT, although there's general guidance to go away from SHA1,? the math suggests that SHA1 is still sufficient for OAEP,? and there's no guidance specific to OAEP's use of SHA1 that I can find other than the requirement in NIST SP800-56B rev 2 to use "Approved Hash Functions" for OAEP. If there's a section in 8017 that you're looking at for this guidance that I missed, you may want to update your comment to point to it. Take care - Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.java.net Tue Apr 12 03:37:44 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 12 Apr 2022 03:37:44 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 15:20:22 GMT, Sean Mullan 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~ > > src/java.base/share/classes/javax/crypto/Cipher.java line 488: > >> 486: * A new {@code Cipher} object encapsulating the >> 487: * {@code CipherSpi} implementation from the first >> 488: * Provider that supports the specified algorithm is returned. > > Since "Provider" is capitalized, I think the intent was that this was the classname, so it should also probably be in an `@code` tag. Alternatively, you could change this to non-capitalized "provider" (w/o the @code tag) and I think it would still be readable (and my vote would be for this). Sure, I will use the non-capitalized "provider" whenever suitable. For some cases, there are "provider" argument, so it looks that {@code provider} is more suitable. > src/java.base/share/classes/javax/crypto/Cipher.java line 655: > >> 653: * >> 654: *

A new {@code Cipher} object encapsulating the >> 655: * {@code CipherSpi} implementation from the specified Provider > > Since `Provider` here is a parameter, it is probably better to put this in an `@code` tag. Yes, I will use the {@code provider} for the "provider" parameter. > src/java.base/share/classes/javax/crypto/Cipher.java line 2641: > >> 2639: * >> 2640: * @param transformation the cipher transformation >> 2641: * @return the maximum key length in bits or Integer.MAX_VALUE > > Integer.MAX_VALUE should be inside a `@code` tag. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From valeriep at openjdk.java.net Tue Apr 12 03:37:44 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 12 Apr 2022 03:37:44 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 19:41:28 GMT, Xue-Lei Andrew Fan wrote: >> Can you be more specific like which block of code that you are referring to as the filtering and modification? >> I'd expect the intention is to use the parameter specified. Otherwise an exception should be thrown if the specified parameter is invalid. Only when no parameter is specified, the provider would try to generate the parameters using whatever values it has or got. > > I read the following methods in com.sun.crypto.provider.CipherCore: > > void init(int opmode, Key key, AlgorithmParameterSpec params, > SecureRandom random) > > where the 'params' are converted to IV byte array for further processing. > > > void init(int opmode, Key key, AlgorithmParameters params, > SecureRandom random) > > where the spec is retrieved from the 'params', and then pass the call to the init() method above. > > > AlgorithmParameters getParameters(String algName) { > > where the returned parameters are re-constructed. > > It may be fine to use a strict spec, but there is a chance to have compatibility impact unless we check the implementation carefully. It may not worthy the risks as a behavioral update may be not necessary for developers. How about this then? *

The returned parameters may be the same that were used to initialize * this cipher, or may contain additional default and random parameter * values used by the underlying cipher implementation if this * cipher can successfully generate the required parameter values when * not supplied. Otherwise, {@code null} is returned. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From valeriep at openjdk.java.net Tue Apr 12 03:37:44 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 12 Apr 2022 03:37:44 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() In-Reply-To: <17UlP2PIZ3DEMjUNy95_mJ0HteRN3g3CP3rBSbfpYN4=.dfc6c034-46d3-4293-ae0d-2d459d0c1ce6@github.com> References: <17UlP2PIZ3DEMjUNy95_mJ0HteRN3g3CP3rBSbfpYN4=.dfc6c034-46d3-4293-ae0d-2d459d0c1ce6@github.com> Message-ID: On Wed, 6 Apr 2022 19:48:04 GMT, Valerie Peng wrote: >> src/java.base/share/classes/javax/crypto/Cipher.java line 1053: >> >>> 1051: *

If this cipher has been previously initialized with parameters, >>> 1052: * this method returns the same parameters. Otherwise, this method may >>> 1053: * return a combination of user-supplied, default and randomly generated >> >>> ... a combination of user-supplied, default and randomly generated parameter values ... >> >> Other than init(), which APIs could impact the user-supplied parameters? Is it the getInstance()? >> >> Is it OK to just use the provider-specific default values instead, by replacing the "a combination of user-supplied, default and randomly generated ..."? > > I am thinking just init() as it takes parameters. > Let me take a second look at various Cipher algorithm implementations and see if this can be further pared down. Please see the updated wording in earlier comment above. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From djelinski at openjdk.java.net Tue Apr 12 13:10:16 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Apr 2022 13:10:16 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice Message-ID: During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. ------------- Commit messages: - Fix file attributes - Fix file attributes - Avoid wrapping default constraints - Add handshake bench Changes: https://git.openjdk.java.net/jdk/pull/8199/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8199&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284694 Stats: 337 lines in 4 files changed: 336 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8199.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8199/head:pull/8199 PR: https://git.openjdk.java.net/jdk/pull/8199 From djelinski at openjdk.java.net Tue Apr 12 13:10:17 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Apr 2022 13:10:17 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice In-Reply-To: References: Message-ID: <3raQ_ZqRPpuDGee8nUOM3yXDrh2fWXrUkYDfRaoVtdc=.75e5ebb9-d235-4519-abdf-b7d920cc7f23@github.com> On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeli?ski wrote: > During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. > > This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. Results of the attached benchmark: Before: Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake true TLSv1.2 thrpt 5 1407.320 ? 302.562 ops/s SSLHandshake.doHandshake true TLS thrpt 5 391.037 ? 13.014 ops/s SSLHandshake.doHandshake false TLSv1.2 thrpt 5 280.003 ? 69.273 ops/s SSLHandshake.doHandshake false TLS thrpt 5 233.401 ? 9.371 ops/s After: Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake true TLSv1.2 thrpt 5 2267.325 ? 119.800 ops/s SSLHandshake.doHandshake true TLS thrpt 5 490.465 ? 24.698 ops/s SSLHandshake.doHandshake false TLSv1.2 thrpt 5 340.275 ? 72.833 ops/s SSLHandshake.doHandshake false TLS thrpt 5 271.656 ? 5.444 ops/s The results show a nice double-digit improvement across the board. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From redestad at openjdk.java.net Tue Apr 12 13:41:39 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 12 Apr 2022 13:41:39 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeli?ski wrote: > During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. > > This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 73: > 71: > 72: static AlgorithmConstraints wrap(AlgorithmConstraints userSpecifiedConstraints) { > 73: if (userSpecifiedConstraints == DEFAULT) { Just thinking out loud: It seems all this does when `userSpecifiedConstraints` is a `SSLAlgorithmConstraints` is force the `enableX509..` flag to `true`. So in addition to the obvious thing for `DEFAULT`, you could also return `DEFAULT` for `DEFAULT_SSL_ONLY`. Or more generally: if `userSpecifiedConstraints instanceof SSLAlgorithmConstraints` then you could either return `userSpecifiedConstraints` as-is if `enabledX509DisabledAlgConstraints` is `true` or else return a clone of it with `enabledX509DisabledAlgConstraints` set to `true`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From mullan at openjdk.java.net Tue Apr 12 14:40:42 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 12 Apr 2022 14:40:42 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec In-Reply-To: <6c9afc60-e2fa-2309-43fb-5f511d183591@comcast.net> References: <6c9afc60-e2fa-2309-43fb-5f511d183591@comcast.net> Message-ID: On Tue, 12 Apr 2022 02:48:51 GMT, Michael StJohns wrote: > I think deprecating DEFAULT? is wrong.? RFC8017 still has this definition: > > > RSAES-OAEP-params ::= SEQUENCE { > > hashAlgorithm [0] HashAlgorithm DEFAULT sha1, > > maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, > > pSourceAlgorithm [2] PSourceAlgorithm DEFAULT pSpecifiedEmpty > > } > > and DEFAULT is what you should be getting if you see an empty sequence in the param field.? It's DEFAULT in ASN1 terms, not DEFAULT in terms of what you should use going forward? to create signatures, and the ASN1 DEFAULT won't change. > > In any event, I can't find where RFC8017 says anything about deprecating the defaults.? AFAICT, although there's general guidance to go away from SHA1,? the math suggests that SHA1 is still sufficient for OAEP,? and there's no guidance specific to OAEP's use of SHA1 that I can find other than the requirement in NIST SP800-56B rev 2 to use "Approved Hash Functions" for OAEP. If there's a section in 8017 that you're looking at for this guidance that I missed, you may want to update your comment to point to it. [https://www.rfc-editor.org/rfc/rfc8017#appendix-A.2.1](https://www.rfc-editor.org/rfc/rfc8017#appendix-A.2.1) (which defines the OAEP-params structure) says: > o hashAlgorithm identifies the hash function. It SHALL be an > algorithm ID with an OID in the set OAEP-PSSDigestAlgorithms. For > a discussion of supported hash functions, see [Appendix B.1](https://www.rfc-editor.org/rfc/rfc8017#appendix-B.1). [https://www.rfc-editor.org/rfc/rfc8017#appendix-B.1](https://www.rfc-editor.org/rfc/rfc8017#appendix-B.1) is a long section discussing hash functions, but I think this text (last two paragraphs) is most relevant: > There have also been advances in the cryptanalysis of SHA-1. > Particularly, the results of Wang et al. [[SHA1CRYPT](https://www.rfc-editor.org/rfc/rfc8017#ref-SHA1CRYPT)] (which have > been independently verified by M. Cochran in his analysis [[COCHRAN](https://www.rfc-editor.org/rfc/rfc8017#ref-COCHRAN)]) > on using a differential path to find collisions in SHA-1, which > conclude that the security strength of the SHA-1 hashing algorithm is > significantly reduced. However, this reduction is not significant > enough to warrant the removal of SHA-1 from existing applications, > but its usage is only recommended for backwards-compatibility > reasons. > > To address these concerns, only SHA-224, SHA-256, SHA-384, SHA-512, > SHA-512/224, and SHA-512/256 are RECOMMENDED for new applications. > As of today, the best (known) collision attacks against these hash > functions are generic attacks with complexity 2L/2, where L is the > bit length of the hash output. For the signature schemes in this > document, a collision attack is easily translated into a signature > forgery. Therefore, the value L / 2 should be at least equal to the > desired security level in bits of the signature scheme (a security > level of B bits means that the best attack has complexity 2B). The > same rule of thumb can be applied to RSAES-OAEP; it is RECOMMENDED > that the bit length of the seed (which is equal to the bit length of > the hash output) be twice the desired security level in bits. Also, this is a proposed deprecation ... there is no plan to remove this field. The main intention of this deprecation is to alert users that SHA-1 is being used as it may not be apparent from the "DEFAULT" name, and to make sure that is ok or to think about using something stronger. @valeriepeng I recommend making the link more specific in the deprecation text to point to https://www.rfc-editor.org/rfc/rfc8017#appendix-B.1 ------------- PR: https://git.openjdk.java.net/jdk/pull/8191 From anthony.scarpino at oracle.com Tue Apr 12 15:10:56 2022 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 12 Apr 2022 08:10:56 -0700 Subject: Java Cryptographic Extension Survey Message-ID: Hello, Java Cryptographic Extension (JCE) has been in Java SE for a long time and has made incremental changes over the years. Looking forward, we would like to know more about how projects are using JCE and what changes, features, and API enhancements would be helpful for your projects. Below is a survey that we hope you can spend 5 minutes to fill out. If you have written or maintain code that uses the JCE API, then we would appreciate if you would complete this survey: https://www.questionpro.com/t/AUzP7ZrFWv The survey will be open through April 29. Thank you, Anthony Scarpino OpenJDK Security Group https://openjdk.java.net/groups/security/ From djelinski at openjdk.java.net Tue Apr 12 15:22:33 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Apr 2022 15:22:33 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice In-Reply-To: References: Message-ID: <1ETKOC7N3QlHppcNAWhNBin56e7xRXeAAbEPoTeJPpU=.4f8566fe-6d08-44b0-a2b0-8a1e71846fe8@github.com> On Tue, 12 Apr 2022 13:38:17 GMT, Claes Redestad wrote: >> During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. >> >> This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. > > src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 73: > >> 71: >> 72: static AlgorithmConstraints wrap(AlgorithmConstraints userSpecifiedConstraints) { >> 73: if (userSpecifiedConstraints == DEFAULT) { > > Just thinking out loud: It seems all this does when `userSpecifiedConstraints` is a `SSLAlgorithmConstraints` is force the `enableX509..` flag to `true`. So in addition to the obvious thing for `DEFAULT`, you could also return `DEFAULT` for `DEFAULT_SSL_ONLY`. Or more generally: if `userSpecifiedConstraints instanceof SSLAlgorithmConstraints` then you could either return `userSpecifiedConstraints` as-is if `enabledX509DisabledAlgConstraints` is `true` or else return a clone of it with `enabledX509DisabledAlgConstraints` set to `true`. While this is technically true, `SSLAlgorithmConstraints` is an internal class, so it's very unlikely that we will ever get `SSLAlgorithmConstraints` other than `DEFAULT` here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From redestad at openjdk.java.net Tue Apr 12 15:44:33 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 12 Apr 2022 15:44:33 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeli?ski wrote: > During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. > > This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From redestad at openjdk.java.net Tue Apr 12 15:44:34 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 12 Apr 2022 15:44:34 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice In-Reply-To: <1ETKOC7N3QlHppcNAWhNBin56e7xRXeAAbEPoTeJPpU=.4f8566fe-6d08-44b0-a2b0-8a1e71846fe8@github.com> References: <1ETKOC7N3QlHppcNAWhNBin56e7xRXeAAbEPoTeJPpU=.4f8566fe-6d08-44b0-a2b0-8a1e71846fe8@github.com> Message-ID: On Tue, 12 Apr 2022 15:19:41 GMT, Daniel Jeli?ski wrote: >> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 73: >> >>> 71: >>> 72: static AlgorithmConstraints wrap(AlgorithmConstraints userSpecifiedConstraints) { >>> 73: if (userSpecifiedConstraints == DEFAULT) { >> >> Just thinking out loud: It seems all this does when `userSpecifiedConstraints` is a `SSLAlgorithmConstraints` is force the `enableX509..` flag to `true`. So in addition to the obvious thing for `DEFAULT`, you could also return `DEFAULT` for `DEFAULT_SSL_ONLY`. Or more generally: if `userSpecifiedConstraints instanceof SSLAlgorithmConstraints` then you could either return `userSpecifiedConstraints` as-is if `enabledX509DisabledAlgConstraints` is `true` or else return a clone of it with `enabledX509DisabledAlgConstraints` set to `true`. > > While this is technically true, `SSLAlgorithmConstraints` is an internal class, so it's very unlikely that we will ever get `SSLAlgorithmConstraints` other than `DEFAULT` here. Right, I see even `DEFAULT_SSL_ONLY` is only used statically in one place. So the patch is probably good enough. Out of scope here, but if these permits-calls are (somewhat) performance-sensitive and the `DEFAULT` object is likely the only instance of `SSLAlgorithmConstraints` we'll ever see then perhaps it should be a specialized implementation that avoid the always-null `userSpecifiedConstraints != null` and `peerSpecifiedConstraints != null` checks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From wetmore at openjdk.java.net Tue Apr 12 16:17:36 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 12 Apr 2022 16:17:36 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeli?ski wrote: > During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. > > This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. Please make sure @XueleiFan has a chance to look at this before integrating. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From duke at openjdk.java.net Tue Apr 12 17:14:57 2022 From: duke at openjdk.java.net (Mat Carter) Date: Tue, 12 Apr 2022 17:14:57 GMT Subject: RFR: 6782021: add support for localmachine keystores on windows Message-ID: <66ocRhW_xiTC9A6PSduPoXElwl0FR94xvjYs5cda0To=.9ede24f2-5e20-463c-97f7-ddfa96c12935@github.com> 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 ------------- Commit messages: - 6782021: add support for localmachine keystores on windows Changes: https://git.openjdk.java.net/jdk/pull/8210/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8210&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6782021 Stats: 79 lines in 4 files changed: 66 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8210.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8210/head:pull/8210 PR: https://git.openjdk.java.net/jdk/pull/8210 From djelinski at openjdk.java.net Tue Apr 12 18:29:43 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Apr 2022 18:29:43 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice In-Reply-To: References: <1ETKOC7N3QlHppcNAWhNBin56e7xRXeAAbEPoTeJPpU=.4f8566fe-6d08-44b0-a2b0-8a1e71846fe8@github.com> Message-ID: On Tue, 12 Apr 2022 15:40:46 GMT, Claes Redestad wrote: >> While this is technically true, `SSLAlgorithmConstraints` is an internal class, so it's very unlikely that we will ever get `SSLAlgorithmConstraints` other than `DEFAULT` here. > > Right, I see even `DEFAULT_SSL_ONLY` is only used statically in one place. > > So the patch is probably good enough. Out of scope here, but if these permits-calls are (somewhat) performance-sensitive and the `DEFAULT` object is likely the only instance of `SSLAlgorithmConstraints` we'll ever see then perhaps it should be a specialized implementation that avoid the always-null `userSpecifiedConstraints != null` and `peerSpecifiedConstraints != null` checks. Thanks for reviewing! These permits calls are generally performing sufficiently well; the problem is that they in turn end up calling [AlgorithmDecomposer#decomposeImpl](https://github.com/openjdk/jdk/blob/36b59f3814fdaa44c9c04a0e8d63d0ba56929326/src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java#L53), which performs string splitting using a [pattern with negative look-behind](https://github.com/openjdk/jdk/blob/36b59f3814fdaa44c9c04a0e8d63d0ba56929326/src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java#L43), which is pretty slow. But that's another story. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From duke at openjdk.java.net Tue Apr 12 19:01:32 2022 From: duke at openjdk.java.net (Mat Carter) Date: Tue, 12 Apr 2022 19:01:32 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v2] In-Reply-To: <66ocRhW_xiTC9A6PSduPoXElwl0FR94xvjYs5cda0To=.9ede24f2-5e20-463c-97f7-ddfa96c12935@github.com> References: <66ocRhW_xiTC9A6PSduPoXElwl0FR94xvjYs5cda0To=.9ede24f2-5e20-463c-97f7-ddfa96c12935@github.com> 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 refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8210/files - new: https://git.openjdk.java.net/jdk/pull/8210/files/91d58f38..4e165f66 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8210&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8210&range=00-01 Stats: 79 lines in 4 files changed: 0 ins; 66 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8210.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8210/head:pull/8210 PR: https://git.openjdk.java.net/jdk/pull/8210 From duke at openjdk.java.net Tue Apr 12 19:01:32 2022 From: duke at openjdk.java.net (Mat Carter) Date: Tue, 12 Apr 2022 19:01:32 GMT Subject: Withdrawn: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider In-Reply-To: <66ocRhW_xiTC9A6PSduPoXElwl0FR94xvjYs5cda0To=.9ede24f2-5e20-463c-97f7-ddfa96c12935@github.com> References: <66ocRhW_xiTC9A6PSduPoXElwl0FR94xvjYs5cda0To=.9ede24f2-5e20-463c-97f7-ddfa96c12935@github.com> Message-ID: On Tue, 12 Apr 2022 16:55:28 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 been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8210 From duke at openjdk.java.net Tue Apr 12 19:12:18 2022 From: duke at openjdk.java.net (Mat Carter) Date: Tue, 12 Apr 2022 19:12:18 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider 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 ------------- Commit messages: - 6782021: add support for localmachine keystores on windows Changes: https://git.openjdk.java.net/jdk/pull/8211/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8211&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6782021 Stats: 79 lines in 4 files changed: 66 ins; 0 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 Matthew.Carter at microsoft.com Tue Apr 12 21:37:11 2022 From: Matthew.Carter at microsoft.com (Mat Carter) Date: Tue, 12 Apr 2022 21:37:11 +0000 Subject: Proposal: Extend Windows KeyStore support to include access to the local machine location In-Reply-To: <61F25F5C-A740-425D-8230-DF7D865C7D5E@oracle.com> References: <61F25F5C-A740-425D-8230-DF7D865C7D5E@oracle.com> Message-ID: Weijun Here's a PR [1] if you would like to review and consider sponsoring [1] https://github.com/openjdk/jdk/pull/8211 Cheers Mat Sent from Outlook ________________________________ From: Wei-Jun Wang Sent: Monday, April 11, 2022 3:33 PM To: Mat Carter Cc: Bernd Eckenfels ; security-dev at openjdk.java.net Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location Added a comment and assigned the enhancement to you. Thanks. --Weijun > On Apr 11, 2022, at 5:02 PM, Mat Carter wrote: > > Thanks, Weijun > > Let's move ahead with the two new strings while we consider read-only access. As the current assignee can you update the JBS issue [1] with what we've agreed here. > > I have an implementation that I've been testing in 11u which can easily move to tip; if you are happy for me to make the changes then please ack here and re-assign the issue to me > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-6782021&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Cf46a1e0bd128483c980f08da1c0b40e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637853131938100906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FcdLRJAf8TyNNQjc7Pw9vDBnLNBZ%2BhIjQ17MDMPUqIg%3D&reserved=0 > > > Thanks > Mat -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Apr 12 21:58:43 2022 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Tue, 12 Apr 2022 21:58:43 +0000 Subject: Proposal: Extend Windows KeyStore support to include access to the local machine location In-Reply-To: References: <61F25F5C-A740-425D-8230-DF7D865C7D5E@oracle.com> Message-ID: <1461B4B9-BEA4-428E-8BE7-9AB39957E52C@oracle.com> No problem. The code change looks fine to me but you will need to create a CSR. I'll add a comment in the PR. Thanks, Weijun > On Apr 12, 2022, at 5:37 PM, Mat Carter wrote: > > Weijun > > Here's a PR [1] if you would like to review and consider sponsoring > > [1] https://github.com/openjdk/jdk/pull/8211 > > > Cheers > Mat > > Sent from Outlook > From: Wei-Jun Wang > Sent: Monday, April 11, 2022 3:33 PM > To: Mat Carter > Cc: Bernd Eckenfels ; security-dev at openjdk.java.net > Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location > > Added a comment and assigned the enhancement to you. Thanks. > > --Weijun > > > On Apr 11, 2022, at 5:02 PM, Mat Carter wrote: > > > > Thanks, Weijun > > > > Let's move ahead with the two new strings while we consider read-only access. As the current assignee can you update the JBS issue [1] with what we've agreed here. > > > > I have an implementation that I've been testing in 11u which can easily move to tip; if you are happy for me to make the changes then please ack here and re-assign the issue to me > > > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-6782021&data=05%7C01%7CMatthew.Carter%40microsoft.com%7Cf46a1e0bd128483c980f08da1c0b40e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637853131938100906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FcdLRJAf8TyNNQjc7Pw9vDBnLNBZ%2BhIjQ17MDMPUqIg%3D&reserved=0 > > > > > > Thanks > > Mat > From weijun at openjdk.java.net Tue Apr 12 22:13:08 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 12 Apr 2022 22:13:08 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 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 Thanks a lot for the quick contribution! I'll definitely be happy to sponsor it. Since new keystore types are created, this needs a CSR. Go to https://bugs.openjdk.java.net/browse/JDK-6782021, click "More" and at the end there is a "Create CSR". Basically you talk about what these new keystores are and why they are useful. The scope is JDK and I assume the compatibility risk is low. There is no spec change but you can suggest new entries in the "JDK Providers Documentation" (https://docs.oracle.com/en/java/javase/18/security/oracle-providers.html#GUID-4F1737D6-1569-4340-B140-678C70E63CD5). You can also add a label like `noreg-other` to the bug and add a comment explaining what manual tests can be added, how to run it, and what the expected output is. ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Wed Apr 13 00:25:10 2022 From: duke at openjdk.java.net (Mark Powers) Date: Wed, 13 Apr 2022 00:25:10 GMT Subject: RFR: JDK-8284112 Minor cleanup could be done in javax.crypto Message-ID: JDK-8284112 Minor cleanup could be done in javax.crypto ------------- Commit messages: - second iteration - Merge - first iteration Changes: https://git.openjdk.java.net/jdk/pull/8214/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8214&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284112 Stats: 300 lines in 37 files changed: 9 ins; 79 del; 212 mod Patch: https://git.openjdk.java.net/jdk/pull/8214.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8214/head:pull/8214 PR: https://git.openjdk.java.net/jdk/pull/8214 From jjiang at openjdk.java.net Wed Apr 13 05:18:43 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Wed, 13 Apr 2022 05:18:43 GMT Subject: RFR: 8284796: sun.security.ssl.Finished::toString misses a line feed in the message format pattern Message-ID: The log for Finished message looks like the below, "Finished": { "verify data": { 0000: ... ... }'} // looks weird because a line feed is missing in the format pattern. ""Finished": '{'\n" + " "verify data": '{'\n" + "{0}\n" + " '}'" + // a line feed is needed "'}'", ------------- Commit messages: - 8284796: sun.security.ssl.Finished::toString misses a line feed in the message format pattern Changes: https://git.openjdk.java.net/jdk/pull/8215/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8215&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284796 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8215.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8215/head:pull/8215 PR: https://git.openjdk.java.net/jdk/pull/8215 From wetmore at openjdk.java.net Wed Apr 13 05:35:20 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 13 Apr 2022 05:35:20 GMT Subject: RFR: JDK-8284112 Minor cleanup could be done in javax.crypto In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 21:59:09 GMT, Mark Powers wrote: > JDK-8284112 Minor cleanup could be done in javax.crypto src/java.base/share/classes/javax/crypto/CryptoPermission.java line 437: > 435: // may be the best try. > 436: return this.algParamSpec.equals(algParamSpec); > 437: } else return !this.checkParam; Please use the standard coding format. } else { return !this.checkParam; } or } return !this.checkParam; ------------- PR: https://git.openjdk.java.net/jdk/pull/8214 From wetmore at openjdk.java.net Wed Apr 13 05:42:14 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 13 Apr 2022 05:42:14 GMT Subject: RFR: JDK-8284112 Minor cleanup could be done in javax.crypto In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 21:59:09 GMT, Mark Powers wrote: > JDK-8284112 Minor cleanup could be done in javax.crypto Can you file a bug to update the javax.crypto files to use proper javadoc for mentioned classes, e.g. < code> tags. src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 158: > 156: > 157: /** > 158: * Checks if this object's PermissionCollection for permissions Just FYI and not for this review, but this class should really be updated to use proper javadoc comment style, which is to tag all objects with < code >PermissionCollection< /code > ------------- PR: https://git.openjdk.java.net/jdk/pull/8214 From wetmore at openjdk.java.net Wed Apr 13 06:07:11 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 13 Apr 2022 06:07:11 GMT Subject: RFR: JDK-8284112 Minor cleanup could be done in javax.crypto In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 21:59:09 GMT, Mark Powers wrote: > JDK-8284112 Minor cleanup could be done in javax.crypto src/java.base/share/classes/javax/crypto/ExemptionMechanism.java line 142: > 140: * @see java.security.Provider > 141: */ > 142: public static ExemptionMechanism getInstance(String algorithm) Others might disagree with this comment, but I would encourage you not to make these changes throughout your PR. (@jddarcy ?) Even though a static method is implicitly final and IJ is correct, the final keyword does prevent subclasses from inadvertently using the same method signature. ------------- PR: https://git.openjdk.java.net/jdk/pull/8214 From xuelei at openjdk.java.net Wed Apr 13 06:11:12 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 13 Apr 2022 06:11:12 GMT Subject: RFR: 8284796: sun.security.ssl.Finished::toString misses a line feed in the message format pattern In-Reply-To: References: Message-ID: <5DZjwMadg9XcuRvup3GaB-fCdSkAY6IkATvXt4Gw2is=.3e7245c3-d7f3-4018-8db1-1b34e02e8840@github.com> On Wed, 13 Apr 2022 05:10:22 GMT, John Jiang wrote: > The log for Finished message looks like the below, > > "Finished": { > "verify data": { > 0000: ... ... > }'} // looks weird > > because a line feed is missing in the format pattern. > > ""Finished": '{'\n" + > " "verify data": '{'\n" + > "{0}\n" + > " '}'" + // a line feed is needed > "'}'", src/java.base/share/classes/sun/security/ssl/Finished.java line 150: > 148: "{0}\n" + > 149: " '}'\n" + > 150: "'}'", As you are already here to touch the code, would you like to use text block instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/8215 From wetmore at openjdk.java.net Wed Apr 13 06:23:20 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 13 Apr 2022 06:23:20 GMT Subject: RFR: JDK-8284112 Minor cleanup could be done in javax.crypto In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 21:59:09 GMT, Mark Powers wrote: > JDK-8284112 Minor cleanup could be done in javax.crypto src/java.base/share/classes/javax/crypto/SealedObject.java line 449: > 447: final class extObjectInputStream extends ObjectInputStream { > 448: extObjectInputStream(InputStream in) > 449: throws IOException { This is another "I probably wouldn't do that..." It's nice to know what kind of IOExceptions you might get, so leaving StreamCorruptedException is ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/8214 From wetmore at openjdk.java.net Wed Apr 13 06:28:11 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 13 Apr 2022 06:28:11 GMT Subject: RFR: JDK-8284112 Minor cleanup could be done in javax.crypto In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 21:59:09 GMT, Mark Powers wrote: > JDK-8284112 Minor cleanup could be done in javax.crypto src/java.base/share/classes/javax/crypto/spec/DESKeySpec.java line 49: > 47: * Weak/semi-weak keys copied from FIPS 74. > 48: * > 49: * "...The first 6 keys have duals different from themselves, hence Suggest you leave this alone as this is a direct quote from FIPS 74 (page 10). ------------- PR: https://git.openjdk.java.net/jdk/pull/8214 From wetmore at openjdk.java.net Wed Apr 13 06:37:06 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 13 Apr 2022 06:37:06 GMT Subject: RFR: JDK-8284112 Minor cleanup could be done in javax.crypto In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 21:59:09 GMT, Mark Powers wrote: > JDK-8284112 Minor cleanup could be done in javax.crypto src/java.base/share/classes/javax/crypto/CipherInputStream.java line 159: > 157: try { > 158: ofinish = cipher.update(ibuffer, 0, readin, obuffer, ostart); > 159: } catch (IllegalStateException e) { This is another one of those I would probably leave alone, just so it's clear what should be done. src/java.base/share/classes/javax/crypto/CipherSpi.java line 29: > 27: > 28: import java.nio.ByteBuffer; > 29: import java.security.*; This is another one that some people will complain about. I personally prefer this style, others prefer everything written out as long as it's not "too many." ------------- PR: https://git.openjdk.java.net/jdk/pull/8214 From xuelei at openjdk.java.net Wed Apr 13 06:50:14 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 13 Apr 2022 06:50:14 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice In-Reply-To: References: Message-ID: <-1bnefBpuQA1cHNaN93ULwBskNsIU49tYw6sUE9a_TI=.e7ef496c-d6a0-4f3c-900f-5f817b77c5cf@github.com> On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeli?ski wrote: > During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. > > This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. Nice catch. Thank you! src/java.base/share/classes/sun/security/ssl/HandshakeContext.java line 167: > 165: this.sslConfig = (SSLConfiguration)conContext.sslConfig.clone(); > 166: > 167: this.algorithmConstraints = SSLAlgorithmConstraints.wrap( Maybe, the change could be placed in the SSLAlgorithmConstraints constructors implementation so that it is easier to avoid this mistake. src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 72: > 70: } > 71: > 72: static AlgorithmConstraints wrap(AlgorithmConstraints userSpecifiedConstraints) { I may update all of the constructors so that the accumulation of the reference of userSpecifiedConstraints could be avoid further. - this.userSpecifiedConstraints = userSpecifiedConstraints; + this.userSpecifiedConstraints = userSpecifiedConstraints == DEFAULT ? + null : userSpecifiedConstraints; Similar update could be placed in the getUserSpecifiedConstraints() implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From xuelei at openjdk.java.net Wed Apr 13 07:04:16 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 13 Apr 2022 07:04:16 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 03:27:59 GMT, Valerie Peng wrote: >> I read the following methods in com.sun.crypto.provider.CipherCore: >> >> void init(int opmode, Key key, AlgorithmParameterSpec params, >> SecureRandom random) >> >> where the 'params' are converted to IV byte array for further processing. >> >> >> void init(int opmode, Key key, AlgorithmParameters params, >> SecureRandom random) >> >> where the spec is retrieved from the 'params', and then pass the call to the init() method above. >> >> >> AlgorithmParameters getParameters(String algName) { >> >> where the returned parameters are re-constructed. >> >> It may be fine to use a strict spec, but there is a chance to have compatibility impact unless we check the implementation carefully. It may not worthy the risks as a behavioral update may be not necessary for developers. > > How about this then? > > *

The returned parameters may be the same that were used to initialize > * this cipher, or may contain additional default and random parameter > * values used by the underlying cipher implementation if this > * cipher can successfully generate the required parameter values when > * not supplied. Otherwise, {@code null} is returned. I like the revised spec more. BTW, for "... contain additional default and random parameter values ...", is "or" more common than "and" in English? ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From jjiang at openjdk.java.net Wed Apr 13 07:17:19 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Wed, 13 Apr 2022 07:17:19 GMT Subject: RFR: 8284796: sun.security.ssl.Finished::toString misses a line feed in the message format pattern In-Reply-To: <5DZjwMadg9XcuRvup3GaB-fCdSkAY6IkATvXt4Gw2is=.3e7245c3-d7f3-4018-8db1-1b34e02e8840@github.com> References: <5DZjwMadg9XcuRvup3GaB-fCdSkAY6IkATvXt4Gw2is=.3e7245c3-d7f3-4018-8db1-1b34e02e8840@github.com> Message-ID: On Wed, 13 Apr 2022 06:07:43 GMT, Xue-Lei Andrew Fan wrote: >> The log for Finished message looks like the below, >> >> "Finished": { >> "verify data": { >> 0000: ... ... >> }'} // looks weird >> >> because a line feed is missing in the format pattern. >> >> ""Finished": '{'\n" + >> " "verify data": '{'\n" + >> "{0}\n" + >> " '}'" + // a line feed is needed >> "'}'", > > src/java.base/share/classes/sun/security/ssl/Finished.java line 150: > >> 148: "{0}\n" + >> 149: " '}'\n" + >> 150: "'}'", > > As you are already here to touch the code, would you like to use text block instead? Could I not change this style? Maybe another PR should be filed for applying text block feature in sun.security.ssl package. ------------- PR: https://git.openjdk.java.net/jdk/pull/8215 From djelinski at openjdk.java.net Wed Apr 13 07:54:14 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 13 Apr 2022 07:54:14 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice In-Reply-To: <-1bnefBpuQA1cHNaN93ULwBskNsIU49tYw6sUE9a_TI=.e7ef496c-d6a0-4f3c-900f-5f817b77c5cf@github.com> References: <-1bnefBpuQA1cHNaN93ULwBskNsIU49tYw6sUE9a_TI=.e7ef496c-d6a0-4f3c-900f-5f817b77c5cf@github.com> Message-ID: On Wed, 13 Apr 2022 06:45:20 GMT, Xue-Lei Andrew Fan wrote: >> During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. >> >> This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. > > src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 72: > >> 70: } >> 71: >> 72: static AlgorithmConstraints wrap(AlgorithmConstraints userSpecifiedConstraints) { > > I may update all of the constructors so that the accumulation of the reference of userSpecifiedConstraints could be avoid further. > > > - this.userSpecifiedConstraints = userSpecifiedConstraints; > + this.userSpecifiedConstraints = userSpecifiedConstraints == DEFAULT ? > + null : userSpecifiedConstraints; > > > > Similar update could be placed in the getUserSpecifiedConstraints() implementation. Thanks @XueleiFan for the review! If we do that, this will result in a behavior change for cases where `enabledX509DisabledAlgConstraints` = false; is that okay? Or should we set `enabledX509DisabledAlgConstraints` = true if `userSpecifiedConstraints == DEFAULT`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From redestad at openjdk.java.net Wed Apr 13 08:22:14 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 13 Apr 2022 08:22:14 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeli?ski wrote: > During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. > > This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. test/micro/org/openjdk/bench/java/security/SSLHandshake.java line 54: > 52: @OutputTimeUnit(TimeUnit.SECONDS) > 53: @State(Scope.Benchmark) > 54: public class SSLHandshake { Default number of iterations and forks is usually excessive, I suggest some tuning runs to minimize benchmark execution time, e.g., something like: @Warmup(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS) @Measurement(iterations = 5, time = 1000, timeUnit = TimeUnit.MILLISECONDS) @Fork(3) ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From coffeys at openjdk.java.net Wed Apr 13 09:03:15 2022 From: coffeys at openjdk.java.net (Sean Coffey) Date: Wed, 13 Apr 2022 09:03:15 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeli?ski wrote: > During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. > > This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. Nice work. I've been looking at this area myself in recent weeks also while debugging some JDK 11u performance issues. JFR shows this area as costly. Some other JDK fixes in this area have already improved performance. This will certainly help. Pasting a stacktrace[1] from an old Oracle JDK 11.0.12 report for history purposes. I think there are other improvements that can be made in the TLS constraints code. Caching the last known values from a constraints permits test is something I've begun looking into. [1] Stack Trace Count Percentage boolean java.lang.StringLatin1.regionMatchesCI(byte[], int, byte[], int, int) 1637 100?% boolean java.lang.String.regionMatches(boolean, int, String, int, int) 1637 100?% boolean java.lang.String.equalsIgnoreCase(String) 1637 100?% boolean sun.security.util.AbstractAlgorithmConstraints.checkAlgorithm(List, String, AlgorithmDecomposer) 1631 99.6?% boolean sun.security.util.DisabledAlgorithmConstraints.permits(Set, String, AlgorithmParameters) 1631 99.6?% boolean sun.security.ssl.SSLAlgorithmConstraints.permits(Set, String, AlgorithmParameters) 1631 99.6?% boolean sun.security.ssl.SSLAlgorithmConstraints.permits(Set, String, AlgorithmParameters) 836 51.1?% boolean sun.security.ssl.HandshakeContext.isActivatable(CipherSuite, AlgorithmConstraints, Map) 428 26.1?% List sun.security.ssl.HandshakeContext.getActiveCipherSuites(List, List, AlgorithmConstraints) 418 25.5?% void sun.security.ssl.HandshakeContext.(SSLContextImpl, TransportContext) 418 25.5?% void sun.security.ssl.ClientHandshakeContext.(SSLContextImpl, TransportContext) 418 25.5?% void sun.security.ssl.TransportContext.kickstart() 418 25.5?% void sun.security.ssl.SSLSocketImpl.startHandshake(boolean) 418 25.5?% void sun.security.ssl.SSLSocketImpl.startHandshake() 418 25.5?% ------------- Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8199 From mullan at openjdk.java.net Wed Apr 13 15:39:19 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 13 Apr 2022 15:39:19 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec In-Reply-To: References: Message-ID: <5E98i8Wqd6lh6rYAfUT2wvy78C5X-Who_TGDjVbjGtA=.1e56702d-04d5-4959-9935-c4e942013ceb@github.com> On Tue, 12 Apr 2022 01:27:35 GMT, Valerie Peng wrote: > This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring. > > The CSR will be filed once review is somewhat finished. > > Thanks, > Valerie src/java.base/share/classes/javax/crypto/spec/OAEPParameterSpec.java line 81: > 79: * parameters for mgf -- MGF1ParameterSpec.SHA1 > 80: * source of encoding input -- PSource.PSpecified.DEFAULT > 81: * I think you should leave these lines in, so users can still see what the default parameters are. Nit, change: "the OAEPParameterSpec.DEFAULT uses the following" to: "{@code OAEPParameterSpec.DEFAULT} uses the following default values:" ------------- PR: https://git.openjdk.java.net/jdk/pull/8191 From xuelei at openjdk.java.net Wed Apr 13 16:06:23 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 13 Apr 2022 16:06:23 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice In-Reply-To: References: <-1bnefBpuQA1cHNaN93ULwBskNsIU49tYw6sUE9a_TI=.e7ef496c-d6a0-4f3c-900f-5f817b77c5cf@github.com> Message-ID: On Wed, 13 Apr 2022 07:50:55 GMT, Daniel Jeli?ski wrote: >> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 72: >> >>> 70: } >>> 71: >>> 72: static AlgorithmConstraints wrap(AlgorithmConstraints userSpecifiedConstraints) { >> >> I may update all of the constructors so that the accumulation of the reference of userSpecifiedConstraints could be avoid further. >> >> >> - this.userSpecifiedConstraints = userSpecifiedConstraints; >> + this.userSpecifiedConstraints = userSpecifiedConstraints == DEFAULT ? >> + null : userSpecifiedConstraints; >> >> >> >> Similar update could be placed in the getUserSpecifiedConstraints() implementation. > > Thanks @XueleiFan for the review! > If we do that, this will result in a behavior change for cases where `enabledX509DisabledAlgConstraints` = false; is that okay? Or should we set `enabledX509DisabledAlgConstraints` = true if `userSpecifiedConstraints == DEFAULT`? I think it is OK. The enabledX509DisabledAlgConstraints should be specified with the withDefaultCertPathConstraints parameterm, and should not be overrode by the userSpecifiedConstraints. I think it is a behavior that we'd like to correct. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From xueleifan at tencent.com Wed Apr 13 16:19:57 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Wed, 13 Apr 2022 16:19:57 +0000 Subject: [Internet]Re: JEP Review Request: TLS Certificate Compression In-Reply-To: <66667359-7a4f-4fdb-2b8a-5384d9b9a29b@oracle.com> References: <66667359-7a4f-4fdb-2b8a-5384d9b9a29b@oracle.com> Message-ID: Ping ? Xuelei > On Mar 24, 2022, at 1:05 PM, Sean Mullan wrote: > > > > On 3/21/22 11:49 AM, xueleifan(XueleiFan) wrote: >> Hi, >> >> >> The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for community review. Detailed, please refer to the draft: >> >> https://bugs.openjdk.java.net/browse/JDK-8281710 > > Or a more readable version at https://openjdk.java.net/jeps/8281710 > > --Sean > >> >> and the discussion of this potential feature at security-dev: >> >> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html >> >> >> Please feel free to make comments and review the JEP. >> >> Thanks, >> Xuelei > > From anthony.scarpino at oracle.com Wed Apr 13 17:05:50 2022 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 13 Apr 2022 10:05:50 -0700 Subject: AlgorithmConstraints caching [ was Re: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice] In-Reply-To: References: Message-ID: <08a9602e-1d50-334c-7121-cf3348463429@oracle.com> Hi Sean, Caching is an interesting idea. I've wondered for a while off and on about how to speed it up, but hadn't come up with a solution I liked. The complication with caching is while something like an algorithm name only could be easy in a hashmap, it gets more complicated when you get into key sizes. Such as, how to represent RSA 1k being disallowed and but 2k allowed.. or certificate usage.. Tony On 4/13/22 2:03 AM, Sean Coffey wrote: > On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeli?ski wrote: > >> During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. >> >> This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. > > Nice work. I've been looking at this area myself in recent weeks also while debugging some JDK 11u performance issues. JFR shows this area as costly. Some other JDK fixes in this area have already improved performance. This will certainly help. Pasting a stacktrace[1] from an old Oracle JDK 11.0.12 report for history purposes. > > I think there are other improvements that can be made in the TLS constraints code. Caching the last known values from a constraints permits test is something I've begun looking into. > > [1] > Stack Trace Count Percentage > boolean java.lang.StringLatin1.regionMatchesCI(byte[], int, byte[], int, int) 1637 100?% > boolean java.lang.String.regionMatches(boolean, int, String, int, int) 1637 100?% > boolean java.lang.String.equalsIgnoreCase(String) 1637 100?% > boolean sun.security.util.AbstractAlgorithmConstraints.checkAlgorithm(List, String, AlgorithmDecomposer) 1631 99.6?% > boolean sun.security.util.DisabledAlgorithmConstraints.permits(Set, String, AlgorithmParameters) 1631 99.6?% > boolean sun.security.ssl.SSLAlgorithmConstraints.permits(Set, String, AlgorithmParameters) 1631 99.6?% > boolean sun.security.ssl.SSLAlgorithmConstraints.permits(Set, String, AlgorithmParameters) 836 51.1?% > boolean sun.security.ssl.HandshakeContext.isActivatable(CipherSuite, AlgorithmConstraints, Map) 428 26.1?% > List sun.security.ssl.HandshakeContext.getActiveCipherSuites(List, List, AlgorithmConstraints) 418 25.5?% > void sun.security.ssl.HandshakeContext.(SSLContextImpl, TransportContext) 418 25.5?% > void sun.security.ssl.ClientHandshakeContext.(SSLContextImpl, TransportContext) 418 25.5?% > void sun.security.ssl.TransportContext.kickstart() 418 25.5?% > void sun.security.ssl.SSLSocketImpl.startHandshake(boolean) 418 25.5?% > void sun.security.ssl.SSLSocketImpl.startHandshake() 418 25.5?% > > ------------- > > Marked as reviewed by coffeys (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/8199 From valeriep at openjdk.java.net Wed Apr 13 18:26:13 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 13 Apr 2022 18:26:13 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 01:27:35 GMT, Valerie Peng wrote: > This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring. > > The CSR will be filed once review is somewhat finished. > > Thanks, > Valerie > _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_ > > On 4/11/2022 9:34 PM, Valerie Peng wrote: > > Hi Valerie - > > I think deprecating DEFAULT? is wrong.? RFC8017 still has this definition: > > > RSAES-OAEP-params ::= SEQUENCE { > > hashAlgorithm [0] HashAlgorithm DEFAULT sha1, > > maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, > > pSourceAlgorithm [2] PSourceAlgorithm DEFAULT pSpecifiedEmpty > > } > > and DEFAULT is what you should be getting if you see an empty sequence in the param field.? It's DEFAULT in ASN1 terms, not DEFAULT in terms of what you should use going forward? to create signatures, and the ASN1 DEFAULT won't change. > > In any event, I can't find where RFC8017 says anything about deprecating the defaults.? AFAICT, although there's general guidance to go away from SHA1,? the math suggests that SHA1 is still sufficient for OAEP,? and there's no guidance specific to OAEP's use of SHA1 that I can find other than the requirement in NIST SP800-56B rev 2 to use "Approved Hash Functions" for OAEP. If there's a section in 8017 that you're looking at for this guidance that I missed, you may want to update your comment to point to it. > > Take care - Mike > > -------------- next part -------------- An HTML attachment was scrubbed... URL: Hi Mike, Thanks for the comment/feedback. Deprecating the static field in javadoc does not mean we are changing its parameters with something other than those in RFC 8017. Providers can and should still follow the default ASN.1 values when the DER encoding omit the particular field(s). Besides what Sean mentioned already, this deprecation is an effort to moving toward the "explicitly specify what you want to use" direction. Hope this clarifies thing up? I like the suggestion for using a more specific link and will change it to point to the particular section. Regards, Valerie ------------- PR: https://git.openjdk.java.net/jdk/pull/8191 From valeriep at openjdk.java.net Wed Apr 13 18:32:15 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 13 Apr 2022 18:32:15 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec In-Reply-To: <5E98i8Wqd6lh6rYAfUT2wvy78C5X-Who_TGDjVbjGtA=.1e56702d-04d5-4959-9935-c4e942013ceb@github.com> References: <5E98i8Wqd6lh6rYAfUT2wvy78C5X-Who_TGDjVbjGtA=.1e56702d-04d5-4959-9935-c4e942013ceb@github.com> Message-ID: On Wed, 13 Apr 2022 15:35:38 GMT, Sean Mullan wrote: >> This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring. >> >> The CSR will be filed once review is somewhat finished. >> >> Thanks, >> Valerie > > src/java.base/share/classes/javax/crypto/spec/OAEPParameterSpec.java line 81: > >> 79: * parameters for mgf -- MGF1ParameterSpec.SHA1 >> 80: * source of encoding input -- PSource.PSpecified.DEFAULT >> 81: * > > I think you should leave these lines in, so users can still see what the default parameters are. Nit, change: > "the OAEPParameterSpec.DEFAULT uses the following" > to: > "{@code OAEPParameterSpec.DEFAULT} uses the following default values:" Leaving this in meaning we may have to duplicate the new wordings for the field here. The default values are covered in the paragraph above where the ASN.1 structure for RSAES-OAEP-params is defined. I can move this down to the javadoc field description for the DEFAULT field. ------------- PR: https://git.openjdk.java.net/jdk/pull/8191 From mullan at openjdk.java.net Wed Apr 13 18:37:15 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 13 Apr 2022 18:37:15 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec In-Reply-To: References: <5E98i8Wqd6lh6rYAfUT2wvy78C5X-Who_TGDjVbjGtA=.1e56702d-04d5-4959-9935-c4e942013ceb@github.com> Message-ID: On Wed, 13 Apr 2022 18:28:33 GMT, Valerie Peng wrote: >> src/java.base/share/classes/javax/crypto/spec/OAEPParameterSpec.java line 81: >> >>> 79: * parameters for mgf -- MGF1ParameterSpec.SHA1 >>> 80: * source of encoding input -- PSource.PSpecified.DEFAULT >>> 81: * >> >> I think you should leave these lines in, so users can still see what the default parameters are. Nit, change: >> "the OAEPParameterSpec.DEFAULT uses the following" >> to: >> "{@code OAEPParameterSpec.DEFAULT} uses the following default values:" > > Leaving this in meaning we may have to duplicate the new wordings for the field here. The default values are covered in the paragraph above where the ASN.1 structure for RSAES-OAEP-params is defined. I can move this down to the javadoc field description for the DEFAULT field. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/8191 From valeriep at openjdk.java.net Wed Apr 13 19:27:00 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 13 Apr 2022 19:27:00 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec [v2] In-Reply-To: References: Message-ID: > This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring. > > The CSR will be filed once review is somewhat finished. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update w/ review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8191/files - new: https://git.openjdk.java.net/jdk/pull/8191/files/371afccb..ba572eed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8191&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8191&range=00-01 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8191/head:pull/8191 PR: https://git.openjdk.java.net/jdk/pull/8191 From smarks at openjdk.java.net Wed Apr 13 19:31:18 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 13 Apr 2022 19:31:18 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 16:29:11 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > revert changes in: > src/java.desktop > src/java.management > src/jdk.internal.vm.ci > src/jdk.jfr > src/jdk.management.jfr > src/jdk.management > src/utils/IdealGraphVisualizer Reviewers for i18n, net, nio, and security, please review call site changes in your areas. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From djelinski1 at gmail.com Wed Apr 13 20:01:29 2022 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Wed, 13 Apr 2022 22:01:29 +0200 Subject: JEP Review Request: TLS Certificate Compression In-Reply-To: References: Message-ID: I like the idea of implementing certificate compression. Only one concern: TLS handshakes are generally a CPU-intensive operation, and certificate compression / decompression will only make it worse. Will it be possible to compress a certificate once and use it across multiple handshakes? Decompression has to be performed every time, obviously. Regards, Daniel pon., 21 mar 2022 o 16:49 xueleifan(XueleiFan) napisa?(a): > > Hi, > > > The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for community review. Detailed, please refer to the draft: > > https://bugs.openjdk.java.net/browse/JDK-8281710 > > and the discussion of this potential feature at security-dev: > > https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html > > > Please feel free to make comments and review the JEP. > > Thanks, > Xuelei From naoto at openjdk.java.net Wed Apr 13 20:10:11 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 13 Apr 2022 20:10:11 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 16:29:11 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > revert changes in: > src/java.desktop > src/java.management > src/jdk.internal.vm.ci > src/jdk.jfr > src/jdk.management.jfr > src/jdk.management > src/utils/IdealGraphVisualizer Looks good for changes in i18n related call sites, assuming that the copyright years will be updated. Should we need some additions/modifications to the hashmap optimal capacity utility `test/lib/jdk/test/lib/util/OptimalCapacity.java`? ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7928 From djelinski at openjdk.java.net Wed Apr 13 20:32:02 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 13 Apr 2022 20:32:02 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v2] In-Reply-To: References: Message-ID: > During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. > > This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Avoid nesting SSLAlgorithmConstraints ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8199/files - new: https://git.openjdk.java.net/jdk/pull/8199/files/9bcd0b66..b6e46ae9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8199&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8199&range=00-01 Stats: 14 lines in 1 file changed: 9 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8199.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8199/head:pull/8199 PR: https://git.openjdk.java.net/jdk/pull/8199 From aturbanov at openjdk.java.net Wed Apr 13 20:45:35 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 13 Apr 2022 20:45:35 GMT Subject: RFR: 8284853: Fix varios 'expected' typo Message-ID: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. ------------- Commit messages: - [PATCH] Fix 'expected' typo - [PATCH] Fix 'expected' typo - [PATCH] Fix 'expected' typo Changes: https://git.openjdk.java.net/jdk/pull/8231/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8231&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284853 Stats: 65 lines in 28 files changed: 0 ins; 0 del; 65 mod Patch: https://git.openjdk.java.net/jdk/pull/8231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8231/head:pull/8231 PR: https://git.openjdk.java.net/jdk/pull/8231 From duke at openjdk.java.net Wed Apr 13 21:00:38 2022 From: duke at openjdk.java.net (Mark Powers) Date: Wed, 13 Apr 2022 21:00:38 GMT Subject: RFR: JDK-8284112 Minor cleanup could be done in javax.crypto In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 06:31:51 GMT, Bradford Wetmore wrote: >> JDK-8284112 Minor cleanup could be done in javax.crypto > > src/java.base/share/classes/javax/crypto/CipherInputStream.java line 159: > >> 157: try { >> 158: ofinish = cipher.update(ibuffer, 0, readin, obuffer, ostart); >> 159: } catch (IllegalStateException e) { > > This is another one of those I would probably leave alone, just so it's clear what should be done. Keeping the original. > src/java.base/share/classes/javax/crypto/CipherSpi.java line 29: > >> 27: >> 28: import java.nio.ByteBuffer; >> 29: import java.security.*; > > This is another one that some people will complain about. I personally prefer this style, others prefer everything written out as long as it's not "too many." Keeping the change for now. > src/java.base/share/classes/javax/crypto/CryptoPermission.java line 437: > >> 435: // may be the best try. >> 436: return this.algParamSpec.equals(algParamSpec); >> 437: } else return !this.checkParam; > > Please use the standard coding format. > > } else { > return !this.checkParam; > } > > or > > } > > return !this.checkParam; Using the first format. > src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 158: > >> 156: >> 157: /** >> 158: * Checks if this object's PermissionCollection for permissions > > Just FYI and not for this review, but this class should really be updated to use proper javadoc comment style, which is to tag all objects with < code >PermissionCollection< /code > No change required. > src/java.base/share/classes/javax/crypto/ExemptionMechanism.java line 142: > >> 140: * @see java.security.Provider >> 141: */ >> 142: public static ExemptionMechanism getInstance(String algorithm) > > Others might disagree with this comment, but I would encourage you not to make these changes throughout your PR. (@jddarcy ?) > > Even though a static method is implicitly final and IJ is correct, the final keyword does prevent subclasses from inadvertently using the same method signature. > > Once this is resolved, I can approve. Keeping the original here and elsewhere. > src/java.base/share/classes/javax/crypto/SealedObject.java line 449: > >> 447: final class extObjectInputStream extends ObjectInputStream { >> 448: extObjectInputStream(InputStream in) >> 449: throws IOException { > > This is another "I probably wouldn't do that..." > > It's nice to know what kind of IOExceptions you might get, so leaving StreamCorruptedException is ok. Keeping the original. Still, why would IJ suggest removing this unless it had already figured out the exception could never happen? > src/java.base/share/classes/javax/crypto/spec/DESKeySpec.java line 49: > >> 47: * Weak/semi-weak keys copied from FIPS 74. >> 48: * >> 49: * "...The first 6 keys have duals different from themselves, hence > > Suggest you leave this alone as this is a direct quote from FIPS 74 (page 10). Keeping the original. ------------- PR: https://git.openjdk.java.net/jdk/pull/8214 From joehw at openjdk.java.net Wed Apr 13 21:05:23 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 13 Apr 2022 21:05:23 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16] In-Reply-To: References: Message-ID: <21Zq0-bQTy5fAlxd-WnsAp-JQ6DwJ5HO4ceFTN3zCRQ=.98cd3042-cbe2-4c6a-9647-7762fcb20d89@github.com> On Wed, 13 Apr 2022 16:29:11 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > revert changes in: > src/java.desktop > src/java.management > src/jdk.internal.vm.ci > src/jdk.jfr > src/jdk.management.jfr > src/jdk.management > src/utils/IdealGraphVisualizer Looks good for the changes in java.xml, like Naoto, assuming copyright years and the LastModified tag are updated. I generally prefer for the source level to stay at 8 as the upstream source is maintained at an older JDK level, but these changes seem to be small enough to tolerate. ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7928 From ecki at zusammenkunft.net Wed Apr 13 21:07:02 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 13 Apr 2022 21:07:02 +0000 Subject: JEP Review Request: TLS Certificate Compression In-Reply-To: References: Message-ID: Hello, For multiple connections session- or ticket reuse would be much more efficient. In fact I think cert compression looks like the wrong solution. Having a immutable certificate download Chain would be a cool alternative solution - especially with future large postquantumcrypto certificates. That?s also easy to cache. (But I recon that?s not for this list to discuss, it?s just an argument against implementing a draft standard) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Daniel Jeli?ski Gesendet: Wednesday, April 13, 2022 10:01:29 PM An: xueleifan(XueleiFan) Cc: OpenJDK Dev list Betreff: Re: JEP Review Request: TLS Certificate Compression I like the idea of implementing certificate compression. Only one concern: TLS handshakes are generally a CPU-intensive operation, and certificate compression / decompression will only make it worse. Will it be possible to compress a certificate once and use it across multiple handshakes? Decompression has to be performed every time, obviously. Regards, Daniel pon., 21 mar 2022 o 16:49 xueleifan(XueleiFan) napisa?(a): > > Hi, > > > The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for community review. Detailed, please refer to the draft: > > https://bugs.openjdk.java.net/browse/JDK-8281710 > > and the discussion of this potential feature at security-dev: > > https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html > > > Please feel free to make comments and review the JEP. > > Thanks, > Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From lancea at openjdk.java.net Wed Apr 13 21:26:15 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 13 Apr 2022 21:26:15 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 16:29:11 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > revert changes in: > src/java.desktop > src/java.management > src/jdk.internal.vm.ci > src/jdk.jfr > src/jdk.management.jfr > src/jdk.management > src/utils/IdealGraphVisualizer The ZipFS and Jar changes seem OK ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7928 From djelinski at openjdk.java.net Wed Apr 13 21:41:26 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 13 Apr 2022 21:41:26 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v2] In-Reply-To: References: <-1bnefBpuQA1cHNaN93ULwBskNsIU49tYw6sUE9a_TI=.e7ef496c-d6a0-4f3c-900f-5f817b77c5cf@github.com> Message-ID: <7kEGOoNdXMS1amkoRXhgiokSNGUBskBseOy0wr2-rhU=.25a42d5a-8e94-42b3-a881-13a3d0245e74@github.com> On Wed, 13 Apr 2022 16:02:50 GMT, Xue-Lei Andrew Fan wrote: >> Thanks @XueleiFan for the review! >> If we do that, this will result in a behavior change for cases where `enabledX509DisabledAlgConstraints` = false; is that okay? Or should we set `enabledX509DisabledAlgConstraints` = true if `userSpecifiedConstraints == DEFAULT`? > > I think it is OK. The enabledX509DisabledAlgConstraints should be specified with the withDefaultCertPathConstraints parameterm, and should not be overrode by the userSpecifiedConstraints. I think it is a behavior that we'd like to correct. updated the patch. Let me know if that's what you had in mind. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From xueleifan at tencent.com Wed Apr 13 21:47:39 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Wed, 13 Apr 2022 21:47:39 +0000 Subject: [Internet]Re: JEP Review Request: TLS Certificate Compression In-Reply-To: References: Message-ID: Hi Daniel, Actually, I?m considering the improvement, by using cached compressed certificates, for the implementation. The solution is not straightforward yet to me. But it is a direction I will consider seriously. Thanks, Xuelei > On Apr 13, 2022, at 1:01 PM, Daniel Jeli?ski wrote: > > I like the idea of implementing certificate compression. Only one > concern: TLS handshakes are generally a CPU-intensive operation, and > certificate compression / decompression will only make it worse. Will > it be possible to compress a certificate once and use it across > multiple handshakes? Decompression has to be performed every time, > obviously. > > Regards, > Daniel > > pon., 21 mar 2022 o 16:49 xueleifan(XueleiFan) > napisa?(a): >> >> Hi, >> >> >> The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for community review. Detailed, please refer to the draft: >> >> https://bugs.openjdk.java.net/browse/JDK-8281710 >> >> and the discussion of this potential feature at security-dev: >> >> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html >> >> >> Please feel free to make comments and review the JEP. >> >> Thanks, >> Xuelei > From xueleifan at tencent.com Wed Apr 13 21:52:09 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Wed, 13 Apr 2022 21:52:09 +0000 Subject: [Internet]Re: JEP Review Request: TLS Certificate Compression In-Reply-To: References: Message-ID: <41EF5C38-1673-4DE7-8574-2AB4584E8928@Tencent.Com> On Apr 13, 2022, at 2:07 PM, Bernd Eckenfels > wrote: Hello, For multiple connections session- or ticket reuse would be much more efficient. In fact I think cert compression looks like the wrong solution. Having a immutable certificate download Chain would be a cool alternative solution - especially with future large postquantumcrypto certificates. That?s also easy to cache. I agreed, it would be cool as well if the certificate chain could be cached in the DNS record. Thanks, Xuelei (But I recon that?s not for this list to discuss, it?s just an argument against implementing a draft standard) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev > im Auftrag von Daniel Jeli?ski > Gesendet: Wednesday, April 13, 2022 10:01:29 PM An: xueleifan(XueleiFan) > Cc: OpenJDK Dev list > Betreff: Re: JEP Review Request: TLS Certificate Compression I like the idea of implementing certificate compression. Only one concern: TLS handshakes are generally a CPU-intensive operation, and certificate compression / decompression will only make it worse. Will it be possible to compress a certificate once and use it across multiple handshakes? Decompression has to be performed every time, obviously. Regards, Daniel pon., 21 mar 2022 o 16:49 xueleifan(XueleiFan) > napisa?(a): > > Hi, > > > The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for community review. Detailed, please refer to the draft: > > https://bugs.openjdk.java.net/browse/JDK-8281710 > > and the discussion of this potential feature at security-dev: > > https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html > > > Please feel free to make comments and review the JEP. > > Thanks, > Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.java.net Wed Apr 13 21:57:19 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 13 Apr 2022 21:57:19 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() In-Reply-To: References: Message-ID: <3XOl6ZuU6Qh1Wi_MQssPxDHSrz3PHWHQ69DwZX1Iu7Q=.e1129e1f-038f-4058-9366-15cfda83a53e@github.com> On Wed, 13 Apr 2022 07:01:19 GMT, Xue-Lei Andrew Fan wrote: >> How about this then? >> >> *

The returned parameters may be the same that were used to initialize >> * this cipher, or may contain additional default and random parameter >> * values used by the underlying cipher implementation if this >> * cipher can successfully generate the required parameter values when >> * not supplied. Otherwise, {@code null} is returned. > > I like the revised spec more. > > BTW, for "... contain additional default and random parameter values ...", is "or" more common than "and" in English? Hmm, the original javadoc has "and", so I just picked it up. Perhaps I should change it to "or" then. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From valeriep at openjdk.java.net Wed Apr 13 22:04:03 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 13 Apr 2022 22:04:03 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] 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 w/ review feedbacks ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8117/files - new: https://git.openjdk.java.net/jdk/pull/8117/files/b0463fba..9b8b71a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8117&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8117&range=00-01 Stats: 19 lines in 2 files changed: 0 ins; 0 del; 19 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 duke at openjdk.java.net Wed Apr 13 22:10:09 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 13 Apr 2022 22:10:09 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v17] In-Reply-To: References: Message-ID: <3_faiutX4epQEXucP2z6IcaH5QLh4py7mqmuvYeUZTs=.9604e1eb-dd98-44fe-955b-d08966a78ba1@github.com> > 8186958: Need method to create pre-sized HashMap XenoAmess has updated the pull request incrementally with one additional commit since the last revision: Copyright latest year to 2022 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7928/files - new: https://git.openjdk.java.net/jdk/pull/7928/files/2f5617bb..4476c761 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=15-16 Stats: 24 lines in 24 files changed: 0 ins; 0 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/7928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928 PR: https://git.openjdk.java.net/jdk/pull/7928 From bpb at openjdk.java.net Wed Apr 13 22:15:15 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 13 Apr 2022 22:15:15 GMT Subject: RFR: 8284853: Fix varios 'expected' typo In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote: > Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. Expect the Unexpeted. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8231 From duke at openjdk.java.net Wed Apr 13 22:20:14 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 13 Apr 2022 22:20:14 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: References: Message-ID: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> > 8186958: Need method to create pre-sized HashMap XenoAmess has updated the pull request incrementally with one additional commit since the last revision: update LastModified ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7928/files - new: https://git.openjdk.java.net/jdk/pull/7928/files/4476c761..d110ecfd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=16-17 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928 PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Wed Apr 13 22:20:15 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 13 Apr 2022 22:20:15 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 20:06:34 GMT, Naoto Sato wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> revert changes in: >> src/java.desktop >> src/java.management >> src/jdk.internal.vm.ci >> src/jdk.jfr >> src/jdk.management.jfr >> src/jdk.management >> src/utils/IdealGraphVisualizer > > Looks good for changes in i18n related call sites, assuming that the copyright years will be updated. > > Should we need some additions/modifications to the hashmap optimal capacity utility `test/lib/jdk/test/lib/util/OptimalCapacity.java`? @naotoj @JoeWang-Java copyright updated to 2022. LastModified updated to 2022. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From smarks at openjdk.java.net Wed Apr 13 22:44:19 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 13 Apr 2022 22:44:19 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> References: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> Message-ID: <0wlaWl-UQhwWw0Oe1JNW3JrpYKHahcEfrdbWjXOZ7Ic=.ab6c195a-f142-4aa2-824e-d4afe63a2e4c@github.com> On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > update LastModified src/java.base/share/classes/java/lang/Character.java line 8574: > 8572: private static final HashMap aliases; > 8573: static { > 8574: aliases = HashMap.newHashMap(162); @naotoj Seems like this magic number is likely to go out of date. Should there be a test for it like the one you updated for NUM_ENTITIES? [JDK-8283465](https://bugs.openjdk.java.net/browse/JDK-8283465). ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From cjplummer at openjdk.java.net Wed Apr 13 22:45:18 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 13 Apr 2022 22:45:18 GMT Subject: RFR: 8284853: Fix varios 'expected' typo In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote: > Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. test/jdk/java/lang/StackWalker/StackStreamTest.java line 218: > 216: private static void equalsOrThrow(String label, List list, List expected) { > 217: System.out.println("List: " + list); > 218: System.out.println("Expected: " + list); I think there is a per-existing bug here. Shouldn't the second println print `expected` instead of `list`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From naoto at openjdk.java.net Wed Apr 13 22:56:31 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 13 Apr 2022 22:56:31 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: <0wlaWl-UQhwWw0Oe1JNW3JrpYKHahcEfrdbWjXOZ7Ic=.ab6c195a-f142-4aa2-824e-d4afe63a2e4c@github.com> References: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> <0wlaWl-UQhwWw0Oe1JNW3JrpYKHahcEfrdbWjXOZ7Ic=.ab6c195a-f142-4aa2-824e-d4afe63a2e4c@github.com> Message-ID: On Wed, 13 Apr 2022 22:40:38 GMT, Stuart Marks wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> update LastModified > > src/java.base/share/classes/java/lang/Character.java line 8574: > >> 8572: private static final HashMap aliases; >> 8573: static { >> 8574: aliases = HashMap.newHashMap(162); > > @naotoj Seems like this magic number is likely to go out of date. Should there be a test for it like the one you updated for NUM_ENTITIES? [JDK-8283465](https://bugs.openjdk.java.net/browse/JDK-8283465). Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856 ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From smarks at openjdk.java.net Wed Apr 13 23:01:16 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 13 Apr 2022 23:01:16 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> References: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> Message-ID: On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > update LastModified src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java line 171: > 169: _current = 0; > 170: _size = size; > 171: _references = HashMap.newHashMap(_size); Not `_size+2` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From smarks at openjdk.java.net Wed Apr 13 23:06:16 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 13 Apr 2022 23:06:16 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> References: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> Message-ID: On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > update LastModified src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java line 1819: > 1817: Map items; > 1818: LargeContainer(int size) { > 1819: items = HashMap.newHashMap(size*2+1); I'm wondering if we should change this to just `newHashMap(size)` since it looks like this container is intended to hold up to `size` items. @JoeWang-Java ? I suspect the `size*2+1` was a failed attempt at allocating a HashMap of the correct capacity for `size` mappings. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From smarks at openjdk.java.net Wed Apr 13 23:29:19 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 13 Apr 2022 23:29:19 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> References: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> Message-ID: On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > update LastModified src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 102: > 100: /* Only for use by Runtime.exec(...String[]envp...) */ > 101: static Map emptyEnvironment(int capacity) { > 102: return new StringEnvironment(HashMap.newHashMap(capacity)); This change is correct, since this is called with the length of an array that's used to populate the environment. It really should be named `size` instead of `capacity`. However the windows version of this code simply calls `super(capacity)` as it's a subclass of `HashMap`, which is wrong. Well, probably not worth changing this now. We may need to revisit this later to do some cleaning up. (And also the strange computation in the static initializer at line 71.) ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From smarks at openjdk.java.net Wed Apr 13 23:51:16 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 13 Apr 2022 23:51:16 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 20:06:34 GMT, Naoto Sato wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> revert changes in: >> src/java.desktop >> src/java.management >> src/jdk.internal.vm.ci >> src/jdk.jfr >> src/jdk.management.jfr >> src/jdk.management >> src/utils/IdealGraphVisualizer > > Looks good for changes in i18n related call sites, assuming that the copyright years will be updated. > > Should we need some additions/modifications to the hashmap optimal capacity utility `test/lib/jdk/test/lib/util/OptimalCapacity.java`? @naotoj wrote: > Should we need some additions/modifications to the hashmap optimal capacity utility `test/lib/jdk/test/lib/util/OptimalCapacity.java`? The only thing that uses this utility now is `test/jdk/java/lang/Enum/ConstantDirectoryOptimalCapacity.java`, which is on the problem list. The cleanup is covered by [JDK-8282120](https://bugs.openjdk.java.net/browse/JDK-8282120). After this PR gets integrated, the Enum ConstantDirectory will be initialized with `HashMap.newHashMap(universe.length)` so the OptimalCapacity test won't really be testing anything. I'll take another look at it and the library utility, but I suspect the cleanup may simply be removing them entirely. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From naoto at openjdk.java.net Thu Apr 14 00:32:19 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 14 Apr 2022 00:32:19 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16] In-Reply-To: References: Message-ID: <_7xS1jx8qIo088_W_yOC8VCiUgRyl4eWXrNSWSa6OPY=.e8d5bdd1-91bb-4eb7-8043-20197415e5d8@github.com> On Wed, 13 Apr 2022 23:48:06 GMT, Stuart Marks wrote: > but I suspect the cleanup may simply be removing them entirely. +1 for removing it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Apr 14 00:37:04 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 14 Apr 2022 00:37:04 GMT Subject: RFR: JDK-8284112 Minor cleanup could be done in javax.crypto [v2] In-Reply-To: References: Message-ID: > JDK-8284112 Minor cleanup could be done in javax.crypto Mark Powers has updated the pull request incrementally with two additional commits since the last revision: - merge stuff - review comments from Brad Wetmore ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8214/files - new: https://git.openjdk.java.net/jdk/pull/8214/files/a6754642..86a546bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8214&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8214&range=00-01 Stats: 24 lines in 10 files changed: 4 ins; 0 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/8214.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8214/head:pull/8214 PR: https://git.openjdk.java.net/jdk/pull/8214 From duke at openjdk.java.net Thu Apr 14 01:18:10 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 14 Apr 2022 01:18:10 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: References: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> Message-ID: On Wed, 13 Apr 2022 22:57:33 GMT, Stuart Marks wrote: > Not `_size+2` ? I don't have a idea here why he original use the + 2. Is there any guy more familiar with this code tell me why? Thanks! > I suspect the `size*2+1` was a failed attempt at allocating a HashMap of the correct capacity for `size` mappings. I looked the codes and don't think so.. If I'm wrong, I'm glad to fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From joehw at openjdk.java.net Thu Apr 14 03:31:15 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 14 Apr 2022 03:31:15 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: References: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> Message-ID: On Thu, 14 Apr 2022 01:15:05 GMT, XenoAmess wrote: >> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java line 171: >> >>> 169: _current = 0; >>> 170: _size = size; >>> 171: _references = HashMap.newHashMap(_size); >> >> Not `_size+2` ? > >> Not `_size+2` ? > > I don't have a idea here why he original use the + 2. > Is there any guy more familiar with this code tell me why? > Thanks! size, not size + 2, same situation as size*2+1 below. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From xuelei at openjdk.java.net Thu Apr 14 04:14:06 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 14 Apr 2022 04:14:06 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 22:04:03 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 incrementally with one additional commit since the last revision: > > Update w/ review feedbacks Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From xuelei at openjdk.java.net Thu Apr 14 04:14:07 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 14 Apr 2022 04:14:07 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: <3XOl6ZuU6Qh1Wi_MQssPxDHSrz3PHWHQ69DwZX1Iu7Q=.e1129e1f-038f-4058-9366-15cfda83a53e@github.com> References: <3XOl6ZuU6Qh1Wi_MQssPxDHSrz3PHWHQ69DwZX1Iu7Q=.e1129e1f-038f-4058-9366-15cfda83a53e@github.com> Message-ID: On Wed, 13 Apr 2022 21:53:33 GMT, Valerie Peng wrote: >> I like the revised spec more. >> >> BTW, for "... contain additional default and random parameter values ...", is "or" more common than "and" in English? > > Hmm, the original javadoc has "and", so I just picked it up. Perhaps I should change it to "or" then. Thanks. Thank you, I have no further comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From joehw at openjdk.java.net Thu Apr 14 03:42:16 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 14 Apr 2022 03:42:16 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: References: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> Message-ID: On Thu, 14 Apr 2022 01:13:18 GMT, XenoAmess wrote: >> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java line 1819: >> >>> 1817: Map items; >>> 1818: LargeContainer(int size) { >>> 1819: items = HashMap.newHashMap(size*2+1); >> >> I'm wondering if we should change this to just `newHashMap(size)` since it looks like this container is intended to hold up to `size` items. @JoeWang-Java ? I suspect the `size*2+1` was a failed attempt at allocating a HashMap of the correct capacity for `size` mappings. > >> I suspect the `size*2+1` was a failed attempt at allocating a HashMap of the correct capacity for `size` mappings. > > I looked the codes and don't think so.. > If I'm wrong, I'm glad to fix. Stuart's right, I looked at the code, it's as you said a failed attempt, "size" would be good. So HashMap.newHashMap(size) would actually be a small improvement. It's an interesting impl the way it used HashMap, but it's 20 year code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From xuelei at openjdk.java.net Thu Apr 14 04:27:14 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 14 Apr 2022 04:27:14 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 20:32:02 GMT, Daniel Jeli?ski wrote: >> During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. >> >> This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Avoid nesting SSLAlgorithmConstraints src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 73: > 71: > 72: static AlgorithmConstraints wrap(AlgorithmConstraints userSpecifiedConstraints) { > 73: if (userSpecifiedConstraints == DEFAULT) { Maybe, DEFAULT could be returned for null userSpecifiedConstraints. - if (userSpecifiedConstraints == DEFAULT) { + if (userSpecifiedConstraints == null && + userSpecifiedConstraints== DEFAULT) { ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From xuelei at openjdk.java.net Thu Apr 14 06:37:15 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 14 Apr 2022 06:37:15 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2] In-Reply-To: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> References: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> Message-ID: On Thu, 7 Apr 2022 20:17:28 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 two additional commits since the last revision: > > - typo blank linke correction > - revise the update I parsed the finalize() code one more time. The sending close_notify may be not an expected part of the finalize() implementation. The finalize() calls the close() method. If the socket is layered over a preexisting socket, the preexisting socket is closed by calling it close() method: ` self.close(); ` Otherwise, the SSLSocket.close() method will be called: ` super.close(); ` See the BaseSSLSocketImpl.close() method: @Override public void close() throws IOException { if (self == this) { super.close(); } else { self.close(); } } For layered over socket case, if the preexisting socket is not an SSLSocket object(which is the common case), no close_notify will be sent off course. If the preexisting socket is an SSLSocket object (which may be not common), the SSLSocketImpl.close() will be called and the close_notify could be sent. For non-layered over sockets, as super.close() is called, there is no close_notify delivered during the finalizing. Based on the cases above, the close_notify delivery may be not an expected behavior during finalization in practice. I would like to remove the finalize() method without adding a cleaner, as shown in the current PR. But if you read the code and behavior differently , it's acceptable to me to clean up the preexisting socket, by adding a cleaner like: BaseSSLSocketImpl(Socket socket) { super(); this.self = socket; this.consumedInput = null; + CleanerFactory.cleaner().register(this, self::close); } Please let me know your preference. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From dfuchs at openjdk.java.net Thu Apr 14 08:45:19 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 14 Apr 2022 08:45:19 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v16] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 19:28:08 GMT, Stuart Marks wrote: > Reviewers for i18n, net, nio, and security, please review call site changes in your areas. Thanks. Changes to `java.net.http` look good to me. I haven't spotted anything obviously wrong in the rest, but should defer to reviewers of these areas. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From dfuchs at openjdk.java.net Thu Apr 14 09:03:16 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 14 Apr 2022 09:03:16 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v2] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 04:24:07 GMT, Xue-Lei Andrew Fan wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid nesting SSLAlgorithmConstraints > > src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 73: > >> 71: >> 72: static AlgorithmConstraints wrap(AlgorithmConstraints userSpecifiedConstraints) { >> 73: if (userSpecifiedConstraints == DEFAULT) { > > Maybe, DEFAULT could be returned for null userSpecifiedConstraints. > > > - if (userSpecifiedConstraints == DEFAULT) { > + if (userSpecifiedConstraints == null && > + userSpecifiedConstraints== DEFAULT) { @XueleiFan did you mean `||` (not `&&`) ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From aturbanov at openjdk.java.net Thu Apr 14 09:28:17 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 14 Apr 2022 09:28:17 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: > Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8284853: Fix various 'expected' typo improve test log ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8231/files - new: https://git.openjdk.java.net/jdk/pull/8231/files/fe6d9890..9fc75e89 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8231&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8231&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8231/head:pull/8231 PR: https://git.openjdk.java.net/jdk/pull/8231 From yyang at openjdk.java.net Thu Apr 14 10:42:11 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 14 Apr 2022 10:42:11 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov wrote: >> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8284853: Fix various 'expected' typo > improve test log I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948), I wonder if you can merge this into your patch so that I do not need to submit a new PR for it? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From ihse at openjdk.java.net Thu Apr 14 13:13:15 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 14 Apr 2022 13:13:15 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov wrote: >> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8284853: Fix various 'expected' typo > improve test log Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8231 From xuelei at openjdk.java.net Thu Apr 14 15:01:49 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 14 Apr 2022 15:01:49 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v2] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 04:24:07 GMT, Xue-Lei Andrew Fan wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid nesting SSLAlgorithmConstraints > > src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 73: > >> 71: >> 72: static AlgorithmConstraints wrap(AlgorithmConstraints userSpecifiedConstraints) { >> 73: if (userSpecifiedConstraints == DEFAULT) { > > Maybe, DEFAULT could be returned for null userSpecifiedConstraints. > > > - if (userSpecifiedConstraints == DEFAULT) { > + if (userSpecifiedConstraints == null && > + userSpecifiedConstraints== DEFAULT) { > @XueleiFan did you mean `||` (not `&&`) ? Thank you @dfuch. Yes, it should be "||". ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From xuelei at openjdk.java.net Thu Apr 14 15:22:29 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 14 Apr 2022 15:22:29 GMT Subject: RFR: 8284796: sun.security.ssl.Finished::toString misses a line feed in the message format pattern In-Reply-To: References: <5DZjwMadg9XcuRvup3GaB-fCdSkAY6IkATvXt4Gw2is=.3e7245c3-d7f3-4018-8db1-1b34e02e8840@github.com> Message-ID: On Wed, 13 Apr 2022 07:14:04 GMT, John Jiang wrote: > Could I not change this style? Sure. But effort of this update will be overrode if text blocks are used. I would suggest to use text block once the code block get touched. ------------- PR: https://git.openjdk.java.net/jdk/pull/8215 From djelinski at openjdk.java.net Thu Apr 14 15:40:48 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 14 Apr 2022 15:40:48 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2] In-Reply-To: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> References: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> Message-ID: On Thu, 7 Apr 2022 20:17:28 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 two additional commits since the last revision: > > - typo blank linke correction > - revise the update IMO we should not send close_notify in the finalizer. It's the application's responsibility to send close_notify when it's done with the socket; we should not pretend that it was closed normally when it was not. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From djelinski at openjdk.java.net Thu Apr 14 15:45:50 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 14 Apr 2022 15:45:50 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v2] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 14:58:24 GMT, Xue-Lei Andrew Fan wrote: >> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 73: >> >>> 71: >>> 72: static AlgorithmConstraints wrap(AlgorithmConstraints userSpecifiedConstraints) { >>> 73: if (userSpecifiedConstraints == DEFAULT) { >> >> Maybe, DEFAULT could be returned for null userSpecifiedConstraints. >> >> >> - if (userSpecifiedConstraints == DEFAULT) { >> + if (userSpecifiedConstraints == null && >> + userSpecifiedConstraints== DEFAULT) { > >> @XueleiFan did you mean `||` (not `&&`) ? > > Thank you @dfuch. Yes, it should be "||". as of today, this method is never called with a `null` argument (`SSLConfiguration#userSpecifiedAlgorithmConstraints` is initialized to `DEFAULT` and cannot be reset to `null`), but I can add a null check for future-proofing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From chegar at openjdk.java.net Thu Apr 14 15:55:35 2022 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 14 Apr 2022 15:55:35 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> References: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> Message-ID: <4BdteSngv9Euudaha21kOdmSYZicJ6L7jWT-emmUqTk=.4a13e3b2-b75f-4c42-b5bd-f839b5cf898d@github.com> On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > update LastModified LGTM. ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7928 From xuelei at openjdk.java.net Thu Apr 14 15:57:30 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 14 Apr 2022 15:57:30 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v2] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 15:43:42 GMT, Daniel Jeli?ski wrote: >>> @XueleiFan did you mean `||` (not `&&`) ? >> >> Thank you @dfuch. Yes, it should be "||". > > as of today, this method is never called with a `null` argument (`SSLConfiguration#userSpecifiedAlgorithmConstraints` is initialized to `DEFAULT` and cannot be reset to `null`), but I can add a null check for future-proofing. I know. But if the null condition is not added, a code reader may have to search for its usage and make sure null is not passed. If the usages are in the same class, I may not add the checking. Otherwise, an additional checking might save time in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From dfuchs at openjdk.java.net Thu Apr 14 16:07:32 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 14 Apr 2022 16:07:32 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v2] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 15:53:53 GMT, Xue-Lei Andrew Fan wrote: >> as of today, this method is never called with a `null` argument (`SSLConfiguration#userSpecifiedAlgorithmConstraints` is initialized to `DEFAULT` and cannot be reset to `null`), but I can add a null check for future-proofing. > > I know. But if the null condition is not added, a code reader may have to search for its usage and make sure null is not passed. If the usages are in the same class, I may not add the checking. Otherwise, an additional checking might save time in the future. In such cases `assert xxx != null;` could be used to tell the reader that `null` is not an expected value. But then you need to be absolutely sure that `null` can never reach here when in production. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From duke at openjdk.java.net Thu Apr 14 16:58:40 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 14 Apr 2022 16:58:40 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v19] In-Reply-To: References: Message-ID: > 8186958: Need method to create pre-sized HashMap XenoAmess has updated the pull request incrementally with one additional commit since the last revision: fix usage in XSAttributeChecker ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7928/files - new: https://git.openjdk.java.net/jdk/pull/7928/files/d110ecfd..5603f193 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=17-18 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928 PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Apr 14 16:58:42 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 14 Apr 2022 16:58:42 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: References: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> Message-ID: On Thu, 14 Apr 2022 03:38:52 GMT, Joe Wang wrote: >>> I suspect the `size*2+1` was a failed attempt at allocating a HashMap of the correct capacity for `size` mappings. >> >> I looked the codes and don't think so.. >> If I'm wrong, I'm glad to fix. > > Stuart's right, I looked at the code, it's as you said a failed attempt, "size" would be good. So HashMap.newHashMap(size) would actually be a small improvement. > > It's an interesting impl the way it used HashMap, but it's 20 year code. @JoeWang-Java @stuart-marks got it. done. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Apr 14 17:05:42 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 14 Apr 2022 17:05:42 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: References: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> Message-ID: <74mi18QF7mCaY5H_LJgOl47cqfoEB3WEmOVtfsv6v2A=.901a9ead-673e-4948-89a8-3f1dbfacbf8a@github.com> On Wed, 13 Apr 2022 23:25:47 GMT, Stuart Marks wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> update LastModified > > src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 102: > >> 100: /* Only for use by Runtime.exec(...String[]envp...) */ >> 101: static Map emptyEnvironment(int capacity) { >> 102: return new StringEnvironment(HashMap.newHashMap(capacity)); > > This change is correct, since this is called with the length of an array that's used to populate the environment. It really should be named `size` instead of `capacity`. However the windows version of this code simply calls `super(capacity)` as it's a subclass of `HashMap`, which is wrong. Well, probably not worth changing this now. We may need to revisit this later to do some cleaning up. (And also the strange computation in the static initializer at line 71.) @stuart-marks OK, changes on this class reverted. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Apr 14 17:05:39 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 14 Apr 2022 17:05:39 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v20] In-Reply-To: References: Message-ID: > 8186958: Need method to create pre-sized HashMap XenoAmess has updated the pull request incrementally with one additional commit since the last revision: revert changes on ProcessEnvironment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7928/files - new: https://git.openjdk.java.net/jdk/pull/7928/files/5603f193..5b437dab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=18-19 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928 PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Apr 14 17:10:36 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 14 Apr 2022 17:10:36 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: References: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> <0wlaWl-UQhwWw0Oe1JNW3JrpYKHahcEfrdbWjXOZ7Ic=.ab6c195a-f142-4aa2-824e-d4afe63a2e4c@github.com> Message-ID: <9Mjy2CA-ZYTC5v7KdhMuULeghdOSotPnUZnMIjxEplA=.cbf4cd73-5c1e-42d4-82a3-2e791e2af0f0@github.com> On Wed, 13 Apr 2022 22:53:15 GMT, Naoto Sato wrote: > Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856 @stuart-marks @naotoj I can help solve JDK-8284856 after this pr. But usually we only solve 1 issue in 1 pr, so I think it's better to wait after this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From joehw at openjdk.java.net Thu Apr 14 17:26:48 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 14 Apr 2022 17:26:48 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v20] In-Reply-To: References: Message-ID: <7GEnLP4Zqzr8PjggCXITqnTE6eMMMeKmBFJONfjdm_0=.8867cd6b-6197-430f-8b81-02416083240b@github.com> On Thu, 14 Apr 2022 17:05:39 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > revert changes on ProcessEnvironment src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java line 3: > 1: /* > 2: * Copyright (c) 2015, 2022, Oracle and/or its affiliates. All rights reserved. > 3: */ The LastModified tag was missing in this class. Pls use this opportunity to add it in the same format as the other classes (CoreDocumentImpl, XSAttributeChecker), that is after line 52. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From aturbanov at openjdk.java.net Thu Apr 14 18:09:34 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 14 Apr 2022 18:09:34 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Thu, 14 Apr 2022 10:38:33 GMT, Yi Yang wrote: >I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948), I wonder if you can merge this into your patch so that I do not need to submit a new PR for it? Thanks. I think it deserves a separate ticket. BTW there are a lot of other typos in JDK, especially in comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From aturbanov at openjdk.java.net Thu Apr 14 18:09:37 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 14 Apr 2022 18:09:37 GMT Subject: Integrated: 8284853: Fix various 'expected' typo In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote: > Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. This pull request has now been integrated. Changeset: 48c75498 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/48c75498060f076287d3d44c49934db9ac70887b Stats: 65 lines in 28 files changed: 0 ins; 0 del; 65 mod 8284853: Fix various 'expected' typo Reviewed-by: bpb, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From duke at openjdk.java.net Thu Apr 14 18:10:28 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 14 Apr 2022 18:10:28 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21] In-Reply-To: References: Message-ID: > 8186958: Need method to create pre-sized HashMap XenoAmess has updated the pull request incrementally with one additional commit since the last revision: add `@LastModified: Apr 2022` to DocumentCache ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7928/files - new: https://git.openjdk.java.net/jdk/pull/7928/files/5b437dab..71b7dba3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=19-20 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928 PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Apr 14 18:10:29 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 14 Apr 2022 18:10:29 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v20] In-Reply-To: <7GEnLP4Zqzr8PjggCXITqnTE6eMMMeKmBFJONfjdm_0=.8867cd6b-6197-430f-8b81-02416083240b@github.com> References: <7GEnLP4Zqzr8PjggCXITqnTE6eMMMeKmBFJONfjdm_0=.8867cd6b-6197-430f-8b81-02416083240b@github.com> Message-ID: On Thu, 14 Apr 2022 17:23:42 GMT, Joe Wang wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> revert changes on ProcessEnvironment > > src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java line 3: > >> 1: /* >> 2: * Copyright (c) 2015, 2022, Oracle and/or its affiliates. All rights reserved. >> 3: */ > > The LastModified tag was missing in this class. Pls use this opportunity to add it in the same format as the other classes (CoreDocumentImpl, XSAttributeChecker), that is after line 52. Thanks. @JoeWang-Java done. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From xuelei at openjdk.java.net Thu Apr 14 18:11:31 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 14 Apr 2022 18:11:31 GMT Subject: RFR: 8284796: sun.security.ssl.Finished::toString misses a line feed in the message format pattern In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 05:10:22 GMT, John Jiang wrote: > The log for Finished message looks like the below, > > "Finished": { > "verify data": { > 0000: ... ... > }'} // looks weird > > because a line feed is missing in the format pattern. > > ""Finished": '{'\n" + > " "verify data": '{'\n" + > "{0}\n" + > " '}'" + // a line feed is needed > "'}'", Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8215 From xuelei at openjdk.java.net Thu Apr 14 18:13:11 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 14 Apr 2022 18:13:11 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki Message-ID: This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. ------------- Commit messages: - 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki Changes: https://git.openjdk.java.net/jdk/pull/8248/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8248&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284855 Stats: 46 lines in 6 files changed: 10 ins; 21 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8248.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8248/head:pull/8248 PR: https://git.openjdk.java.net/jdk/pull/8248 From joehw at openjdk.java.net Thu Apr 14 18:25:32 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 14 Apr 2022 18:25:32 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 18:10:28 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > add `@LastModified: Apr 2022` to DocumentCache Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From joehw at openjdk.java.net Thu Apr 14 18:25:32 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 14 Apr 2022 18:25:32 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v20] In-Reply-To: References: <7GEnLP4Zqzr8PjggCXITqnTE6eMMMeKmBFJONfjdm_0=.8867cd6b-6197-430f-8b81-02416083240b@github.com> Message-ID: <1RTVIryM7sFw60Su-rO3CRvJh7c3O-F9cpIqVAg5etw=.31126d2c-6643-4e4a-865a-0579cd35616b@github.com> On Thu, 14 Apr 2022 18:05:48 GMT, XenoAmess wrote: >> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java line 3: >> >>> 1: /* >>> 2: * Copyright (c) 2015, 2022, Oracle and/or its affiliates. All rights reserved. >>> 3: */ >> >> The LastModified tag was missing in this class. Pls use this opportunity to add it in the same format as the other classes (CoreDocumentImpl, XSAttributeChecker), that is after line 52. Thanks. > > @JoeWang-Java done. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From naoto at openjdk.java.net Thu Apr 14 18:35:34 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 14 Apr 2022 18:35:34 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: <9Mjy2CA-ZYTC5v7KdhMuULeghdOSotPnUZnMIjxEplA=.cbf4cd73-5c1e-42d4-82a3-2e791e2af0f0@github.com> References: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> <0wlaWl-UQhwWw0Oe1JNW3JrpYKHahcEfrdbWjXOZ7Ic=.ab6c195a-f142-4aa2-824e-d4afe63a2e4c@github.com> <9Mjy2CA-ZYTC5v7KdhMuULeghdOSotPnUZnMIjxEplA=.cbf4cd73-5c1e-42d4-82a3-2e791e2af0f0@github.com> Message-ID: On Thu, 14 Apr 2022 17:06:53 GMT, XenoAmess wrote: >> Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856 > >> Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856 > > @stuart-marks @naotoj I can help solve JDK-8284856 after this pr. But usually we only solve 1 issue in 1 pr, so I think it's better to wait after this. Thanks. Will fix it myself, as I want to eliminate that immediate value in the code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From valeriep at openjdk.java.net Thu Apr 14 19:25:30 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 14 Apr 2022 19:25:30 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 18:06:10 GMT, Xue-Lei Andrew Fan wrote: > This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/.PKCS11.java.swp file should not be there? ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From ihse at openjdk.java.net Thu Apr 14 19:37:06 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 14 Apr 2022 19:37:06 GMT Subject: RFR: 8284893: Fix typos in java.base Message-ID: I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. (Due to false positives this can unfortunately not be run automatically) The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. ------------- Commit messages: - Pass #2 - 8284893: Fix typos in java.base Changes: https://git.openjdk.java.net/jdk/pull/8250/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8250&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284893 Stats: 268 lines in 180 files changed: 0 ins; 0 del; 268 mod Patch: https://git.openjdk.java.net/jdk/pull/8250.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8250/head:pull/8250 PR: https://git.openjdk.java.net/jdk/pull/8250 From dfuchs at openjdk.java.net Thu Apr 14 19:38:30 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 14 Apr 2022 19:38:30 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 18:06:10 GMT, Xue-Lei Andrew Fan wrote: > This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java line 168: > 166: // Calls disconnect() to cleanup the native part of the wrapper. > 167: Cleaner.create().register(this, > 168: () -> PKCS11.disconnect(pNativeData)); If I'm not mistaken each new call to Cleaner.create() will create a new cleaner and a new deamon thread for it, so it's not recommended to create one cleaner per object. Also it might be worth double checking that the lambda created here doesn't capture `this`: IIRC there were some subtle cases where a lambda could unexpectedly capture `this`. Also probably the cleaner itself can't be GC'ed while its thread is running but you might be relying on undocumented behavior. It would be more prudent to stick it in a static variable to retain a strong reference. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From mullan at openjdk.java.net Thu Apr 14 19:48:33 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 14 Apr 2022 19:48:33 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 19:27:00 GMT, Valerie Peng wrote: >> This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring. >> >> The CSR will be filed once review is somewhat finished. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update w/ review feedback. src/java.base/share/classes/javax/crypto/spec/OAEPParameterSpec.java line 113: > 111: > 112: // disallowed > 113: private OAEPParameterSpec() { I think you can just remove this ctor now that it is not used by `DEFAULT`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8191 From naoto at openjdk.java.net Thu Apr 14 19:51:29 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 14 Apr 2022 19:51:29 GMT Subject: RFR: 8284893: Fix typos in java.base In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. > > Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. src/java.base/share/classes/jdk/internal/icu/impl/NormalizerImpl.java line 2002: > 2000: } > 2001: > 2002: // this is where we are right now with all these indices: Although these are actual typos, they come from upstream ICU code. Changing them locally would make merging complicated, so please exclude ICU related changes from the PR. I guess fixes in other 3rd party libraries are in the same boat. ------------- PR: https://git.openjdk.java.net/jdk/pull/8250 From mullan at openjdk.java.net Thu Apr 14 19:58:49 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 14 Apr 2022 19:58:49 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 18:10:28 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > add `@LastModified: Apr 2022` to DocumentCache Right, we generally try to avoid making too many changes to the implementation code in the java.xml.crypto module in order to stay consistent with Apache Santuario. They also would not accept this change because it is a new API and they need to run on older releases. I haven't had time yet to understand this Enhancement, but are the changes necessary for this part? ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From wetmore at openjdk.java.net Thu Apr 14 19:58:48 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 14 Apr 2022 19:58:48 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 18:10:28 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > add `@LastModified: Apr 2022` to DocumentCache I learned something new about HashMap today... I looked at java.security.cert and sun.security.* and that part LGTM. That said, you need to check with @seanjmullan for the java.xml.crypto code. We try to keep the code in sync with the Apache code. As this is a new API, we probably can't push this kind of change to Apache as they need to support older releases. src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java line 110: > 108: int length = attributes.getLength(); > 109: Map namespaceMap = > 110: HashMap.newHashMap(length); Please check these changes with @seanjmullan before integrating. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7928 From iris at openjdk.java.net Thu Apr 14 20:04:29 2022 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 14 Apr 2022 20:04:29 GMT Subject: RFR: 8284893: Fix typos in java.base In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. > > Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. Looks good. I usually like GitHub's colorful diffs, but this is one of those rare cases where looking at the single webrev-generated diff file is so much easier. About the only thing that could improve it would be to reduce the context (i.e. "diff -C"). ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8250 From duke at openjdk.java.net Thu Apr 14 20:15:33 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 14 Apr 2022 20:15:33 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 18:10:28 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > add `@LastModified: Apr 2022` to DocumentCache > Are the changes necessary for this part? @seanjmullan no, they are just performance refinement. If you really that wanna 100% sync , I can use the old 1.8 api to migrate that part, and make a mirror pr to that part of https://github.com/apache/santuario-xml-security-java Is this solution acceptable then? ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From mullan at openjdk.java.net Thu Apr 14 20:20:33 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 14 Apr 2022 20:20:33 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 20:11:37 GMT, XenoAmess wrote: > > Are the changes necessary for this part? > > @seanjmullan no, they are just performance refinement. > > If you really that wanna 100% sync , > > I can use the old 1.8 api to migrate that part, and make a mirror pr to that part of https://github.com/apache/santuario-xml-security-java > > Is this solution acceptable then? Yes, that would be preferred. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From wetmore at openjdk.java.net Thu Apr 14 20:23:30 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 14 Apr 2022 20:23:30 GMT Subject: RFR: 8284893: Fix typos in java.base In-Reply-To: References: Message-ID: <4jUVElIYYvhwM9scNvI_4D6tfp5rcnuvSl5Pz969IqI=.29be0aa3-4db2-479c-8c44-71c299409f4b@github.com> On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. > > Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. I checked over: java.base/macosx/classes/apple/security java.base/share/classes/com/sun/crypto java.base/share/classes/com/sun/security java.base/share/classes/java/security java.base/share/classes/javax/crypto java.base/share/classes/javax/net java.base/share/classes/sun/security The copyright dates need updating. src/java.base/share/classes/sun/security/provider/certpath/AdjacencyList.java line 128: > 126: // Each time this method is called, we're examining a new list > 127: // from the global list. So, we have to start by getting the list > 128: // that contains the set of Vertices we're considering. The class being affected is a Vertex, so either change to vertices, or leave as is... ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8250 From smarks at openjdk.java.net Thu Apr 14 20:43:44 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 14 Apr 2022 20:43:44 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 19:53:45 GMT, Bradford Wetmore wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> add `@LastModified: Apr 2022` to DocumentCache > > I learned something new about HashMap today... > > I looked at java.security.cert and sun.security.* and that part LGTM. > > That said, you need to check with @seanjmullan for the java.xml.crypto code. We try to keep the code in sync with the Apache code. As this is a new API, we probably can't push this kind of change to Apache as they need to support older releases. Thanks @bradfordwetmore and @seanjmullan for looking at this, and @XenoAmess for following up quickly. To summarize, it sounds like the only issues are with the changes to two files in the `java.xml.crypto` area, as those need to be maintained in sync with Apache Santuario. Right? In both cases it looks like the HashMap is likely being under-allocated, so the fix would be to inline to capacity computation, something like `new HashMap<>((int) Math.ceil(length / 0.75))` I guess. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From naoto at openjdk.java.net Thu Apr 14 21:04:31 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 14 Apr 2022 21:04:31 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v18] In-Reply-To: References: <83dD1w2lWpo0serYy4URwBzDYkbsXSZtHMbafkSHe9Q=.1a45d190-2374-4e67-a0b7-3a0384479c3b@github.com> <0wlaWl-UQhwWw0Oe1JNW3JrpYKHahcEfrdbWjXOZ7Ic=.ab6c195a-f142-4aa2-824e-d4afe63a2e4c@github.com> <9Mjy2CA-ZYTC5v7KdhMuULeghdOSotPnUZnMIjxEplA=.cbf4cd73-5c1e-42d4-82a3-2e791e2af0f0@github.com> Message-ID: On Thu, 14 Apr 2022 18:32:03 GMT, Naoto Sato wrote: >>> Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856 >> >> @stuart-marks @naotoj I can help solve JDK-8284856 after this pr. But usually we only solve 1 issue in 1 pr, so I think it's better to wait after this. > > Thanks. Will fix it myself, as I want to eliminate that immediate value in the code. PR opened, based on this PR. https://github.com/openjdk/jdk/pull/8253 ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From djelinski at openjdk.java.net Thu Apr 14 21:05:06 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 14 Apr 2022 21:05:06 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v3] In-Reply-To: References: Message-ID: > During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. > > This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: - add more factory methods, update copyright - return DEFAULT also when user constraints are null ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8199/files - new: https://git.openjdk.java.net/jdk/pull/8199/files/b6e46ae9..e4cc8152 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8199&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8199&range=01-02 Stats: 65 lines in 6 files changed: 33 ins; 2 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/8199.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8199/head:pull/8199 PR: https://git.openjdk.java.net/jdk/pull/8199 From djelinski at openjdk.java.net Thu Apr 14 21:17:38 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 14 Apr 2022 21:17:38 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v3] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 21:05:06 GMT, Daniel Jeli?ski wrote: >> During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. >> >> This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - add more factory methods, update copyright > - return DEFAULT also when user constraints are null I think I addressed all the concerns raised. Could you take another look? ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From duke at openjdk.java.net Thu Apr 14 21:27:16 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 14 Apr 2022 21:27:16 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v22] In-Reply-To: References: Message-ID: <8BqTTnIZwmWPePWhmjea15skxDmEexP5ugH8H2PawtI=.79a6387d-4a4d-4867-94c0-6554e7b9b8ad@github.com> > 8186958: Need method to create pre-sized HashMap XenoAmess has updated the pull request incrementally with one additional commit since the last revision: java.xml.crypto's usage downgrade grammar to 1.8 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7928/files - new: https://git.openjdk.java.net/jdk/pull/7928/files/71b7dba3..95e22f25 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=20-21 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928 PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Apr 14 21:27:18 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 14 Apr 2022 21:27:18 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 19:56:22 GMT, Bradford Wetmore wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> add `@LastModified: Apr 2022` to DocumentCache > > src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java line 110: > >> 108: int length = attributes.getLength(); >> 109: Map namespaceMap = >> 110: HashMap.newHashMap(length); > > Please check these changes with @seanjmullan before integrating. @seanjmullan mirror pr in https://github.com/apache/santuario-xml-security-java/pull/64 jira at https://issues.apache.org/jira/projects/SANTUARIO/issues/SANTUARIO-586?filter=reportedbyme ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From xuelei at openjdk.java.net Thu Apr 14 22:01:55 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 14 Apr 2022 22:01:55 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v2] In-Reply-To: References: Message-ID: > This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: use static cleaner, and clean up swp file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8248/files - new: https://git.openjdk.java.net/jdk/pull/8248/files/898154b9..d9f4e00d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8248&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8248&range=00-01 Stats: 16 lines in 8 files changed: 5 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8248.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8248/head:pull/8248 PR: https://git.openjdk.java.net/jdk/pull/8248 From xuelei at openjdk.java.net Thu Apr 14 22:01:55 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 14 Apr 2022 22:01:55 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki In-Reply-To: References: Message-ID: <5BzdkH2ixSD9DXlzonj5VmuMCTDnIFUjfMp6G5j_8rg=.5c1f7169-6005-4d35-92e5-320fed171f14@github.com> On Thu, 14 Apr 2022 19:22:00 GMT, Valerie Peng wrote: > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/.PKCS11.java.swp file should not be there? Oops, I missed this swp file while using git commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From xuelei at openjdk.java.net Thu Apr 14 22:03:53 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 14 Apr 2022 22:03:53 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v2] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 19:26:53 GMT, Daniel Fuchs wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> use static cleaner, and clean up swp file > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java line 168: > >> 166: // Calls disconnect() to cleanup the native part of the wrapper. >> 167: Cleaner.create().register(this, >> 168: () -> PKCS11.disconnect(pNativeData)); > > If I'm not mistaken each new call to Cleaner.create() will create a new cleaner and a new deamon thread for it, so it's not recommended to create one cleaner per object. > Also it might be worth double checking that the lambda created here doesn't capture `this`: IIRC there were some subtle cases where a lambda could unexpectedly capture `this`. > > Also probably the cleaner itself can't be GC'ed while its thread is running but you might be relying on undocumented behavior. It would be more prudent to stick it in a static variable to retain a strong reference. Good points. I may change to use a static method instead in the next commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From bchristi at openjdk.java.net Thu Apr 14 22:35:38 2022 From: bchristi at openjdk.java.net (Brent Christian) Date: Thu, 14 Apr 2022 22:35:38 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v2] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 22:01:55 GMT, Xue-Lei Andrew Fan wrote: >> This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > use static cleaner, and clean up swp file Thanks for updating this. Can a test case be included? While it doesn't _seem_ like `this` would need to be captured for these lambdas, it's good to be sure -- now, and in the future. If test code could access a PKCS11 instance, the WeakHashMap technique from [PR 8136](https://github.com/openjdk/jdk/pull/8136#issuecomment-1092881171) could be used. The same goes for P11KeyStore (well, a `PasswordCallbackHandler` instance, in that case). But I don't know how practical it would be for test code to get access to those objects. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From bchristi at openjdk.java.net Thu Apr 14 22:35:39 2022 From: bchristi at openjdk.java.net (Brent Christian) Date: Thu, 14 Apr 2022 22:35:39 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v2] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 22:01:18 GMT, Xue-Lei Andrew Fan wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java line 168: >> >>> 166: // Calls disconnect() to cleanup the native part of the wrapper. >>> 167: Cleaner.create().register(this, >>> 168: () -> PKCS11.disconnect(pNativeData)); >> >> If I'm not mistaken each new call to Cleaner.create() will create a new cleaner and a new deamon thread for it, so it's not recommended to create one cleaner per object. >> Also it might be worth double checking that the lambda created here doesn't capture `this`: IIRC there were some subtle cases where a lambda could unexpectedly capture `this`. >> >> Also probably the cleaner itself can't be GC'ed while its thread is running but you might be relying on undocumented behavior. It would be more prudent to stick it in a static variable to retain a strong reference. > > Good points. I may change to use a static method instead in the next commit. The new Cleaner code for PasswordCallbackHandler in P11KeyStore.java also creates a new Cleaner instance per object. Possible capture of 'this' is one reason I find `Runnable`s written out as static classes easier reason about than lambdas. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From duke at openjdk.java.net Thu Apr 14 22:37:39 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 14 Apr 2022 22:37:39 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v2] 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: fourth iteration ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7746/files - new: https://git.openjdk.java.net/jdk/pull/7746/files/fb0b7f16..e4292aef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7746&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7746&range=00-01 Stats: 63 lines in 10 files changed: 13 ins; 0 del; 50 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 valeriep at openjdk.java.net Thu Apr 14 23:42:40 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 14 Apr 2022 23:42:40 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: <-MtXAGbG5oCJcC5c2TtDnBIai9lefYrB61Op95fcWqc=.e6a9526a-2274-4a2f-ae5a-56c0cdf29f8d@github.com> On Wed, 13 Apr 2022 22:04:03 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 incrementally with one additional commit since the last revision: > > Update w/ review feedbacks CSR is filed at: https://bugs.openjdk.java.net/browse/JDK-8284897 Please review, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From jjiang at openjdk.java.net Fri Apr 15 02:13:42 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Fri, 15 Apr 2022 02:13:42 GMT Subject: RFR: 8284796: sun.security.ssl.Finished::toString misses a line feed in the message format pattern In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 18:08:21 GMT, Xue-Lei Andrew Fan wrote: >> The log for Finished message looks like the below, >> >> "Finished": { >> "verify data": { >> 0000: ... ... >> }'} // looks weird >> >> because a line feed is missing in the format pattern. >> >> ""Finished": '{'\n" + >> " "verify data": '{'\n" + >> "{0}\n" + >> " '}'" + // a line feed is needed >> "'}'", > > Marked as reviewed by xuelei (Reviewer). @XueleiFan Thanks for your approval! ------------- PR: https://git.openjdk.java.net/jdk/pull/8215 From jjiang at openjdk.java.net Fri Apr 15 02:13:42 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Fri, 15 Apr 2022 02:13:42 GMT Subject: Integrated: 8284796: sun.security.ssl.Finished::toString misses a line feed in the message format pattern In-Reply-To: References: Message-ID: <94VERog-v-mceF3sscL2ga4wvL60PkJzl3YZeufQ5Iw=.c79f32ee-20fd-461c-bd64-b50d9e7229f4@github.com> On Wed, 13 Apr 2022 05:10:22 GMT, John Jiang wrote: > The log for Finished message looks like the below, > > "Finished": { > "verify data": { > 0000: ... ... > }'} // looks weird > > because a line feed is missing in the format pattern. > > ""Finished": '{'\n" + > " "verify data": '{'\n" + > "{0}\n" + > " '}'" + // a line feed is needed > "'}'", This pull request has now been integrated. Changeset: d9708206 Author: John Jiang URL: https://git.openjdk.java.net/jdk/commit/d9708206164a0b7bfe611b597b49c5e75c37ad47 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8284796: sun.security.ssl.Finished::toString misses a line feed in the message format pattern Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/8215 From xuelei at openjdk.java.net Fri Apr 15 07:20:42 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 15 Apr 2022 07:20:42 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v3] In-Reply-To: References: Message-ID: > This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Don't use lambda in cleaner ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8248/files - new: https://git.openjdk.java.net/jdk/pull/8248/files/d9f4e00d..cdd609c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8248&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8248&range=01-02 Stats: 14 lines in 1 file changed: 11 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8248.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8248/head:pull/8248 PR: https://git.openjdk.java.net/jdk/pull/8248 From duke at openjdk.java.net Fri Apr 15 07:29:50 2022 From: duke at openjdk.java.net (Markus KARG) Date: Fri, 15 Apr 2022 07:29:50 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 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 Actually the Windows API is using a reverse naming system, so I would propose the following changes: * MY and ROOT become marked as deprecated in both, the source code and all documentation, so in future there won't be any confusion anymore what store these actually do access. * Following the Windows naming system and make the syntax more logical, I propose the new store names are `Windows:LOCALMACHINE/MY` , `Windows:LOCALMACHINE/ROOT`, `Windows:CURRENTUSER/MY` and `Windows:CURRENTUSER/ROOT`. The colon is commonly well-understood as a separator between schemes and names, and the slash is commonly understood as a path separator. So this new syntax makes usage much cleaner. ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From aturbanov at openjdk.java.net Fri Apr 15 08:14:39 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Fri, 15 Apr 2022 08:14:39 GMT Subject: RFR: 8284893: Fix typos in java.base In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. > > Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. Shouldn't copyright year be updated too? ------------- PR: https://git.openjdk.java.net/jdk/pull/8250 From dfuchs at openjdk.java.net Fri Apr 15 08:28:39 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 15 Apr 2022 08:28:39 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:20:42 GMT, Xue-Lei Andrew Fan wrote: >> This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Don't use lambda in cleaner src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java line 235: > 233: this.password = password.clone(); > 234: P11Util.cleaner.register(this, > 235: () -> Arrays.fill(this.password, ' ')); This lambda most probably capture `this` so it will create a leak. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From prappo at openjdk.java.net Fri Apr 15 11:46:44 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 15 Apr 2022 11:46:44 GMT Subject: RFR: 8284893: Fix typos in java.base In-Reply-To: References: Message-ID: <8o1t-S3XFlxllM9gYtF5EHcMmby8_6RQxCxi86ndGfY=.b9d04f24-288e-4095-bdcb-41ea5efda852@github.com> On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. > > Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. src/java.base/share/legal/icu.md line 310: > 308: # list of conditions and the following disclaimer. Redistributions in binary > 309: # form must reproduce the above copyright notice, this list of conditions and > 310: # the following disclaimer in the documentation and/or the materials I think it's a mistype of "other", not "the"; look at the similar text below. src/java.base/share/native/libzip/zlib/ChangeLog line 99: > 97: - Simplify contrib/vstudio/vc10 with 'd' suffix > 98: - Add TOP support to win32/Makefile.msc > 99: - Support i686 and amd64 assembler builds in CMakeLists.txt Similarly to Naoto's comment on ICU: shouldn't we leave this as is? If anybody cares enough about this typo, they could file a bug against zlib directly. src/java.base/share/native/libzip/zlib/README line 67: > 65: when compiled with cc. > 66: > 67: - On Digital Unix 4.0D (formerly OSF/1) on AlphaServer, the cc option -std1 is Same as above. ------------- PR: https://git.openjdk.java.net/jdk/pull/8250 From prappo at openjdk.java.net Fri Apr 15 11:50:39 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 15 Apr 2022 11:50:39 GMT Subject: RFR: 8284893: Fix typos in java.base In-Reply-To: <8o1t-S3XFlxllM9gYtF5EHcMmby8_6RQxCxi86ndGfY=.b9d04f24-288e-4095-bdcb-41ea5efda852@github.com> References: <8o1t-S3XFlxllM9gYtF5EHcMmby8_6RQxCxi86ndGfY=.b9d04f24-288e-4095-bdcb-41ea5efda852@github.com> Message-ID: On Fri, 15 Apr 2022 11:25:09 GMT, Pavel Rappo wrote: >> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. >> >> (Due to false positives this can unfortunately not be run automatically) >> >> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. >> >> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. > > src/java.base/share/legal/icu.md line 310: > >> 308: # list of conditions and the following disclaimer. Redistributions in binary >> 309: # form must reproduce the above copyright notice, this list of conditions and >> 310: # the following disclaimer in the documentation and/or the materials > > I think it's a mistype of "other", not "the"; look at the similar text below. Should be addressed on the ICU side. ------------- PR: https://git.openjdk.java.net/jdk/pull/8250 From alanb at openjdk.java.net Fri Apr 15 13:09:39 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 15 Apr 2022 13:09:39 GMT Subject: RFR: 8284893: Fix typos in java.base In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. > > Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. I skimmed through the changes to src/java.base and they look okay except for the changes to 3rd party code that I think should be dropped from this patch. src/java.base/share/native/libzip/zlib/inftrees.h line 65: > 63: 1444, which is the sum of 852 for literal/length codes and 592 for distance > 64: codes. These values were found by exhaustive searches using the program > 65: examples/enough.c found in the zlib distribution. The arguments to that This is 3rd party code so should be dropped from the patch as we want as few changes to this code has possible. src/java.base/windows/native/libnio/ch/wepoll.c line 894: > 892: * error code when the once-callback returns FALSE. We return -1 here to > 893: * indicate that global initialization failed; the failing init function is > 894: * responsible for setting `errno` and calling `SetLastError()`. */ This is also 3rd party code so should be dropped from this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/8250 From duke at openjdk.java.net Fri Apr 15 13:35:39 2022 From: duke at openjdk.java.net (altrisi) Date: Fri, 15 Apr 2022 13:35:39 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v3] In-Reply-To: References: Message-ID: <5hd2Qm1t-nBD8r7TFUUmyE3D0los1TuANvxCPhrZD8M=.2873d8db-29ef-4f41-ac07-3e5815df2960@github.com> On Fri, 15 Apr 2022 07:20:42 GMT, Xue-Lei Andrew Fan wrote: >> This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Don't use lambda in cleaner Can't this use `CleanerFactory.cleaner()` and reuse the common Cleaner instead of having its own? ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From xuelei at openjdk.java.net Fri Apr 15 15:04:20 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 15 Apr 2022 15:04:20 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v4] In-Reply-To: References: Message-ID: > This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: more update on replace lambda ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8248/files - new: https://git.openjdk.java.net/jdk/pull/8248/files/cdd609c1..ec1641ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8248&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8248&range=02-03 Stats: 8 lines in 1 file changed: 6 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8248.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8248/head:pull/8248 PR: https://git.openjdk.java.net/jdk/pull/8248 From xuelei at openjdk.java.net Fri Apr 15 15:04:21 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 15 Apr 2022 15:04:21 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v3] In-Reply-To: <5hd2Qm1t-nBD8r7TFUUmyE3D0los1TuANvxCPhrZD8M=.2873d8db-29ef-4f41-ac07-3e5815df2960@github.com> References: <5hd2Qm1t-nBD8r7TFUUmyE3D0los1TuANvxCPhrZD8M=.2873d8db-29ef-4f41-ac07-3e5815df2960@github.com> Message-ID: On Fri, 15 Apr 2022 13:32:10 GMT, altrisi wrote: > Can't this use `CleanerFactory.cleaner()` and reuse the common Cleaner instead of having its own? CleanerFactory is in java.base module, and does not export to jdk.crypto.cryptoki module. I'm not sure if adding modules dependency is good or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From xuelei at openjdk.java.net Fri Apr 15 15:04:22 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 15 Apr 2022 15:04:22 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 08:25:40 GMT, Daniel Fuchs wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't use lambda in cleaner > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java line 235: > >> 233: this.password = password.clone(); >> 234: P11Util.cleaner.register(this, >> 235: () -> Arrays.fill(this.password, ' ')); > > This lambda most probably capture `this` so it will create a leak. I was wondering to fix it in another PR as there is another issue in the block. Better to fix it sooner. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From xuelei at openjdk.java.net Fri Apr 15 15:06:29 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 15 Apr 2022 15:06:29 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v2] In-Reply-To: References: Message-ID: <4qULEq1AyNi2G6KtQa3twZjGkww9c3Oi7jaj0w7qDVQ=.4dac1e3e-1fb3-4a56-a217-1541dc715051@github.com> On Thu, 14 Apr 2022 22:32:23 GMT, Brent Christian wrote: > Can a test case be included? The classes updated are not public. I'm still looking for the way to expose the reference of them. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From dfuchs at openjdk.java.net Fri Apr 15 15:19:39 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 15 Apr 2022 15:19:39 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v4] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 15:04:20 GMT, Xue-Lei Andrew Fan wrote: >> This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > more update on replace lambda The latest updates LGTM. I have only looked at the generic Cleaner usage side of things - you will need someone from the security-libs team to have a look at the security-libs implementation logic... ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From rriggs at openjdk.java.net Fri Apr 15 15:28:54 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 15 Apr 2022 15:28:54 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v4] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 15:04:20 GMT, Xue-Lei Andrew Fan wrote: >> This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > more update on replace lambda src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java line 117: > 115: > 116: // Note: Please don't update this field other than the constructor. > 117: // Otherwise, the native data is not able to be collected. If it is only set in the constructor, it can be 'final". src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java line 235: > 233: * and any subsequent calls to C_ methods will fail. This method is for > 234: * internal use only. Please don't use this method other than finalization. > 235: * Perhaps refer to the code in which the cleanup occurs. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From xuelei at openjdk.java.net Fri Apr 15 15:50:20 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 15 Apr 2022 15:50:20 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v4] In-Reply-To: References: Message-ID: <8l10EC8P_P7h47T4hynnkPBNk--qexQtU5r-Bq5DC2A=.84a5085d-0445-4e4b-8dbb-14e9b4b3fea2@github.com> On Fri, 15 Apr 2022 15:23:33 GMT, Roger Riggs wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> more update on replace lambda > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java line 117: > >> 115: >> 116: // Note: Please don't update this field other than the constructor. >> 117: // Otherwise, the native data is not able to be collected. > > If it is only set in the constructor, it can be 'final". I would prefer to use 'final'. But this field is set by JNI code. I'm not very sure of the impact if declaring it as final field. > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java line 235: > >> 233: * and any subsequent calls to C_ methods will fail. This method is for >> 234: * internal use only. Please don't use this method other than finalization. >> 235: * > > Perhaps refer to the code in which the cleanup occurs. Good point! A reference to the releaserFor() method is added. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From xuelei at openjdk.java.net Fri Apr 15 15:50:19 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 15 Apr 2022 15:50:19 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v5] In-Reply-To: References: Message-ID: > This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: add a reference to the clean up method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8248/files - new: https://git.openjdk.java.net/jdk/pull/8248/files/ec1641ae..650bcb9b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8248&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8248&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8248.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8248/head:pull/8248 PR: https://git.openjdk.java.net/jdk/pull/8248 From mullan at openjdk.java.net Fri Apr 15 17:33:40 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 15 Apr 2022 17:33:40 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 22:04:03 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 incrementally with one additional commit since the last revision: > > Update w/ review feedbacks src/java.base/share/classes/javax/crypto/Cipher.java line 1054: > 1052: * this cipher, or may contain additional default or random parameter > 1053: * values used by the underlying cipher implementation if this cipher can > 1054: * successfully generate the required parameter values when not supplied. A few comments: 1. 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 ..." 2. Should `Signature.getParameters` be updated to be consistent? Are there any cases, or could there be, where a signature provider may return additional parameters other than what the user specified? ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From valeriep at openjdk.java.net Fri Apr 15 17:47:52 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 15 Apr 2022 17:47:52 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v5] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 15:50:19 GMT, Xue-Lei Andrew Fan wrote: >> This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > add a reference to the clean up method src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c line 265: > 263: * Class: sun_security_pkcs11_wrapper_PKCS11 > 264: * Method: disconnect > 265: * Signature: ()V nit: update the JNI method signature? Same for all other p11_md.c for different OS... ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From valeriep at openjdk.java.net Fri Apr 15 17:54:37 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 15 Apr 2022 17:54:37 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v5] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 15:50:19 GMT, Xue-Lei Andrew Fan wrote: >> This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > add a reference to the clean up method src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c line 274: > 272: ModuleData *moduleData = jlong_to_ptr(ckpNativeData); > 273: > 274: if (moduleData != NULL) { The check should be (moduleData->hModule != NULL)? ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From mullan at openjdk.java.net Fri Apr 15 18:12:51 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 15 Apr 2022 18:12:51 GMT Subject: RFR: 8284893: Fix typos in java.base In-Reply-To: <4jUVElIYYvhwM9scNvI_4D6tfp5rcnuvSl5Pz969IqI=.29be0aa3-4db2-479c-8c44-71c299409f4b@github.com> References: <4jUVElIYYvhwM9scNvI_4D6tfp5rcnuvSl5Pz969IqI=.29be0aa3-4db2-479c-8c44-71c299409f4b@github.com> Message-ID: On Thu, 14 Apr 2022 20:16:21 GMT, Bradford Wetmore wrote: >> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. >> >> (Due to false positives this can unfortunately not be run automatically) >> >> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. >> >> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. > > src/java.base/share/classes/sun/security/provider/certpath/AdjacencyList.java line 128: > >> 126: // Each time this method is called, we're examining a new list >> 127: // from the global list. So, we have to start by getting the list >> 128: // that contains the set of Vertices we're considering. > > The class being affected is a Vertex, so either change to vertices, or leave as is... Agree, suggest changing it to "vertices". ------------- PR: https://git.openjdk.java.net/jdk/pull/8250 From bchristi at openjdk.java.net Fri Apr 15 18:51:38 2022 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 15 Apr 2022 18:51:38 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v3] In-Reply-To: References: <5hd2Qm1t-nBD8r7TFUUmyE3D0los1TuANvxCPhrZD8M=.2873d8db-29ef-4f41-ac07-3e5815df2960@github.com> Message-ID: On Fri, 15 Apr 2022 15:00:18 GMT, Xue-Lei Andrew Fan wrote: > > CleanerFactory is in java.base module, and does not export to jdk.crypto.cryptoki module. I'm not sure if adding modules dependency is good or not. It seems fine to me to export the common Cleaner to `jdk.crypto.cryptoki`. It's already [exported for desktop and Panama](https://github.com/bchristi-git/jdk/blob/master/src/java.base/share/classes/module-info.java#L226), and I see that [com.sun.crypto.provider](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/com/sun/crypto/provider/DESKey.java#L84) already uses it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From valeriep at openjdk.java.net Fri Apr 15 22:14:40 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 15 Apr 2022 22:14:40 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 19:27:00 GMT, Valerie Peng wrote: >> This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring. >> >> The CSR will be filed once review is somewhat finished. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update w/ review feedback. CSR filed at: https://bugs.openjdk.java.net/browse/JDK-8284919 ------------- PR: https://git.openjdk.java.net/jdk/pull/8191 From duke at openjdk.java.net Fri Apr 15 23:32:11 2022 From: duke at openjdk.java.net (Mark Powers) Date: Fri, 15 Apr 2022 23:32:11 GMT Subject: RFR: JDK-8284112 Minor cleanup could be done in javax.crypto [v3] In-Reply-To: References: Message-ID: > JDK-8284112 Minor cleanup could be done in javax.crypto Mark Powers has updated the pull request incrementally with one additional commit since the last revision: cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8214/files - new: https://git.openjdk.java.net/jdk/pull/8214/files/86a546bc..3c123c32 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8214&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8214&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8214.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8214/head:pull/8214 PR: https://git.openjdk.java.net/jdk/pull/8214 From peter.firmstone at zeus.net.au Sat Apr 16 02:46:46 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 16 Apr 2022 12:46:46 +1000 Subject: Command line flag to disable finalizers. In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: To securely instrument access controls onto public Java API, we need to have the ability to disable finalizers, to prevent finalizer attacks from circumventing access controls. Since finalizers are planned for removal, as soon as finalizers are officially deprecated, I propose a command line flag be provided to disable jvm calls to finalizer methods. -- Regards, Peter Firmstone. From xuelei at openjdk.java.net Sat Apr 16 05:27:42 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 16 Apr 2022 05:27:42 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v5] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 17:44:08 GMT, Valerie Peng wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> add a reference to the clean up method > > src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c line 265: > >> 263: * Class: sun_security_pkcs11_wrapper_PKCS11 >> 264: * Method: disconnect >> 265: * Signature: ()V > > nit: update the JNI method signature? Same for the other p11_md.c for different OS... Yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From xuelei at openjdk.java.net Sat Apr 16 05:31:40 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 16 Apr 2022 05:31:40 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v5] In-Reply-To: References: Message-ID: <09nZBWUg9qc9kFIJvVfx0BnzyyVp3t2bAJlKV1wQt28=.12a424f0-81fb-4b53-91cd-c7cec9ffdea8@github.com> On Fri, 15 Apr 2022 17:51:43 GMT, Valerie Peng wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> add a reference to the clean up method > > src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c line 274: > >> 272: ModuleData *moduleData = jlong_to_ptr(ckpNativeData); >> 273: >> 274: if (moduleData != NULL) { > > The check should be (moduleData->hModule != NULL)? Same goes for the other p11_md.c file. I think it is safer to add the check for 'hModule'. - if (moduleData != NULL) { + if (moduleData != NULL && moduleData->hModule != NULL) { ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From xuelei at openjdk.java.net Sat Apr 16 05:35:20 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 16 Apr 2022 05:35:20 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v6] In-Reply-To: References: Message-ID: > This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Update signatures for native code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8248/files - new: https://git.openjdk.java.net/jdk/pull/8248/files/650bcb9b..71b957fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8248&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8248&range=04-05 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8248.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8248/head:pull/8248 PR: https://git.openjdk.java.net/jdk/pull/8248 From xuelei at openjdk.java.net Sat Apr 16 05:38:40 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 16 Apr 2022 05:38:40 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v3] In-Reply-To: References: <5hd2Qm1t-nBD8r7TFUUmyE3D0los1TuANvxCPhrZD8M=.2873d8db-29ef-4f41-ac07-3e5815df2960@github.com> Message-ID: On Fri, 15 Apr 2022 18:48:33 GMT, Brent Christian wrote: >>> CleanerFactory is in java.base module, and does not export to jdk.crypto.cryptoki module. I'm not sure if adding modules dependency is good or not. > > It seems fine to me to export the common Cleaner to `jdk.crypto.cryptoki`. It's already [exported for desktop and Panama](https://github.com/bchristi-git/jdk/blob/master/src/java.base/share/classes/module-info.java#L226), and I see that [com.sun.crypto.provider](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/com/sun/crypto/provider/DESKey.java#L84) already uses it. There are several places that don't use CleanerFactory here and there. I may fill a new PR later for this purpose. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From duke at openjdk.java.net Sat Apr 16 10:26:42 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sat, 16 Apr 2022 10:26:42 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v22] In-Reply-To: <8BqTTnIZwmWPePWhmjea15skxDmEexP5ugH8H2PawtI=.79a6387d-4a4d-4867-94c0-6554e7b9b8ad@github.com> References: <8BqTTnIZwmWPePWhmjea15skxDmEexP5ugH8H2PawtI=.79a6387d-4a4d-4867-94c0-6554e7b9b8ad@github.com> Message-ID: On Thu, 14 Apr 2022 21:27:16 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > java.xml.crypto's usage downgrade grammar to 1.8 So is there any other things we should do before calling bot to integrate? ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From jjiang at openjdk.java.net Sat Apr 16 14:06:02 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Sat, 16 Apr 2022 14:06:02 GMT Subject: RFR: 8284926: Share the certificate NamedGroup in SignatureScheme::getSignerOfPreferableAlgorithm Message-ID: It would not to generate the certificate's ECParameterSpec and NamedGroup multiple times in method `SignatureScheme::getSignerOfPreferableAlgorithm`. ------------- Commit messages: - 8284926: Share the certificate NamedGroup in SignatureScheme::getSignerOfPreferableAlgorithm Changes: https://git.openjdk.java.net/jdk/pull/8271/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8271&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284926 Stats: 19 lines in 1 file changed: 5 ins; 8 del; 6 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 duke at openjdk.java.net Sat Apr 16 14:41:36 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sat, 16 Apr 2022 14:41:36 GMT Subject: RFR: 8284926: Share the certificate NamedGroup in SignatureScheme::getSignerOfPreferableAlgorithm In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 13:59:25 GMT, John Jiang wrote: > It would not to generate the certificate's ECParameterSpec and NamedGroup multiple times in method `SignatureScheme::getSignerOfPreferableAlgorithm`. src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 494: > 492: x509Possession.getECParameterSpec(); > 493: if (params != null && > 494: ss.namedGroup == NamedGroup.valueOf(params)) { look at here. if : param == null and namedGroup == null and ss.namedGroup == null, the codes before this change will not enter the if branch, but the codes after this changes will enter the if branch. ------------- PR: https://git.openjdk.java.net/jdk/pull/8271 From xuelei at openjdk.java.net Sat Apr 16 15:52:58 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 16 Apr 2022 15:52:58 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback Message-ID: Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. ------------- Commit messages: - 8284910: Buffer clean in PasswordCallback Changes: https://git.openjdk.java.net/jdk/pull/8272/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284910 Stats: 142 lines in 3 files changed: 136 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8272/head:pull/8272 PR: https://git.openjdk.java.net/jdk/pull/8272 From jjiang at openjdk.java.net Sat Apr 16 23:52:31 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Sat, 16 Apr 2022 23:52:31 GMT Subject: RFR: 8284926: Share the certificate NamedGroup in SignatureScheme::getSignerOfPreferableAlgorithm In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 14:38:09 GMT, XenoAmess wrote: >> It would not to generate the certificate's ECParameterSpec and NamedGroup multiple times in method `SignatureScheme::getSignerOfPreferableAlgorithm`. > > src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 494: > >> 492: x509Possession.getECParameterSpec(); >> 493: if (params != null && >> 494: ss.namedGroup == NamedGroup.valueOf(params)) { > > look at here. > if : param == null and namedGroup == null and ss.namedGroup == null, > the codes before this change will not enter the if branch, but the codes after this changes will enter the if branch. ss.namedGroup should not be null here. The previous if statement already checks that: if ((ss.namedGroup != null) && (ss.namedGroup.spec == NamedGroupSpec.NAMED_GROUP_ECDHE)) { ------------- PR: https://git.openjdk.java.net/jdk/pull/8271 From xuelei at openjdk.java.net Sun Apr 17 14:52:02 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 17 Apr 2022 14:52:02 GMT Subject: RFR: 8284933: Improve debug in jdk.crypto.cryptoki Message-ID: Hi, May I have the simple update reviewed? In the jdk.crypto.cryptoki module implementation, some of the debug information could be calculated even if the debug is not enabled, which is not resource friendly. Thanks, Xuelei ------------- Commit messages: - 8284933: Improve debug in jdk.crypto.cryptoki Changes: https://git.openjdk.java.net/jdk/pull/8277/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8277&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284933 Stats: 34 lines in 1 file changed: 20 ins; 2 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/8277.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8277/head:pull/8277 PR: https://git.openjdk.java.net/jdk/pull/8277 From xuelei at openjdk.java.net Sun Apr 17 15:04:30 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 17 Apr 2022 15:04:30 GMT Subject: RFR: 8284926: Share the certificate NamedGroup in SignatureScheme::getSignerOfPreferableAlgorithm In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 13:59:25 GMT, John Jiang wrote: > It would not to generate the certificate's ECParameterSpec and NamedGroup multiple times in method `SignatureScheme::getSignerOfPreferableAlgorithm`. src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 479: > 477: NamedGroup namedGroup = params != null > 478: ? NamedGroup.valueOf(params) : null; > 479: X509Possession.java might be a better place for the update, by caching the named group of the private key. ------------- PR: https://git.openjdk.java.net/jdk/pull/8271 From duke at openjdk.java.net Sun Apr 17 16:24:13 2022 From: duke at openjdk.java.net (liach) Date: Sun, 17 Apr 2022 16:24:13 GMT Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes Message-ID: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building. The main compatibility changes and their rationales are: 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior. - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes. - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain. - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe. 2. The disappearance of proxies in stack traces. - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic. A summary of the rest of the changes: 1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well. 2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups. 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance. In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)? Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed. ------------- Commit messages: - Change proxy serialization to work with hidden classes (require spec update) - Formatting - Move to hidden class and methods in class data - Implement anchors and remove proxyClassLookup factory Changes: https://git.openjdk.java.net/jdk/pull/8278/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8278&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242888 Stats: 400 lines in 6 files changed: 122 ins; 222 del; 56 mod Patch: https://git.openjdk.java.net/jdk/pull/8278.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8278/head:pull/8278 PR: https://git.openjdk.java.net/jdk/pull/8278 From peter.firmstone at zeus.net.au Sun Apr 17 23:51:54 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 18 Apr 2022 09:51:54 +1000 Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> Message-ID: <8c88f789-c842-bda7-d97c-9cd808b9a082@zeus.net.au> We re-implemented a subset of Java Serialization, prior to the creation Java serialization filters.? Field types are read ahead from the stream and invariant's validated during construction for failure atomicity (a special constructor signature is used for deserialization), there are also stream limits that require periodical stream resets, to avoid million laugh style attacks. Also the source of the serialized data must be authenticated before permission is granted for parsing serial data.?? We also removed the ability to deserialize object graphs with circular links. This is used for an Remove invocation framework called JERI (Jini extensible remote invocation).? Serialization has been given a public API to allow extensibility, that is to allow other serialization protocols to be used via configuration, using a Serialization layer. Service and service discovery architecture makes use of JERI, for marshaling object parameters securely over the network, for remote method calls on services, via remote proxy's. The way that JERI serializes proxy's has changed significantly since Jini, instead of marshaling proxy's, a bootstrap proxy (local code only) is marshaled first, the client first authenticates the connection, the bootstrap proxy is used to provide information for dynamic downloading of any required jar files, or wiring of dependencies prior to the unmarshaling of the service proxy.? Unlike Java RMI, which uses RMIClassLoading for class resolution, each Jeri Endpoint is assigned a ClassLoader for class resolution during deserialization / object unmarshaling, this solves the OSGi deserialzation class resolution problem. https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io/ProxySerializer.java https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io/AtomicMarshalInputStream.java#L2263 https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io/AtomicMarshalInputStream.java#L853 Would be nice to do some testing with the changes. -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. On 18/04/2022 2:24 am, liach wrote: > Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building. > > The main compatibility changes and their rationales are: > 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior. > - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes. > - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain. > - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe. > 2. The disappearance of proxies in stack traces. > - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic. > > A summary of the rest of the changes: > 1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well. > 2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups. > 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance. > > In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)? > > Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed. > > ------------- > > Commit messages: > - Change proxy serialization to work with hidden classes (require spec update) > - Formatting > - Move to hidden class and methods in class data > - Implement anchors and remove proxyClassLookup factory > > Changes: https://git.openjdk.java.net/jdk/pull/8278/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8278&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8242888 > Stats: 400 lines in 6 files changed: 122 ins; 222 del; 56 mod > Patch: https://git.openjdk.java.net/jdk/pull/8278.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/8278/head:pull/8278 > > PR: https://git.openjdk.java.net/jdk/pull/8278 From xuelei at openjdk.java.net Mon Apr 18 04:46:59 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 18 Apr 2022 04:46:59 GMT Subject: RFR: 8284935: Improve debug in java.security.jgss Message-ID: <9E_5-kKQyokmeBxAy4TNKsDJTpKbCorJT2_vNREzJxs=.a9cd5583-ed0b-409e-94e7-d7c9dd6d3d50@github.com> Hi, May I have the simple update reviewed? In the java.security.jgss module implementation, some of the debug information could be generated even if debugging is not enabled, which is not resource friendly. Thanks, Xuelei ------------- Commit messages: - 8284935: Improve debug in java.security.jgss Changes: https://git.openjdk.java.net/jdk/pull/8279/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8279&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284935 Stats: 98 lines in 7 files changed: 40 ins; 16 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/8279.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8279/head:pull/8279 PR: https://git.openjdk.java.net/jdk/pull/8279 From svkamath at openjdk.java.net Mon Apr 18 05:13:14 2022 From: svkamath at openjdk.java.net (Smita Kamath) Date: Mon, 18 Apr 2022 05:13:14 GMT Subject: RFR: 8283022: com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java failing with -Xcomp after 8273297 Message-ID: When input length provided to the intrinsic is 8192, only 7680 bytes are processed as the intrinsic operates on multiples of 768 bytes. In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method, dst.put(bout, 0, PARALLEL_LEN) statement caused the ciphertext mismatch as PARALLEL_LEN was set to 8192. Since the intrinsic only processed 7680 bytes, the rest output was incorrect. ------------- Commit messages: - Changed PARALLEL_LEN to 7680 as intrinsic processes multiples of 768 bytes Changes: https://git.openjdk.java.net/jdk/pull/8280/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8280&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283022 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8280.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8280/head:pull/8280 PR: https://git.openjdk.java.net/jdk/pull/8280 From duke at openjdk.java.net Mon Apr 18 05:20:28 2022 From: duke at openjdk.java.net (liach) Date: Mon, 18 Apr 2022 05:20:28 GMT Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> Message-ID: On Sun, 17 Apr 2022 16:17:30 GMT, liach wrote: > Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building. > > The main compatibility changes and their rationales are: > 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior. > - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes. > - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain. > - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe. > 2. The disappearance of proxies in stack traces. > - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic. > > A summary of the rest of the changes: > 1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well. > 2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups. > 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance. > > In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)? > > Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed. I now think that this should be split into probably four separate patches: 1. Merge the 2 passes of scanning interfaces, and store the exported/non-exported package within the classloader value info for dynamic modules 2. Use the JLIA access to obtain lookup than spin an accessor in every proxy class 3. Update serialization constructor generation to use method handles (as in #1830) for hidden classes, don't change the serialization specs for now, as it affects security. And finally, convert proxies to hidden classes like in this pr. There will be an option (most likely command line) to restore old proxies. And in the new proxies, method objects can be passed as class data, like in the current patch. The jshell test change will be in the final conversion patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/8278 From Alan.Bateman at oracle.com Mon Apr 18 07:36:08 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Apr 2022 08:36:08 +0100 Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> Message-ID: <0dcb6adc-13b4-1319-bb0e-e0ec86f916bd@oracle.com> On 17/04/2022 17:24, liach wrote: > Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building. > > The main compatibility changes and their rationales are: > 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior. > - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes. > - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain. > - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe. > 2. The disappearance of proxies in stack traces. > - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic. It's great that you have time to experiment in this area but just to set expectations that it will likely require significant discussion and maybe prototyping of alternatives. It suspect the Reviewer effort will end up being many times the effort required to do the actual work because of the compatibility and security issues that will need to be worked through. I think you need to add non-discoverability to the list of compatibility issues. Do we know for sure that there aren't frameworks and libraries that use Class.forName on proxy classes? We've had issues in the past with changes in this area. It's too early to say but it might be that the compatibility risks may nudge this one into creating a new API. -Alan. From alanb at openjdk.java.net Mon Apr 18 09:01:36 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 18 Apr 2022 09:01:36 GMT Subject: RFR: 8283022: com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java failing with -Xcomp after 8273297 In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 05:06:26 GMT, Smita Kamath wrote: > When input length provided to the intrinsic is 8192, only 7680 bytes are processed as the intrinsic operates on multiples of 768 bytes. > In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method, > dst.put(bout, 0, PARALLEL_LEN) statement caused the ciphertext mismatch as PARALLEL_LEN was set to 8192. > Since the intrinsic only processed 7680 bytes, the rest output was incorrect. It's good that this issue has been found. There seems to be an intrinsic for aarch64 with a vectorized GCM implementation, I guess is must also work in multiples of 768 bytes, so is this change okay there too? ------------- PR: https://git.openjdk.java.net/jdk/pull/8280 From ssahoo at openjdk.java.net Mon Apr 18 09:54:09 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Mon, 18 Apr 2022 09:54:09 GMT Subject: RFR: 8209935: Test to cover CodeSource.getCodeSigners() Message-ID: A Test updated to cover the getCodeSigners. ------------- Commit messages: - Update Implies.java - 8209935: Test to cover CodeSource.getCodeSigners() Changes: https://git.openjdk.java.net/jdk/pull/8286/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8286&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8209935 Stats: 12 lines in 1 file changed: 4 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8286.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8286/head:pull/8286 PR: https://git.openjdk.java.net/jdk/pull/8286 From jjiang at openjdk.java.net Mon Apr 18 12:37:15 2022 From: jjiang at openjdk.java.net (John Jiang) Date: Mon, 18 Apr 2022 12:37:15 GMT Subject: RFR: 8284926: Share the certificate NamedGroup in SignatureScheme::getSignerOfPreferableAlgorithm [v2] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8271/files - new: https://git.openjdk.java.net/jdk/pull/8271/files/4367d812..eb706ae8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8271&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8271&range=00-01 Stats: 63 lines in 4 files changed: 43 ins; 15 del; 5 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 mullan at openjdk.java.net Mon Apr 18 12:51:40 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 18 Apr 2022 12:51:40 GMT Subject: RFR: 8284935: Improve debug in java.security.jgss In-Reply-To: <9E_5-kKQyokmeBxAy4TNKsDJTpKbCorJT2_vNREzJxs=.a9cd5583-ed0b-409e-94e7-d7c9dd6d3d50@github.com> References: <9E_5-kKQyokmeBxAy4TNKsDJTpKbCorJT2_vNREzJxs=.a9cd5583-ed0b-409e-94e7-d7c9dd6d3d50@github.com> Message-ID: On Mon, 18 Apr 2022 04:40:27 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have the simple update reviewed? > > In the java.security.jgss module implementation, some of the debug information could be generated even if debugging is not enabled, which is not resource friendly. > > Thanks, > Xuelei LGTM. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8279 From mullan at openjdk.java.net Mon Apr 18 12:59:41 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 18 Apr 2022 12:59:41 GMT Subject: RFR: 8209935: Test to cover CodeSource.getCodeSigners() In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 09:46:06 GMT, Sibabrata Sahoo wrote: > A Test updated to cover the getCodeSigners. test/jdk/java/security/CodeSource/Implies.java line 60: > 58: = new CodeSource(thatURL, (java.security.cert.Certificate[]) null); > 59: if (thisCs.implies(thatCs) != result) { > 60: throw new SecurityException("test failed"); Can you add a more descriptive error message here, ex: `"CodeSource.implies() returned " + !result " instead of " + result` test/jdk/java/security/CodeSource/Implies.java line 63: > 61: } > 62: if (thisCs.getCodeSigners() != null && thatCs.getCodeSigners() != null) { > 63: throw new RuntimeException("Both getCodeSigners should be null"); This test should probably throw SecurityException to be consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/8286 From ssahoo at openjdk.java.net Mon Apr 18 13:26:30 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Mon, 18 Apr 2022 13:26:30 GMT Subject: RFR: 8209935: Test to cover CodeSource.getCodeSigners() [v2] In-Reply-To: References: Message-ID: > A Test updated to cover the getCodeSigners. Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: Update Implies.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8286/files - new: https://git.openjdk.java.net/jdk/pull/8286/files/7db24d99..70618a17 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8286&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8286&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8286.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8286/head:pull/8286 PR: https://git.openjdk.java.net/jdk/pull/8286 From ssahoo at openjdk.java.net Mon Apr 18 13:26:30 2022 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Mon, 18 Apr 2022 13:26:30 GMT Subject: RFR: 8209935: Test to cover CodeSource.getCodeSigners() [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 13:22:35 GMT, Sibabrata Sahoo wrote: >> A Test updated to cover the getCodeSigners. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Update Implies.java All comments addressed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8286 From mullan at openjdk.java.net Mon Apr 18 13:43:10 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 18 Apr 2022 13:43:10 GMT Subject: RFR: 8225433: Clarify behavior of PKIXParameters.setRevocationEnabled when PKIXRevocationChecker is used Message-ID: This change improves the specification for the case when a `PKIXRevocationChecker` is supplied as one of the `CertPathChecker` parameters. Specifically, it makes it more clear that a `PKIXRevocationChecker` overrides the default revocation checking mechanism of a PKIX service provider, and will be used to check revocation irrespective of the setting of the RevocationEnabled parameter. Will also file a CSR. ------------- Commit messages: - 8225433: Clarify behavior of PKIXParameters.setRevocationEnabled when PKIXRevocationChecker is used Changes: https://git.openjdk.java.net/jdk/pull/8287/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8287&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225433 Stats: 18 lines in 2 files changed: 9 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8287.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8287/head:pull/8287 PR: https://git.openjdk.java.net/jdk/pull/8287 From xuelei at openjdk.java.net Mon Apr 18 14:13:41 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 18 Apr 2022 14:13:41 GMT Subject: Integrated: 8284935: Improve debug in java.security.jgss In-Reply-To: <9E_5-kKQyokmeBxAy4TNKsDJTpKbCorJT2_vNREzJxs=.a9cd5583-ed0b-409e-94e7-d7c9dd6d3d50@github.com> References: <9E_5-kKQyokmeBxAy4TNKsDJTpKbCorJT2_vNREzJxs=.a9cd5583-ed0b-409e-94e7-d7c9dd6d3d50@github.com> Message-ID: On Mon, 18 Apr 2022 04:40:27 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have the simple update reviewed? > > In the java.security.jgss module implementation, some of the debug information could be generated even if debugging is not enabled, which is not resource friendly. > > Thanks, > Xuelei This pull request has now been integrated. Changeset: c63fabe3 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/c63fabe3d582ce0828b04b0224cea49aab5fedf3 Stats: 98 lines in 7 files changed: 40 ins; 16 del; 42 mod 8284935: Improve debug in java.security.jgss Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/8279 From rriggs at openjdk.java.net Mon Apr 18 14:36:40 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 18 Apr 2022 14:36:40 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 15:45:21 GMT, Xue-Lei Andrew Fan wrote: > Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. > > The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. Please combine these closely related cases into a single test, preferably with TestNG or JUnit. test/jdk/javax/security/auth/callback/ClearPasswordMethod.java line 53: > 51: System.gc(); > 52: Thread.sleep(100); > 53: } The test could complete more quickly if the loop was exited when whm.size() == 0. And in the other test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From mullan at openjdk.java.net Mon Apr 18 14:45:42 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 18 Apr 2022 14:45:42 GMT Subject: RFR: 8284933: Improve debug in jdk.crypto.cryptoki In-Reply-To: References: Message-ID: On Sun, 17 Apr 2022 14:45:49 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have the simple update reviewed? > > In the jdk.crypto.cryptoki module implementation, some of the debug information could be calculated even if the debug is not enabled, which is not resource friendly. > > Thanks, > Xuelei DEBUG is final, so it is not intended to be configurable at runtime. I'm ok with this, but will defer to someone else more familiar with this code for approval. ------------- PR: https://git.openjdk.java.net/jdk/pull/8277 From ascarpino at openjdk.java.net Mon Apr 18 15:16:41 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 18 Apr 2022 15:16:41 GMT Subject: RFR: 8283022: com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java failing with -Xcomp after 8273297 In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 05:06:26 GMT, Smita Kamath wrote: > When input length provided to the intrinsic is 8192, only 7680 bytes are processed as the intrinsic operates on multiples of 768 bytes. > In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method, > dst.put(bout, 0, PARALLEL_LEN) statement caused the ciphertext mismatch as PARALLEL_LEN was set to 8192. > Since the intrinsic only processed 7680 bytes, the rest output was incorrect. Marked as reviewed by ascarpino (Reviewer). x86-64 only uses this intrinsic, aarch64 does not support this intrinsic and uses the java code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8280 From xuelei at openjdk.java.net Mon Apr 18 15:21:18 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 18 Apr 2022 15:21:18 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: Message-ID: > Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. > > The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Update test case ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8272/files - new: https://git.openjdk.java.net/jdk/pull/8272/files/172fa7f3..73692489 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=00-01 Stats: 96 lines in 2 files changed: 31 ins; 60 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8272/head:pull/8272 PR: https://git.openjdk.java.net/jdk/pull/8272 From xuelei at openjdk.java.net Mon Apr 18 15:25:36 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 18 Apr 2022 15:25:36 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 14:33:35 GMT, Roger Riggs wrote: > Please combine these closely related cases into a single test, preferably with TestNG or JUnit. I normally prefer to have one job in one test, so that it is easier for debugging. I'm fine to combine them as the cases are simple enough. > test/jdk/javax/security/auth/callback/ClearPasswordMethod.java line 53: > >> 51: System.gc(); >> 52: Thread.sleep(100); >> 53: } > > The test could complete more quickly if the loop was exited when whm.size() == 0. > And in the other test. Good point. It has been a concern to me to have the threads sleep. I will check other PRs, and add the size checking as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From xuelei at openjdk.java.net Mon Apr 18 15:49:40 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 18 Apr 2022 15:49:40 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v3] In-Reply-To: References: Message-ID: On Sat, 9 Apr 2022 15:00:46 GMT, Weijun Wang wrote: >>> You might try it on other objects: >> >> Nice idea to test object collection. I added two test cases. >> >>> The `NativeGSSContext` code still needs to be fixed. >> >> Could you have more details? I did not catch the comment about NativeGSSContext. > >> Could you have more details? I did not catch the comment about NativeGSSContext. > > When `NativeGSSContext(GSSNameElement peer, GSSCredElement myCred, int time, GSSLibStub stub)` is called, `pContext` is 0 and you haven't registered the cleaner. Later, when `initSecContext()` is called, it calls into `cStub.initContext()` and this native method will set `pContext` if a context is established. Since you haven't registered the cleaner in the ctor, this native context will not be released at the end. > > So one solution is to add a `setNativeContext(long pContext)` method and when this method is called you register the cleaner. Now, inside the native method, instead of setting the `pContext` field directly you can call this setter method. Or, move `cStub` and `pContext` into a new static inner class and let `disposerFor` work on it. @wangweij In the following constructor, I'm not sure if the assert right. NativeGSSContext(long pCtxt, GSSLibStub stub) throws GSSException { assert(pContext != 0); ... Should it be `assert(pCtxt != 0);`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From alanb at openjdk.java.net Mon Apr 18 15:56:32 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 18 Apr 2022 15:56:32 GMT Subject: RFR: 8283022: com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java failing with -Xcomp after 8273297 In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 15:13:14 GMT, Anthony Scarpino wrote: > x86-64 only uses this intrinsic, aarch64 does not support this intrinsic and uses the java code. It looks like aarch64 has an implementation of generate_galoisCounterMode_AESCrypt, isn't that the code that implGCMCrypt0 runs? ------------- PR: https://git.openjdk.java.net/jdk/pull/8280 From smarks at openjdk.java.net Mon Apr 18 16:09:45 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Mon, 18 Apr 2022 16:09:45 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 20:16:38 GMT, Sean Mullan wrote: >>> Are the changes necessary for this part? >> >> @seanjmullan no, they are just performance refinement. >> >> If you really that wanna 100% sync , >> >> I can use the old 1.8 api to migrate that part, and make a mirror pr to that part of https://github.com/apache/santuario-xml-security-java >> >> Is this solution acceptable then? > >> > Are the changes necessary for this part? >> >> @seanjmullan no, they are just performance refinement. >> >> If you really that wanna 100% sync , >> >> I can use the old 1.8 api to migrate that part, and make a mirror pr to that part of https://github.com/apache/santuario-xml-security-java >> >> Is this solution acceptable then? > > Yes, that would be preferred. Thanks! I'd like to see a confirmation from @seanjmullan to make sure the issues with Santuario are resolved satisfactorily. Other than that I think it's pretty well covered. I've already run these changes through our internal test system and they look fine. I'll do a final recheck and let you know. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From ascarpino at openjdk.java.net Mon Apr 18 16:24:39 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 18 Apr 2022 16:24:39 GMT Subject: RFR: 8283022: com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java failing with -Xcomp after 8273297 In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 05:06:26 GMT, Smita Kamath wrote: > When input length provided to the intrinsic is 8192, only 7680 bytes are processed as the intrinsic operates on multiples of 768 bytes. > In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method, > dst.put(bout, 0, PARALLEL_LEN) statement caused the ciphertext mismatch as PARALLEL_LEN was set to 8192. > Since the intrinsic only processed 7680 bytes, the rest output was incorrect. Oh wow.. you're right. I never saw that come through.. thanks for seeing that. I'll run some tests that it's ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/8280 From smarks at openjdk.java.net Mon Apr 18 16:42:41 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Mon, 18 Apr 2022 16:42:41 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 15:21:18 GMT, Xue-Lei Andrew Fan wrote: >> Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. >> >> The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Update test case src/java.base/share/classes/javax/security/auth/callback/PasswordCallback.java line 123: > 121: cleanable = CleanerFactory.cleaner().register( > 122: this, cleanerFor(inputPassword)); > 123: } If `setPassword` is called twice in succession, should the previous password be cleaned before the new one is assigned and registered? ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From mullan at openjdk.java.net Mon Apr 18 16:44:35 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 18 Apr 2022 16:44:35 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v21] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 20:16:38 GMT, Sean Mullan wrote: >>> Are the changes necessary for this part? >> >> @seanjmullan no, they are just performance refinement. >> >> If you really that wanna 100% sync , >> >> I can use the old 1.8 api to migrate that part, and make a mirror pr to that part of https://github.com/apache/santuario-xml-security-java >> >> Is this solution acceptable then? > >> > Are the changes necessary for this part? >> >> @seanjmullan no, they are just performance refinement. >> >> If you really that wanna 100% sync , >> >> I can use the old 1.8 api to migrate that part, and make a mirror pr to that part of https://github.com/apache/santuario-xml-security-java >> >> Is this solution acceptable then? > > Yes, that would be preferred. Thanks! > I'd like to see a confirmation from @seanjmullan to make sure the issues with Santuario are resolved satisfactorily. Other than that I think it's pretty well covered. I've already run these changes through our internal test system and they look fine. I'll do a final recheck and let you know. I am fine with this being integrated. @XenoAmess already [submitted a PR to the Santuario Project](https://github.com/apache/santuario-xml-security-java/pull/64) using the existing `HashMap` constructor which I have approved. So the code will be in sync the next time we upgrade the JDK to a newer version of Santuario. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From mchung at openjdk.java.net Mon Apr 18 17:29:40 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 18 Apr 2022 17:29:40 GMT Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> Message-ID: On Sun, 17 Apr 2022 16:17:30 GMT, liach wrote: > Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building. > > The main compatibility changes and their rationales are: > 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior. > - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes. > - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain. > - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe. > 2. The disappearance of proxies in stack traces. > - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic. > > A summary of the rest of the changes: > 1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well. > 2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups. > 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance. > > In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)? > > Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed. It's good to see more experiment and prototype for this issue. Like Alan said, the spec change, compatibility risks and security issues in particular on the serialization spec/impl change require lot of discussions and also prototyping of other alternatives. A new API may also be one alternative to consider. The current spec of Proxy class is defined with null protection domain (same protection domain as the bootstrap class loader). Lookup::defineHiddenClass defines the hidden class in the same protection domain as the defining class loader. This would become a non-issue when the security manager is removed. However, before the removal of security manager, we still need to look into the compatibility risks and what and how applications/libraries depend on this behavior. During the development of JEP 371, I had a prototype of converting dynamic proxies to hidden class by adding a shim class (that's what your prototype does). That raises the question "how to get a Lookup on a package for the dynamic proxy class to be injected in without injecting a shim class (i.e. your anchor class)?" This functionality could be considered as a separate RFE. However, frameworks don't always have the access to inject a class in a package defined to a class loader. This is something worth looking into. ------------- PR: https://git.openjdk.java.net/jdk/pull/8278 From mullan at openjdk.java.net Mon Apr 18 17:30:52 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 18 Apr 2022 17:30:52 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 16:39:36 GMT, Stuart Marks wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test case > > src/java.base/share/classes/javax/security/auth/callback/PasswordCallback.java line 123: > >> 121: cleanable = CleanerFactory.cleaner().register( >> 122: this, cleanerFor(inputPassword)); >> 123: } > > If `setPassword` is called twice in succession, should the previous password be cleaned before the new one is assigned and registered? I can see why that might be a good idea. Would require a specification change though. I also think it is fine to keep the behavior the same, and place the responsibility on the application to call `clearPassword` before setting a new one. We could add a warning though, something like: "Note: `clearPassword` should be called to clear any prior password before calling `setPassword` multiple times on the same `PasswordCallback` instance." ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From mullan at openjdk.java.net Mon Apr 18 17:39:44 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 18 Apr 2022 17:39:44 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 19:27:00 GMT, Valerie Peng wrote: >> This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring. >> >> The CSR will be filed once review is somewhat finished. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update w/ review feedback. src/java.base/share/classes/javax/crypto/spec/OAEPParameterSpec.java line 100: > 98: * standard. Some of these defaults are no longer recommended due > 99: * to advances in cryptanalysis -- see the > 100: * Appendix B.1 In the URL text, you should still say this is from RFC 8017. Suggest changing these two lines to: * to advances in cryptanalysis -- see * Appendix B.1 of RFC 8017 ------------- PR: https://git.openjdk.java.net/jdk/pull/8191 From mullan at openjdk.java.net Mon Apr 18 17:48:44 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 18 Apr 2022 17:48:44 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 15:21:18 GMT, Xue-Lei Andrew Fan wrote: >> Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. >> >> The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Update test case I am not quite seeing the rationale for this change. Are you trying to protect against callers forgetting to call `clearPassword`? Is that really our responsibility? Even if so, then @stuart-marks suggestion about clearing interim passwords is relevant and this solution seems incomplete. But I think trying to fix that will necessitate some specification changes and also possibly some added implementation complexity to detect if code has or has not called `clearPassword`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From rriggs at openjdk.java.net Mon Apr 18 18:11:39 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 18 Apr 2022 18:11:39 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 17:27:04 GMT, Sean Mullan wrote: >> src/java.base/share/classes/javax/security/auth/callback/PasswordCallback.java line 123: >> >>> 121: cleanable = CleanerFactory.cleaner().register( >>> 122: this, cleanerFor(inputPassword)); >>> 123: } >> >> If `setPassword` is called twice in succession, should the previous password be cleaned before the new one is assigned and registered? > > I can see why that might be a good idea. Would require a specification change though. I also think it is fine to keep the behavior the same, and place the responsibility on the application to call `clearPassword` before setting a new one. We could add a warning though, something like: "Note: `clearPassword` should be called to clear any prior password before calling `setPassword` multiple times on the same `PasswordCallback` instance." setPassword can/should always clear the previous password. It is an internal copy that no one else has a reference to and is being replaced. It will need to either explicitly call cleanable.clean() or fill/erase the array itself. Overwriting the cleanable will prevent the existing cleanable from being processed. It don't think it needs a spec change, the internal value is implementation only. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From mullan at openjdk.java.net Mon Apr 18 18:18:40 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 18 Apr 2022 18:18:40 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 18:07:59 GMT, Roger Riggs wrote: >> I can see why that might be a good idea. Would require a specification change though. I also think it is fine to keep the behavior the same, and place the responsibility on the application to call `clearPassword` before setting a new one. We could add a warning though, something like: "Note: `clearPassword` should be called to clear any prior password before calling `setPassword` multiple times on the same `PasswordCallback` instance." > > setPassword can/should always clear the previous password. It is an internal copy that no one else has a reference to and is being replaced. > It will need to either explicitly call cleanable.clean() or fill/erase the array itself. > Overwriting the cleanable will prevent the existing cleanable from being processed. > It don't think it needs a spec change, the internal value is implementation only. What about code that is already calling `clearPassword` between calls to `setPassword`? This seems to be a change in the design of this API. The `clearPassword` method is there to allow callers to manage and clear the passwords itself. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From rriggs at openjdk.java.net Mon Apr 18 19:13:30 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 18 Apr 2022 19:13:30 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 18:15:25 GMT, Sean Mullan wrote: >> setPassword can/should always clear the previous password. It is an internal copy that no one else has a reference to and is being replaced. >> It will need to either explicitly call cleanable.clean() or fill/erase the array itself. >> Overwriting the cleanable will prevent the existing cleanable from being processed. >> It don't think it needs a spec change, the internal value is implementation only. > > What about code that is already calling `clearPassword` between calls to `setPassword`? This seems to be a change in the design of this API. The `clearPassword` method is there to allow callers to manage and clear the passwords itself. I think its "belt and suspenders". If the caller does not call `clearPassword` before calling a second `setPassword,` the previous char array will still contain the previous password and remain uncleared in memory for a (longer) indeterminate time. It is fulfilling the same purpose as the original finalizer. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From smarks at openjdk.java.net Mon Apr 18 19:30:39 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Mon, 18 Apr 2022 19:30:39 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: Message-ID: <6kwPo15egFhWziB4JTw9_-Q_3hfRxI0QWVOkBqjxVs0=.20c03513-c6b7-4f3e-a13c-ca2efad17a13@github.com> On Mon, 18 Apr 2022 19:10:44 GMT, Roger Riggs wrote: >> What about code that is already calling `clearPassword` between calls to `setPassword`? This seems to be a change in the design of this API. The `clearPassword` method is there to allow callers to manage and clear the passwords itself. > > I think its "belt and suspenders". > If the caller does not call `clearPassword` before calling a second `setPassword,` the previous char array will still contain the previous password and remain uncleared in memory for a (longer) indeterminate time. > It is fulfilling the same purpose as the original finalizer. Yes, exactly. I'd recommend it calling `cleanable.clean()` prior to storing the new password, so that the cleaning action for the old password is explicitly and immediately unregistered. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From ascarpino at openjdk.java.net Mon Apr 18 19:33:35 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 18 Apr 2022 19:33:35 GMT Subject: RFR: 8283022: com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java failing with -Xcomp after 8273297 In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 05:06:26 GMT, Smita Kamath wrote: > When input length provided to the intrinsic is 8192, only 7680 bytes are processed as the intrinsic operates on multiples of 768 bytes. > In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method, > dst.put(bout, 0, PARALLEL_LEN) statement caused the ciphertext mismatch as PARALLEL_LEN was set to 8192. > Since the intrinsic only processed 7680 bytes, the rest output was incorrect. Please update the copyright year ------------- PR: https://git.openjdk.java.net/jdk/pull/8280 From duke at openjdk.java.net Mon Apr 18 20:01:39 2022 From: duke at openjdk.java.net (liach) Date: Mon, 18 Apr 2022 20:01:39 GMT Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> Message-ID: On Sun, 17 Apr 2022 16:17:30 GMT, liach wrote: > Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building. > > The main compatibility changes and their rationales are: > 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior. > - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes. > - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain. > - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe. > 2. The disappearance of proxies in stack traces. > - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic. > > A summary of the rest of the changes: > 1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well. > 2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups. > 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance. > > In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)? > > Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed. I strongly recommend a new API over revamping `Proxy` itself. https://github.com/forax/hidden_proxy would be a good prototype that serves most needs of the current Proxy API (except a few, like invoking default superinterface method). With hidden classes, I don't see much value in leaving the new API's produced instance in separate modules; what we have for hidden classes should be fine for the most part. Imo the main obstacle is still the handling of serialization. The annotations are serializable, but currently hidden classes do not work with serialization at all and must use `writeReplace` and `readResolve`. And how to migrate annotations off proxies without breaking serialization is still a question as well. Maybe we can upgrade invocation handlers to allow them to declare custom `readResolve` logic for the proxy to facilitate migration away. How the new API will treat serialization is still undetermined. ------------- PR: https://git.openjdk.java.net/jdk/pull/8278 From mullan at openjdk.java.net Mon Apr 18 20:07:34 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 18 Apr 2022 20:07:34 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: <6kwPo15egFhWziB4JTw9_-Q_3hfRxI0QWVOkBqjxVs0=.20c03513-c6b7-4f3e-a13c-ca2efad17a13@github.com> References: <6kwPo15egFhWziB4JTw9_-Q_3hfRxI0QWVOkBqjxVs0=.20c03513-c6b7-4f3e-a13c-ca2efad17a13@github.com> Message-ID: On Mon, 18 Apr 2022 19:27:21 GMT, Stuart Marks wrote: >> I think its "belt and suspenders". >> If the caller does not call `clearPassword` before calling a second `setPassword,` the previous char array will still contain the previous password and remain uncleared in memory for a (longer) indeterminate time. >> It is fulfilling the same purpose as the original finalizer. > > Yes, exactly. I'd recommend it calling `cleanable.clean()` prior to storing the new password, so that the cleaning action for the old password is explicitly and immediately unregistered. Yes, I suppose that is a good enough reason, although this class never had a finalizer AFAIK. Won't there be a small performance hit (perhaps negligible) for code that already calls `clearPassword`? A specification clarification would provide clarity to applications that they do not have to call `clearPassword` in between calls to `setPassword`. Something as simple as: "This method clears the value of any previously stored password before storing the input password". ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From forax at univ-mlv.fr Mon Apr 18 20:41:26 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 18 Apr 2022 22:41:26 +0200 (CEST) Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes In-Reply-To: References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> Message-ID: <2565866.13937463.1650314486716.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "liach" > To: "core-libs-dev" , "security-dev" > Sent: Monday, April 18, 2022 10:01:39 PM > Subject: Re: RFR: JDK-8242888: Convert dynamic proxy to hidden classes > On Sun, 17 Apr 2022 16:17:30 GMT, liach wrote: > >> Convert dynamic proxies to hidden classes. Modifies the serialization of proxies >> (requires change in "Java Object Serialization Specification"). Makes the >> proxies hidden in stack traces. Removes duplicate logic in proxy building. >> >> The main compatibility changes and their rationales are: >> 1. Modification to the serialization specification: In the "An instance of the >> class is allocated... The contents restored appropriately" section, I propose >> explicitly state that handling of proxies are unspecified as to allow >> implementation freedom, though I've seen deliberate attempts for proxies to >> implement interfaces with `readResolve` in order to control their serialization >> behavior. >> - This is for the existing generated constructor accessor is bytecode-based, >> which cannot refer to hidden classes. >> - An alternative is to preserve the behavior, where the serialization >> constructor calls `invokespecial` on the closest serializable superclass' >> no-arg constructor, like in #1830 by @DasBrain. >> - My rationale against preservation is such super calls are unsafe and should be >> discouraged in the long term. Calling the existing constructor with a dummy >> argument, as in my implementation, would be more safe. >> 2. The disappearance of proxies in stack traces. >> - Same behavior exists in lambda expressions: For instance, in `((Runnable) () >> -> { throw new Error(); }).run();`, the `run` method, implemented by the >> lambda, will not appear in the stack trace, and isn't too problematic. >> >> A summary of the rest of the changes: >> 1. Merged the two passes of determining module and package of the proxy into >> one. This reduced a lot of code and allowed anchor class (for hidden class >> creation) selection be done together as well. >> 2. Exposed internal API for obtaining a full-privileged lookup to the rest of >> `java.base`. This API is intended for implementation of legacy (pre >> `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more >> complex tricks to obtain proper permissions as lookups. >> 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): >> passes methods computed by proxy generator as class data to the hidden proxy >> class to reduce generated proxy class size and improve performance. >> >> In addition, since this change is somewhat large, should we keep the old proxy >> generator as well and have it toggled through a command-line flag (like the old >> v49 proxy generator or the old reflection implementation)? >> >> Please feel free to comment or review. This change definitely requires a CSR, >> but I have yet to determine what specifications should be changed. > > I strongly recommend a new API over revamping `Proxy` itself. > https://github.com/forax/hidden_proxy would be a good prototype that serves > most needs of the current Proxy API (except a few, like invoking default > superinterface method). The third parameter of defineProxy() is a lambda which is called for each method that can be overriden, either toString/equals/hashCode but also any default methods, if the lambda return true, the method is overriden, otherwise the default implementation is used. > With hidden classes, I don't see much value in leaving > the new API's produced instance in separate modules; what we have for hidden > classes should be fine for the most part. > > Imo the main obstacle is still the handling of serialization. The annotations > are serializable, but currently hidden classes do not work with serialization > at all and must use `writeReplace` and `readResolve`. And how to migrate > annotations off proxies without breaking serialization is still a question as > well. Maybe we can upgrade invocation handlers to allow them to declare custom > `readResolve` logic for the proxy to facilitate migration away. How the new API > will treat serialization is still undetermined. yes, i suppose that like with lambdas, we need a special overload of defineProxy that automatically implements writeReplace() and use a specific class SerializableProxy (mirroring how SerializableLambda works). > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/8278 From svkamath at openjdk.java.net Mon Apr 18 20:43:06 2022 From: svkamath at openjdk.java.net (Smita Kamath) Date: Mon, 18 Apr 2022 20:43:06 GMT Subject: RFR: 8283022: com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java failing with -Xcomp after 8273297 [v2] In-Reply-To: References: Message-ID: > When input length provided to the intrinsic is 8192, only 7680 bytes are processed as the intrinsic operates on multiples of 768 bytes. > In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method, > dst.put(bout, 0, PARALLEL_LEN) statement caused the ciphertext mismatch as PARALLEL_LEN was set to 8192. > Since the intrinsic only processed 7680 bytes, the rest output was incorrect. Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Updated copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8280/files - new: https://git.openjdk.java.net/jdk/pull/8280/files/ca08ccd9..3c917fab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8280&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8280&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8280.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8280/head:pull/8280 PR: https://git.openjdk.java.net/jdk/pull/8280 From valeriep at openjdk.java.net Mon Apr 18 21:57:27 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 18 Apr 2022 21:57:27 GMT Subject: RFR: 8284933: Improve debug in jdk.crypto.cryptoki In-Reply-To: References: Message-ID: <03wjShSptSwHWtStL-E6ub0WyXFy2QLs-M8GPZG6emA=.e605cd3c-e096-49f5-85e2-9f2d688cfd56@github.com> On Sun, 17 Apr 2022 14:45:49 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have the simple update reviewed? > > In the jdk.crypto.cryptoki module implementation, some of the debug information could be calculated even if the debug is not enabled, which is not resource friendly. > > Thanks, > Xuelei With this change, I see no reason to have debug(...) method. May as well just remove it and simply do a "System.out.println(...);"? ------------- PR: https://git.openjdk.java.net/jdk/pull/8277 From smarks at openjdk.java.net Mon Apr 18 22:37:36 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Mon, 18 Apr 2022 22:37:36 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v22] In-Reply-To: <8BqTTnIZwmWPePWhmjea15skxDmEexP5ugH8H2PawtI=.79a6387d-4a4d-4867-94c0-6554e7b9b8ad@github.com> References: <8BqTTnIZwmWPePWhmjea15skxDmEexP5ugH8H2PawtI=.79a6387d-4a4d-4867-94c0-6554e7b9b8ad@github.com> Message-ID: On Thu, 14 Apr 2022 21:27:16 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > java.xml.crypto's usage downgrade grammar to 1.8 Marked as reviewed by smarks (Reviewer). OK, go ahead and integrate! ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From wetmore at openjdk.java.net Mon Apr 18 23:12:26 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Mon, 18 Apr 2022 23:12:26 GMT Subject: RFR: JDK-8284112 Minor cleanup could be done in javax.crypto [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 23:32:11 GMT, Mark Powers wrote: >> JDK-8284112 Minor cleanup could be done in javax.crypto > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > cleanup src/java.base/share/classes/javax/crypto/CryptoPolicyParser.java line 282: > 280: } > 281: > 282: private static AlgorithmParameterSpec getInstance(String type, Why are you removing final here? ------------- PR: https://git.openjdk.java.net/jdk/pull/8214 From wetmore at openjdk.java.net Mon Apr 18 23:21:10 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Mon, 18 Apr 2022 23:21:10 GMT Subject: RFR: JDK-8284112 Minor cleanup could be done in javax.crypto [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 23:32:11 GMT, Mark Powers wrote: >> JDK-8284112 Minor cleanup could be done in javax.crypto > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > cleanup This looks ok to me. Go ahead and push. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8214 From valeriep at openjdk.java.net Mon Apr 18 23:36:56 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 18 Apr 2022 23:36:56 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec [v3] In-Reply-To: References: Message-ID: > This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring. > > The CSR will be filed once review is somewhat finished. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Removed the private no-arg default constructor and minor javadoc update. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8191/files - new: https://git.openjdk.java.net/jdk/pull/8191/files/ba572eed..a760fc51 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8191&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8191&range=01-02 Stats: 12 lines in 2 files changed: 0 ins; 11 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8191/head:pull/8191 PR: https://git.openjdk.java.net/jdk/pull/8191 From ascarpino at openjdk.java.net Mon Apr 18 23:49:35 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 18 Apr 2022 23:49:35 GMT Subject: RFR: 8283022: com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java failing with -Xcomp after 8273297 [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 20:43:06 GMT, Smita Kamath wrote: >> When input length provided to the intrinsic is 8192, only 7680 bytes are processed as the intrinsic operates on multiples of 768 bytes. >> In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method, >> dst.put(bout, 0, PARALLEL_LEN) statement caused the ciphertext mismatch as PARALLEL_LEN was set to 8192. >> Since the intrinsic only processed 7680 bytes, the rest output was incorrect. > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright year I reran the test on aarch64 and x64 using -Xcomp without failure, also repeating the failing test. Given the bug says it was intermittent I can never been 100% certain it is perfect, but looking at the aarch64, it is just looping on that data it is presented, not hardcoded for a particular amount of data like the x64 code. That looping should work fine with the code change. I think it's ready to go into the repo. ------------- PR: https://git.openjdk.java.net/jdk/pull/8280 From duke at openjdk.java.net Mon Apr 18 23:52:25 2022 From: duke at openjdk.java.net (Mark Powers) Date: Mon, 18 Apr 2022 23:52:25 GMT Subject: Integrated: JDK-8284112 Minor cleanup could be done in javax.crypto In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 21:59:09 GMT, Mark Powers wrote: > JDK-8284112 Minor cleanup could be done in javax.crypto This pull request has now been integrated. Changeset: 41fc0783 Author: Mark Powers Committer: Bradford Wetmore URL: https://git.openjdk.java.net/jdk/commit/41fc07832300d224bb185b88ac4135b7e2b27cff Stats: 279 lines in 37 files changed: 9 ins; 75 del; 195 mod 8284112: Minor cleanup could be done in javax.crypto Reviewed-by: wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/8214 From smarks at openjdk.java.net Tue Apr 19 00:07:57 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 19 Apr 2022 00:07:57 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v22] In-Reply-To: <8BqTTnIZwmWPePWhmjea15skxDmEexP5ugH8H2PawtI=.79a6387d-4a4d-4867-94c0-6554e7b9b8ad@github.com> References: <8BqTTnIZwmWPePWhmjea15skxDmEexP5ugH8H2PawtI=.79a6387d-4a4d-4867-94c0-6554e7b9b8ad@github.com> Message-ID: <_Chw5faR5IlUHqflJ7FT4npMIOh0ECjpCQdDH4cE0D8=.bb789c23-043a-4515-8c39-0f940b514711@github.com> On Thu, 14 Apr 2022 21:27:16 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > java.xml.crypto's usage downgrade grammar to 1.8 I've also written a release note for this change. Please review. https://bugs.openjdk.java.net/browse/JDK-8284975 ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Tue Apr 19 00:07:58 2022 From: duke at openjdk.java.net (XenoAmess) Date: Tue, 19 Apr 2022 00:07:58 GMT Subject: Integrated: 8186958: Need method to create pre-sized HashMap In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 18:41:59 GMT, XenoAmess wrote: > 8186958: Need method to create pre-sized HashMap This pull request has now been integrated. Changeset: 87faa85c Author: XenoAmess Committer: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/87faa85c59e94d66c3c61d997eacdd2dbe5a1772 Stats: 212 lines in 30 files changed: 139 ins; 4 del; 69 mod 8186958: Need method to create pre-sized HashMap Reviewed-by: chegar, naoto, joehw, lancea, wetmore, smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From bchristi at openjdk.java.net Tue Apr 19 00:16:29 2022 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 19 Apr 2022 00:16:29 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v5] In-Reply-To: <09nZBWUg9qc9kFIJvVfx0BnzyyVp3t2bAJlKV1wQt28=.12a424f0-81fb-4b53-91cd-c7cec9ffdea8@github.com> References: <09nZBWUg9qc9kFIJvVfx0BnzyyVp3t2bAJlKV1wQt28=.12a424f0-81fb-4b53-91cd-c7cec9ffdea8@github.com> Message-ID: On Sat, 16 Apr 2022 05:28:39 GMT, Xue-Lei Andrew Fan wrote: >> src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c line 274: >> >>> 272: ModuleData *moduleData = jlong_to_ptr(ckpNativeData); >>> 273: >>> 274: if (moduleData != NULL) { >> >> The check should be (moduleData->hModule != NULL)? Same goes for the other p11_md.c file. > > I think it is safer to add the check for 'hModule'. > > > - if (moduleData != NULL) { > + if (moduleData != NULL && moduleData->hModule != NULL) { That is very safe -- we already checked that `ckpNativeData != 0L` ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From valeriep at openjdk.java.net Tue Apr 19 00:16:30 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 19 Apr 2022 00:16:30 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v6] In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 05:35:20 GMT, Xue-Lei Andrew Fan wrote: >> This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Update signatures for native code src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c line 274: > 272: ModuleData *moduleData = jlong_to_ptr(ckpNativeData); > 273: > 274: if (moduleData != NULL && moduleData->hModule != NULL) { The moduleData != NULL check seems to duplicate with the line 271? Otherwise looks fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From duke at openjdk.java.net Tue Apr 19 01:31:24 2022 From: duke at openjdk.java.net (liach) Date: Tue, 19 Apr 2022 01:31:24 GMT Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes In-Reply-To: <2565866.13937463.1650314486716.JavaMail.zimbra@u-pem.fr> References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> <2565866.13937463.1650314486716.JavaMail.zimbra@u-pem.fr> Message-ID: On Mon, 18 Apr 2022 20:42:48 GMT, Remi Forax wrote: > The third parameter of defineProxy() is a lambda which is called for each method that can be overriden, either toString/equals/hashCode but also any default methods, if the lambda return true, the method is overriden, otherwise the default implementation is used. Not quite, I mean calling default implementations in the super interface, consider: interface Root { void cleanUp(); } interface FeatureOne extends Root { default void cleanUp() { /* do something */ } } interface FeatureTwo extends Root { default void cleanUp() { /* do something */ } } My proxy implements both feature one and two, but in your API, there is no way for my `cleanUp` to call both `FeatureOne.super.cleanUp();` and `FeatureTwo.super.cleanUp();`. You should probably expose the lookup in your linker too, especially that you enabled nest access and you can just use that lookup to resolve, say, an implementation static method in the proxy user class. Also the "delegate" in your API would significantly benefit from https://bugs.openjdk.java.net/browse/JDK-8282798 (#7744), too. ------------- PR: https://git.openjdk.java.net/jdk/pull/8278 From valeriep at openjdk.java.net Tue Apr 19 02:23:27 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 19 Apr 2022 02:23:27 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 17:30:38 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update w/ review feedbacks > > src/java.base/share/classes/javax/crypto/Cipher.java line 1054: > >> 1052: * this cipher, or may contain additional default or random parameter >> 1053: * values used by the underlying cipher implementation if this cipher can >> 1054: * successfully generate the required parameter values when not supplied. > > A few comments: > > 1. 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 ..." > > 2. Should `Signature.getParameters` be updated to be consistent? Are there any cases, or could there be, where a signature provider may return additional parameters other than what the user specified? Hmm, I tried the suggested approach in (1), the result looks very lengthy. Actually, the Cipher.init(..) methods already has a few paragraphs describing the behavior for parameter generation, perhaps we should not repeat stating the "If this cipher was initialized" vs "was not initialized" since lengthy description may confuse users and have higher risks of inconsistency. What do you think? As for (2), currently only RSASSA-PSS signature impl uses parameters. When specified using PSSParameterSpec, it's possible that some of the parameters are not set, so it's possible for providers to use provider-specific default values for PSS case. So, yes, Signature class may have to updated in the same way to cover this particular scenario. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From valeriep at openjdk.java.net Tue Apr 19 02:47:26 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 19 Apr 2022 02:47:26 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 02:20:10 GMT, Valerie Peng wrote: >> src/java.base/share/classes/javax/crypto/Cipher.java line 1054: >> >>> 1052: * this cipher, or may contain additional default or random parameter >>> 1053: * values used by the underlying cipher implementation if this cipher can >>> 1054: * successfully generate the required parameter values when not supplied. >> >> A few comments: >> >> 1. 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 ..." >> >> 2. Should `Signature.getParameters` be updated to be consistent? Are there any cases, or could there be, where a signature provider may return additional parameters other than what the user specified? > > Hmm, I tried the suggested approach in (1), the result looks very lengthy. Actually, the Cipher.init(..) methods already has a few paragraphs describing the behavior for parameter generation, perhaps we should not repeat stating the "If this cipher was initialized" vs "was not initialized" since lengthy description may confuse users and have higher risks of inconsistency. What do you think? > As for (2), currently only RSASSA-PSS signature impl uses parameters. When specified using PSSParameterSpec, it's possible that some of the parameters are not set, so it's possible for providers to use provider-specific default values for PSS case. So, yes, Signature class may have to updated in the same way to cover this particular scenario. For (1), how about something like below: > *

The returned parameters may be the same that were used to initialize > * this cipher, or may contain additional default or random parameter > * values used by the underlying cipher implementation. If no parameters > * is supplied and this cipher successfully generated the required > * parameter values, it will be returned. Otherwise, {@code null} is > * returned. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From forax at univ-mlv.fr Tue Apr 19 06:01:11 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 19 Apr 2022 08:01:11 +0200 (CEST) Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes In-Reply-To: References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> <2565866.13937463.1650314486716.JavaMail.zimbra@u-pem.fr> Message-ID: <1446733181.14034873.1650348071923.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "liach" > To: "core-libs-dev" , "security-dev" > Sent: Tuesday, April 19, 2022 3:31:24 AM > Subject: Re: RFR: JDK-8242888: Convert dynamic proxy to hidden classes > On Mon, 18 Apr 2022 20:42:48 GMT, Remi Forax wrote: > >> The third parameter of defineProxy() is a lambda which is called for each method >> that can be overriden, either toString/equals/hashCode but also any default >> methods, > if the lambda return true, the method is overriden, otherwise the default > implementation is used. > > Not quite, I mean calling default implementations in the super interface, > consider: > > interface Root { void cleanUp(); } > interface FeatureOne extends Root { default void cleanUp() { /* do something */ > } } > interface FeatureTwo extends Root { default void cleanUp() { /* do something */ > } } > > My proxy implements both feature one and two, but in your API, there is no way > for my `cleanUp` to call both `FeatureOne.super.cleanUp();` and > `FeatureTwo.super.cleanUp();`. You should probably expose the lookup in your > linker too, especially that you enabled nest access and you can just use that > lookup to resolve, say, an implementation static method in the proxy user > class. yes, you are right, i should send the Lookup too. > > Also the "delegate" in your API would significantly benefit from > https://bugs.openjdk.java.net/browse/JDK-8282798 (#7744), too. I don't think i need the carrier API, the idea is to have only one field in the proxy, this field can be a value type (exactly a primitive class) in the future, so being expanded into multiple fields by the VM at runtime. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/8278 From djelinski at openjdk.java.net Tue Apr 19 06:02:27 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 19 Apr 2022 06:02:27 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v3] In-Reply-To: <-1bnefBpuQA1cHNaN93ULwBskNsIU49tYw6sUE9a_TI=.e7ef496c-d6a0-4f3c-900f-5f817b77c5cf@github.com> References: <-1bnefBpuQA1cHNaN93ULwBskNsIU49tYw6sUE9a_TI=.e7ef496c-d6a0-4f3c-900f-5f817b77c5cf@github.com> Message-ID: <0qpMEBz9NDwiZm5Dcqus0xK5rMqc_hck2nq60TNECmg=.d9973756-819f-4443-b28c-ac8861091cb1@github.com> On Wed, 13 Apr 2022 06:46:51 GMT, Xue-Lei Andrew Fan wrote: >> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: >> >> - add more factory methods, update copyright >> - return DEFAULT also when user constraints are null > > Nice catch. Thank you! hi @XueleiFan I'd appreciate your approval here. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From xuelei at openjdk.java.net Tue Apr 19 13:48:26 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 19 Apr 2022 13:48:26 GMT Subject: RFR: 8284933: Improve debug in jdk.crypto.cryptoki [v2] In-Reply-To: References: Message-ID: > Hi, > > May I have the simple update reviewed? > > In the jdk.crypto.cryptoki module implementation, some of the debug information could be calculated even if the debug is not enabled, which is not resource friendly. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Remove debug() method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8277/files - new: https://git.openjdk.java.net/jdk/pull/8277/files/b75a8487..75061bdc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8277&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8277&range=00-01 Stats: 14 lines in 1 file changed: 0 ins; 4 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/8277.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8277/head:pull/8277 PR: https://git.openjdk.java.net/jdk/pull/8277 From xuelei at openjdk.java.net Tue Apr 19 13:48:27 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 19 Apr 2022 13:48:27 GMT Subject: RFR: 8284933: Improve debug in jdk.crypto.cryptoki In-Reply-To: <03wjShSptSwHWtStL-E6ub0WyXFy2QLs-M8GPZG6emA=.e605cd3c-e096-49f5-85e2-9f2d688cfd56@github.com> References: <03wjShSptSwHWtStL-E6ub0WyXFy2QLs-M8GPZG6emA=.e605cd3c-e096-49f5-85e2-9f2d688cfd56@github.com> Message-ID: On Mon, 18 Apr 2022 21:54:22 GMT, Valerie Peng wrote: > With this change, I see no reason to have debug(...) method. May as well just remove it and simply do a "System.out.println(...);"? Yes, that's my preferred style as well. Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8277 From xuelei at openjdk.java.net Tue Apr 19 13:55:28 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 19 Apr 2022 13:55:28 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v5] In-Reply-To: References: <09nZBWUg9qc9kFIJvVfx0BnzyyVp3t2bAJlKV1wQt28=.12a424f0-81fb-4b53-91cd-c7cec9ffdea8@github.com> Message-ID: <1s-5K4wvEzBdLNLXBULWd2SrPLvIe58fj1KoPS6-sqE=.b18c0ff1-29ff-4a36-b045-4157d34e0d83@github.com> On Tue, 19 Apr 2022 00:12:26 GMT, Brent Christian wrote: >> I think it is safer to add the check for 'hModule'. >> >> >> - if (moduleData != NULL) { >> + if (moduleData != NULL && moduleData->hModule != NULL) { > > That is very safe -- we already checked that `ckpNativeData != 0L` Hm, I see now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From xuelei at openjdk.java.net Tue Apr 19 14:00:06 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 19 Apr 2022 14:00:06 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v7] In-Reply-To: References: Message-ID: > This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: remove duplicated checking ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8248/files - new: https://git.openjdk.java.net/jdk/pull/8248/files/71b957fe..0de98b92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8248&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8248&range=05-06 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8248.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8248/head:pull/8248 PR: https://git.openjdk.java.net/jdk/pull/8248 From xuelei at openjdk.java.net Tue Apr 19 14:00:07 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 19 Apr 2022 14:00:07 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v6] In-Reply-To: References: Message-ID: <7Kby-8r3llR8SWQwcpbq6YZeFIu7Gv3wIBZmeNTAJ_I=.767f3df7-6c5b-4568-a32a-6c5da91ea10f@github.com> On Tue, 19 Apr 2022 00:14:06 GMT, Valerie Peng wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update signatures for native code > > src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c line 274: > >> 272: ModuleData *moduleData = jlong_to_ptr(ckpNativeData); >> 273: >> 274: if (moduleData != NULL && moduleData->hModule != NULL) { > > The moduleData != NULL check seems to duplicate with the line 271? Otherwise looks fine. Hm, I see. Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From xuelei at openjdk.java.net Tue Apr 19 14:03:30 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 19 Apr 2022 14:03:30 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v3] In-Reply-To: <-1bnefBpuQA1cHNaN93ULwBskNsIU49tYw6sUE9a_TI=.e7ef496c-d6a0-4f3c-900f-5f817b77c5cf@github.com> References: <-1bnefBpuQA1cHNaN93ULwBskNsIU49tYw6sUE9a_TI=.e7ef496c-d6a0-4f3c-900f-5f817b77c5cf@github.com> Message-ID: <4rMlf6uADKuBv9Y2ofS6Zk17BSikBI-FPrl9v7mXSOA=.1ce3e035-35ad-4799-9865-eba19af59944@github.com> On Wed, 13 Apr 2022 06:46:51 GMT, Xue-Lei Andrew Fan wrote: >> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: >> >> - add more factory methods, update copyright >> - return DEFAULT also when user constraints are null > > Nice catch. Thank you! > hi @XueleiFan I'd appreciate your approval here. Thanks! Sorry, I missed the notification emails. I will have a look today. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From xuelei at openjdk.java.net Tue Apr 19 14:32:29 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 19 Apr 2022 14:32:29 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v3] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 21:05:06 GMT, Daniel Jeli?ski wrote: >> During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. >> >> This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - add more factory methods, update copyright > - return DEFAULT also when user constraints are null Thanks for the update. It looks good to me, except comments for the coding style. src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 94: > 92: * @return a SSLAlgorithmConstraints instance > 93: */ > 94: static AlgorithmConstraints forSocket(SSLSocket socket, I like the idea to use a static method for the construction. What do you think if the same coding style is used for other constructors, by making them private and add forSocket() methods accordingly? For example, changing the following constructor to a private method. SSLAlgorithmConstraints(SSLEngine engine, String[] supportedAlgorithms, boolean withDefaultCertPathConstraints) { src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 118: > 116: if (userSpecifiedConstraints == null) { > 117: return withDefaultCertPathConstraints ? DEFAULT : DEFAULT_SSL_ONLY; > 118: } It looks like a partial duplicate of nullIfDefault(). What do you think if merging the logic into nullIfDefault()? Or even merging nullIfDefault() logic into the getUserSpecifiedConstraints() method? New parameters may be required for the getUserSpecifiedConstraints() methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From xuelei at openjdk.java.net Tue Apr 19 14:39:27 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 19 Apr 2022 14:39:27 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: <6kwPo15egFhWziB4JTw9_-Q_3hfRxI0QWVOkBqjxVs0=.20c03513-c6b7-4f3e-a13c-ca2efad17a13@github.com> Message-ID: On Mon, 18 Apr 2022 20:04:05 GMT, Sean Mullan wrote: >> Yes, exactly. I'd recommend it calling `cleanable.clean()` prior to storing the new password, so that the cleaning action for the old password is explicitly and immediately unregistered. > > Yes, I suppose that is a good enough reason, although this class never had a finalizer AFAIK. Won't there be a small performance hit (perhaps negligible) for code that already calls `clearPassword`? A specification clarification would provide clarity to applications that they do not have to call `clearPassword` in between calls to `setPassword`. Something as simple as: "This method clears the value of any previously stored password before storing the input password". > If `setPassword` is called twice in succession, should the previous password be cleaned before the new one is assigned and registered? Awesome, thank you! That what I want to archive while I filed the bug, but did not get an idea about how to clean the existing passwords during cleanup. It's pretty simple and straightforward to get it done in the setPassword. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From xuelei at openjdk.java.net Tue Apr 19 15:06:25 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 19 Apr 2022 15:06:25 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 17:45:22 GMT, Sean Mullan wrote: > I am not quite seeing the rationale for this change. There were a lot of effort to clean up the buffering password in JDK. In some circumstances, the PasswordCallback would be called for further using of the password. However, because the call to PasswordCallback, the password cleanup effort was void as PasswordCallback will have a copy of the password in the memory. For example, in the P11KeyStore implementation, there is an effort to clean up the password while finalizing. ` Arrays.fill(password, ' '); ` However, the password has been set to the PasswordCallback, and where a copy is placed in the memory. PasswordCallback pc = (PasswordCallback)callbacks[0]; pc.setPassword(password); // this clones the password if not null > Are you trying to protect against callers forgetting to call clearPassword? Is that really our responsibility? Yes, the clearPassword() method may be not called as expected. It may be not our responsibility, but it would be good to collect the password even if the clearPassword() method is not called. It is just something like to clean up the socket if socket.close() is not called. I may file another PR later, where password cleanup/destroy is should be called, but not actually. BTW, it may be nice to clarify the method relationship behaviors of PasswordCallback. It may be worthy of another PR. > Even if so, then @stuart-marks suggestion about clearing interim passwords is relevant and this solution seems incomplete. You are right. @stuart-marks suggestion makes sense to me. I will make the update accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From xuelei at openjdk.java.net Tue Apr 19 15:25:22 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 19 Apr 2022 15:25:22 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: <6kwPo15egFhWziB4JTw9_-Q_3hfRxI0QWVOkBqjxVs0=.20c03513-c6b7-4f3e-a13c-ca2efad17a13@github.com> Message-ID: On Tue, 19 Apr 2022 14:35:37 GMT, Xue-Lei Andrew Fan wrote: >> Yes, I suppose that is a good enough reason, although this class never had a finalizer AFAIK. Won't there be a small performance hit (perhaps negligible) for code that already calls `clearPassword`? A specification clarification would provide clarity to applications that they do not have to call `clearPassword` in between calls to `setPassword`. Something as simple as: "This method clears the value of any previously stored password before storing the input password". > >> If `setPassword` is called twice in succession, should the previous password be cleaned before the new one is assigned and registered? > > Awesome, thank you! That what I want to archive while I filed the bug, but did not get an idea about how to clean the existing passwords during cleanup. It's pretty simple and straightforward to get it done in the setPassword. > Won't there be a small performance hit (perhaps negligible) for code that already calls clearPassword? The impact should be minimal. If clearPassword() has been called, the cleanup (Cleanerable.clean()) won't happen again in the finalization or setPassword cleanup. > A specification clarification would provide clarity to applications that they do not have to call clearPassword in between calls to setPassword. As far as I know from the JDK code, it might be not common to call clearPassword in between calls to setPassword. I would like to have applications calling clearPassword() methods as before, if it is not missed, to speed up the collection rather than rely on finalization. The relationship among setPassword, getPassword and clearPassword() is complicated. I fully agree that the spec should be clarified. I would like to have the clarify update in another PR, and have this one focus on cleanup if an application forget to call clearPassword properly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From xuelei at openjdk.java.net Tue Apr 19 15:36:28 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 19 Apr 2022 15:36:28 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v3] In-Reply-To: References: Message-ID: > Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. > > The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: cleanup the previous password ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8272/files - new: https://git.openjdk.java.net/jdk/pull/8272/files/73692489..324f89fc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=01-02 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8272/head:pull/8272 PR: https://git.openjdk.java.net/jdk/pull/8272 From hchao at openjdk.java.net Tue Apr 19 16:17:59 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 19 Apr 2022 16:17:59 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms 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. ------------- Commit messages: - 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms Changes: https://git.openjdk.java.net/jdk/pull/8300/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255552 Stats: 319 lines in 7 files changed: 233 ins; 0 del; 86 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 ihse at openjdk.java.net Tue Apr 19 16:23:02 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 16:23:02 GMT Subject: RFR: 8284893: Fix typos in java.base [v2] In-Reply-To: References: Message-ID: > I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. > > Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Revert changes to 3rd party code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8250/files - new: https://git.openjdk.java.net/jdk/pull/8250/files/5e3a01c6..31baf0a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8250&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8250&range=00-01 Stats: 15 lines in 11 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8250.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8250/head:pull/8250 PR: https://git.openjdk.java.net/jdk/pull/8250 From ihse at openjdk.java.net Tue Apr 19 16:24:43 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 16:24:43 GMT Subject: RFR: 8284893: Fix typos in java.base [v3] In-Reply-To: References: Message-ID: <9c-dgwrotD5LE8w0H6RyhSbq4LRitonmI12tk7XyqO8=.aa61daf8-c124-4deb-9040-fbfbc9ffa9cf@github.com> > I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. > > Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Vertices -> vertices ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8250/files - new: https://git.openjdk.java.net/jdk/pull/8250/files/31baf0a3..2b029279 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8250&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8250&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8250.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8250/head:pull/8250 PR: https://git.openjdk.java.net/jdk/pull/8250 From ihse at openjdk.java.net Tue Apr 19 16:50:12 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 16:50:12 GMT Subject: RFR: 8284893: Fix typos in java.base [v4] In-Reply-To: References: Message-ID: > I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. > > Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Update Oracle copyrights - Also revert changes in ASM (3rd party code) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8250/files - new: https://git.openjdk.java.net/jdk/pull/8250/files/2b029279..a3f75247 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8250&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8250&range=02-03 Stats: 134 lines in 133 files changed: 0 ins; 0 del; 134 mod Patch: https://git.openjdk.java.net/jdk/pull/8250.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8250/head:pull/8250 PR: https://git.openjdk.java.net/jdk/pull/8250 From ihse at openjdk.java.net Tue Apr 19 16:50:14 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 16:50:14 GMT Subject: RFR: 8284893: Fix typos in java.base [v3] In-Reply-To: <9c-dgwrotD5LE8w0H6RyhSbq4LRitonmI12tk7XyqO8=.aa61daf8-c124-4deb-9040-fbfbc9ffa9cf@github.com> References: <9c-dgwrotD5LE8w0H6RyhSbq4LRitonmI12tk7XyqO8=.aa61daf8-c124-4deb-9040-fbfbc9ffa9cf@github.com> Message-ID: On Tue, 19 Apr 2022 16:24:43 GMT, Magnus Ihse Bursie wrote: >> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. >> >> (Due to false positives this can unfortunately not be run automatically) >> >> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. >> >> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Vertices -> vertices It's a bit annoying that 3rd party code is not more distinctly handled in the JDK source. :( I reverted the code pointed out by reviewers, but then later found the ASM code as well. If I feel really motivated (or bored) I might try to submit PRs with these fixes upstream. Or not. Everybody happy now? ------------- PR: https://git.openjdk.java.net/jdk/pull/8250 From lancea at openjdk.java.net Tue Apr 19 17:01:23 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 19 Apr 2022 17:01:23 GMT Subject: RFR: 8284893: Fix typos in java.base [v4] In-Reply-To: References: Message-ID: <1d8I8AuoQkCXZ8ITDlZS6b_i1JgDD6uS8zsSf_zZvpk=.02aead18-e100-4892-9ddb-d8d6d918625a@github.com> On Tue, 19 Apr 2022 16:50:12 GMT, Magnus Ihse Bursie wrote: >> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. >> >> (Due to false positives this can unfortunately not be run automatically) >> >> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. >> >> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Update Oracle copyrights > - Also revert changes in ASM (3rd party code) Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8250 From jkuhn at openjdk.java.net Tue Apr 19 17:08:28 2022 From: jkuhn at openjdk.java.net (Johannes Kuhn) Date: Tue, 19 Apr 2022 17:08:28 GMT Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> Message-ID: On Sun, 17 Apr 2022 16:17:30 GMT, liach wrote: > Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building. > > The main compatibility changes and their rationales are: > 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior. > - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes. > - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain. > - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe. > 2. The disappearance of proxies in stack traces. > - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic. > > A summary of the rest of the changes: > 1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well. > 2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups. > 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance. > > In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)? > > Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed. About deserializing Proxies, this is currently done in 3 steps: 1. Finding the class 2. Allocating a new instance and invoke the constructor of the **first non-serializable superclass** 3. Setting the fields of the instance Only step 2 is problematic here: 1. For a proxy, the class is serialized using a TC_PROXYCLASSDESC. when deserialized it invokes `Proxy.getProxyClass` (https://github.com/openjdk/jdk/blob/13fb1eed52f1a9152242119969a9d4a0c0627513/src/java.base/share/classes/java/io/ObjectInputStream.java#L891). For this step, it doesn't matter if `Proxy.getProxyClass` returns a normal class or a hidden class. 2. Allocating and calling the constructor: This part is currently implemented by spinning a class. The generated bytecode looks more or less like this: anew ProxyClass invokespecial Object.() The big lie here is that methods and constructors are different - but constructors are just methods, and the verifier makes sure that a constructor is called only once, exactly once, and that uninitialized instances don't escape. This doesn't work for hidden classes - as the hidden class can not be named in an other class. But MethodHandles can do this. Here is one of my old prototypes, based on a prototype for implementing reflection using MethodHandles from Mandy Chung: https://github.com/dasbrain/jdk/compare/ae45c5de7fc635df4dc86b764405158c245d2765...fbb0a63436f696a85e7039c0e109c379dfa1edce 3. Setting the fields uses deep reflection. But the hidden class themself doesn't have any fields - just it's superclass `java.lang.reflect.Proxy.h`. This is not a problem if the class can be instantiated at all (see step 2). ------------- PR: https://git.openjdk.java.net/jdk/pull/8278 From djelinski at openjdk.java.net Tue Apr 19 17:16:29 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 19 Apr 2022 17:16:29 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v4] In-Reply-To: References: Message-ID: <7OEfIY2-RXBhUkvin77qAGz68TRtzHgSaZ7KhBIFcWE=.00189301-9c42-46a3-8bd1-e0c83ef8c7c1@github.com> > During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. > > This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Replace remaining constructors with factory methods ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8199/files - new: https://git.openjdk.java.net/jdk/pull/8199/files/e4cc8152..2a1f0a1d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8199&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8199&range=02-03 Stats: 58 lines in 4 files changed: 21 ins; 14 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/8199.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8199/head:pull/8199 PR: https://git.openjdk.java.net/jdk/pull/8199 From duke at openjdk.java.net Tue Apr 19 17:24:22 2022 From: duke at openjdk.java.net (liach) Date: Tue, 19 Apr 2022 17:24:22 GMT Subject: RFR: JDK-8242888: Convert dynamic proxy to hidden classes In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com> Message-ID: On Sun, 17 Apr 2022 16:17:30 GMT, liach wrote: > Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building. > > The main compatibility changes and their rationales are: > 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior. > - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes. > - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain. > - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe. > 2. The disappearance of proxies in stack traces. > - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic. > > A summary of the rest of the changes: > 1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well. > 2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups. > 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance. > > In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)? > > Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed. Fixing deserialization is not particularly hard. A longer term goal is to declare a readResolve for proxies (presumably by extra methods on invocation handlers) to convert serialization result to something else ------------- PR: https://git.openjdk.java.net/jdk/pull/8278 From djelinski at openjdk.java.net Tue Apr 19 17:24:25 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 19 Apr 2022 17:24:25 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v3] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 14:23:07 GMT, Xue-Lei Andrew Fan wrote: >> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: >> >> - add more factory methods, update copyright >> - return DEFAULT also when user constraints are null > > src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 94: > >> 92: * @return a SSLAlgorithmConstraints instance >> 93: */ >> 94: static AlgorithmConstraints forSocket(SSLSocket socket, > > I like the idea to use a static method for the construction. What do you think if the same coding style is used for other constructors, by making them private and add forSocket() methods accordingly? For example, changing the following constructor to a private method. > > SSLAlgorithmConstraints(SSLEngine engine, String[] supportedAlgorithms, > boolean withDefaultCertPathConstraints) { it won't change the performance in any way - when `supportedAlgorithms` are set, we always need to create a new object. But you're right, it's inconsistent to offer both constructors and factory methods in the same class. Changed. > src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 118: > >> 116: if (userSpecifiedConstraints == null) { >> 117: return withDefaultCertPathConstraints ? DEFAULT : DEFAULT_SSL_ONLY; >> 118: } > > It looks like a partial duplicate of nullIfDefault(). What do you think if merging the logic into nullIfDefault()? Or even merging nullIfDefault() logic into the getUserSpecifiedConstraints() method? New parameters may be required for the getUserSpecifiedConstraints() methods. I'm not a big fan of modifying `getUserSpecifiedConstraints`; that method has 3 `return` clauses. But you're right, there was some code duplication that is removed now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From mullan at openjdk.java.net Tue Apr 19 19:15:33 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 19 Apr 2022 19:15:33 GMT Subject: RFR: 8284893: Fix typos in java.base [v4] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 16:50:12 GMT, Magnus Ihse Bursie wrote: >> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. >> >> (Due to false positives this can unfortunately not be run automatically) >> >> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. >> >> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Update Oracle copyrights > - Also revert changes in ASM (3rd party code) Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8250 From naoto at openjdk.java.net Tue Apr 19 19:43:24 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 19 Apr 2022 19:43:24 GMT Subject: RFR: 8284893: Fix typos in java.base [v4] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 16:50:12 GMT, Magnus Ihse Bursie wrote: >> I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. >> >> (Due to false positives this can unfortunately not be run automatically) >> >> The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. >> >> Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Update Oracle copyrights > - Also revert changes in ASM (3rd party code) Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8250 From valeriep at openjdk.java.net Tue Apr 19 19:50:42 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 19 Apr 2022 19:50:42 GMT Subject: RFR: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki [v7] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 14:00:06 GMT, Xue-Lei Andrew Fan wrote: >> This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > remove duplicated checking Marked as reviewed by valeriep (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From mullan at openjdk.java.net Tue Apr 19 19:58:29 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 19 Apr 2022 19:58:29 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec [v3] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 23:36:56 GMT, Valerie Peng wrote: >> This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring. >> >> The CSR will be filed once review is somewhat finished. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Removed the private no-arg default constructor and minor javadoc update. Marked as reviewed by mullan (Reviewer). src/java.base/share/classes/javax/crypto/spec/OAEPParameterSpec.java line 99: > 97: * @deprecated This field uses the default values defined in the PKCS #1 > 98: * standard. Some of these defaults are no longer recommended due > 99: * to advances in cryptanalysis -- see the Remove "the". src/java.base/share/classes/javax/crypto/spec/OAEPParameterSpec.java line 126: > 124: * {@link #getMGFParameters()} > 125: * @param pSrc the source of the encoding input P > 126: * @exception NullPointerException if {@code mdName}, Change `@exception` to the more accepted `@throws` tag. ------------- PR: https://git.openjdk.java.net/jdk/pull/8191 From ihse at openjdk.java.net Tue Apr 19 20:11:29 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 20:11:29 GMT Subject: Integrated: 8284893: Fix typos in java.base In-Reply-To: References: Message-ID: <1JP1QqXE1B7A6L1N5N8p82g_xrIWs1lr8qSVV-QPzA0=.06021c8b-0602-4bd7-a69f-fc9b1af22832@github.com> On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `src/java.base` directory, and accepted those changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in comments. A handful is in strings, one in a local variable name, and a couple in parameter declarations. > > Annoyingly, there are several instances of "childs" (instead of "children") in the source code, but they were not local and I dared not change them. Someone braver than me might take a stab at it, perhaps.. This pull request has now been integrated. Changeset: fb469fb8 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/fb469fb894ed84686f9fec5787ac99eb535fdd18 Stats: 369 lines in 162 files changed: 0 ins; 0 del; 369 mod 8284893: Fix typos in java.base Reviewed-by: iris, wetmore, lancea, mullan, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/8250 From valeriep at openjdk.java.net Tue Apr 19 21:18:26 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 19 Apr 2022 21:18:26 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec [v3] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 19:52:34 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed the private no-arg default constructor and minor javadoc update. > > src/java.base/share/classes/javax/crypto/spec/OAEPParameterSpec.java line 99: > >> 97: * @deprecated This field uses the default values defined in the PKCS #1 >> 98: * standard. Some of these defaults are no longer recommended due >> 99: * to advances in cryptanalysis -- see the > > Remove "the". Ok~ ------------- PR: https://git.openjdk.java.net/jdk/pull/8191 From valeriep at openjdk.java.net Tue Apr 19 21:28:27 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 19 Apr 2022 21:28:27 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec [v3] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 19:54:24 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed the private no-arg default constructor and minor javadoc update. > > src/java.base/share/classes/javax/crypto/spec/OAEPParameterSpec.java line 126: > >> 124: * {@link #getMGFParameters()} >> 125: * @param pSrc the source of the encoding input P >> 126: * @exception NullPointerException if {@code mdName}, > > Change `@exception` to the more accepted `@throws` tag. Yes, will change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8191 From valeriep at openjdk.java.net Tue Apr 19 21:36:20 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 19 Apr 2022 21:36:20 GMT Subject: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec [v4] In-Reply-To: References: Message-ID: <-mVKmafgPQEF5f7V5x3YJVCoaRZzyLg2025i5OIvAjs=.f0199946-119a-41d5-a7ee-3bfbdf1b3aa3@github.com> > This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring. > > The CSR will be filed once review is somewhat finished. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Remove "the" and change to "@throws". ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8191/files - new: https://git.openjdk.java.net/jdk/pull/8191/files/a760fc51..cbae8613 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8191&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8191&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8191/head:pull/8191 PR: https://git.openjdk.java.net/jdk/pull/8191 From xuelei at openjdk.java.net Tue Apr 19 21:56:32 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 19 Apr 2022 21:56:32 GMT Subject: Integrated: 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 18:06:10 GMT, Xue-Lei Andrew Fan wrote: > This is an effort to fix a problem introduced in the fix for [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there is a problem with the code changes. The Runnables registered with Cleaner refer to the object being registered ('this'). Meaning, the Cleaner mechanism will keep the objects reachable, preventing them from being cleaned and collected. This pull request has now been integrated. Changeset: 60446746 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/60446746d41c3c80d9788a252b4a55afe44e1e7b Stats: 82 lines in 7 files changed: 32 ins; 24 del; 26 mod 8284855: Update needed to Cleaners added to jdk.crypto.cryptoki Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/8248 From valeriep at openjdk.java.net Tue Apr 19 22:06:25 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 19 Apr 2022 22:06:25 GMT Subject: RFR: 8284933: Improve debug in jdk.crypto.cryptoki [v2] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 13:48:26 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have the simple update reviewed? >> >> In the jdk.crypto.cryptoki module implementation, some of the debug information could be calculated even if the debug is not enabled, which is not resource friendly. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Remove debug() method Looks good to me. Thanks~ ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8277 From duke at openjdk.java.net Tue Apr 19 23:00:00 2022 From: duke at openjdk.java.net (Mark Powers) Date: Tue, 19 Apr 2022 23:00:00 GMT Subject: RFR: JDK-8284688 Minor cleanup could be done in java.security.jgss [v3] 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 ten commits: - fifth iteration - Merge - fourth iteration - third iteration - Merge - Merge - Merge - second iteration - first iteration ------------- Changes: https://git.openjdk.java.net/jdk/pull/7746/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7746&range=02 Stats: 929 lines in 73 files changed: 88 ins; 193 del; 648 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 xuelei at openjdk.java.net Wed Apr 20 04:33:26 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 20 Apr 2022 04:33:26 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v4] In-Reply-To: <7OEfIY2-RXBhUkvin77qAGz68TRtzHgSaZ7KhBIFcWE=.00189301-9c42-46a3-8bd1-e0c83ef8c7c1@github.com> References: <7OEfIY2-RXBhUkvin77qAGz68TRtzHgSaZ7KhBIFcWE=.00189301-9c42-46a3-8bd1-e0c83ef8c7c1@github.com> Message-ID: On Tue, 19 Apr 2022 17:16:29 GMT, Daniel Jeli?ski wrote: >> During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. >> >> This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Replace remaining constructors with factory methods src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 94: > 92: AlgorithmConstraints userSpecifiedConstraints, > 93: boolean withDefaultCertPathConstraints) { > 94: if (nullIfDefault(userSpecifiedConstraints) == null) { Do you wan to check DEFAULT_SSL_ONLY in the nullIfDefault() implementation? The logic of the block is a little bit hard to understand to me. src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 97: > 95: return withDefaultCertPathConstraints ? DEFAULT : DEFAULT_SSL_ONLY; > 96: } > 97: return new SSLAlgorithmConstraints(userSpecifiedConstraints, withDefaultCertPathConstraints); It would be nice to limit each line within 80 characters, which is useful for terminal users. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From xuelei at openjdk.java.net Wed Apr 20 04:33:26 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 20 Apr 2022 04:33:26 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v3] In-Reply-To: References: Message-ID: <3MgEgO0Ggyq3epSPKkdgL7oJX1uOe5kzZ9relYgmqjs=.2b5f1e6c-238b-43a2-ae89-69580e16c6d4@github.com> On Tue, 19 Apr 2022 17:21:20 GMT, Daniel Jeli?ski wrote: >> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 94: >> >>> 92: * @return a SSLAlgorithmConstraints instance >>> 93: */ >>> 94: static AlgorithmConstraints forSocket(SSLSocket socket, >> >> I like the idea to use a static method for the construction. What do you think if the same coding style is used for other constructors, by making them private and add forSocket() methods accordingly? For example, changing the following constructor to a private method. >> >> SSLAlgorithmConstraints(SSLEngine engine, String[] supportedAlgorithms, >> boolean withDefaultCertPathConstraints) { > > it won't change the performance in any way - when `supportedAlgorithms` are set, we always need to create a new object. But you're right, it's inconsistent to offer both constructors and factory methods in the same class. Changed. The variants of supportedAlgorithms could be limited. There might be a potential improvement. But it is out of the scope of this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From xuelei at openjdk.java.net Wed Apr 20 04:40:38 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 20 Apr 2022 04:40:38 GMT Subject: Integrated: 8284933: Improve debug in jdk.crypto.cryptoki In-Reply-To: References: Message-ID: On Sun, 17 Apr 2022 14:45:49 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have the simple update reviewed? > > In the jdk.crypto.cryptoki module implementation, some of the debug information could be calculated even if the debug is not enabled, which is not resource friendly. > > Thanks, > Xuelei This pull request has now been integrated. Changeset: 0f81d8fc Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/0f81d8fcc3fb703760b1cddb01861ea5031023fb Stats: 37 lines in 1 file changed: 20 ins; 6 del; 11 mod 8284933: Improve debug in jdk.crypto.cryptoki Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/8277 From djelinski at openjdk.java.net Wed Apr 20 10:32:16 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 20 Apr 2022 10:32:16 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v4] In-Reply-To: References: <7OEfIY2-RXBhUkvin77qAGz68TRtzHgSaZ7KhBIFcWE=.00189301-9c42-46a3-8bd1-e0c83ef8c7c1@github.com> Message-ID: On Wed, 20 Apr 2022 04:19:38 GMT, Xue-Lei Andrew Fan wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace remaining constructors with factory methods > > src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 94: > >> 92: AlgorithmConstraints userSpecifiedConstraints, >> 93: boolean withDefaultCertPathConstraints) { >> 94: if (nullIfDefault(userSpecifiedConstraints) == null) { > > Do you wan to check DEFAULT_SSL_ONLY in the nullIfDefault() implementation? The logic of the block is a little bit hard to understand to me. No I don't; it's for the same reason why I'm using `==` and not `equals`: `DEFAULT` is the only `SSLAlgorithmConstraints` instance that is ever used as `userSpecifiedConstraints` here. `DEFAULT` is used because [SSLConfiguration sets userSpecifiedAlgorithmConstraints to SSLAlgorithmConstraints.DEFAULT](https://github.com/openjdk/jdk/blob/6d8d156c97b90a9ab4776c6b42563a962d959741/src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java#L129). This feels wrong; the name suggests that the constraints should be specified by user, and should be null if the user doesn't touch them. `userSpecifiedAlgorithmConstraints` are accessible by `getSSLParameters().getAlgorithmConstraints()` on SSLEngineImpl and SSLSocketImpl. Returning `DEFAULT` here also feels wrong; as a user I would be concerned that setting my own algorithm constraints would replace the default ones. It doesn't, but that is not immediately apparent. We could initialize `userSpecifiedAlgorithmConstraints` to null, and back out all the other changes from this PR. The only reason why I didn't do that was because it would change the observable behavior (`getSSLParameters().getAlgorithmConstraints()` would return `null`). If you think we can live with that, I'll be happy to do that change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From kevinw at openjdk.java.net Wed Apr 20 14:04:32 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 20 Apr 2022 14:04:32 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Thu, 14 Apr 2022 18:04:16 GMT, Andrey Turbanov wrote: > I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948) ... I didn't think "JVMInvokeMethodSlack" was a typo. I think it's the idea of "slack space" meaning leftover space. We require a certain amount of this space. We need some slack on the stack, in order to invoke. ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From xuelei at openjdk.java.net Wed Apr 20 14:11:27 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 20 Apr 2022 14:11:27 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v4] In-Reply-To: <7OEfIY2-RXBhUkvin77qAGz68TRtzHgSaZ7KhBIFcWE=.00189301-9c42-46a3-8bd1-e0c83ef8c7c1@github.com> References: <7OEfIY2-RXBhUkvin77qAGz68TRtzHgSaZ7KhBIFcWE=.00189301-9c42-46a3-8bd1-e0c83ef8c7c1@github.com> Message-ID: <1rgeLD_uGJA3oqRtlNDNYTqYIT1uk_T4JNZlVeqlfIQ=.73fe546e-f620-4682-8803-b613a7e3243d@github.com> On Tue, 19 Apr 2022 17:16:29 GMT, Daniel Jeli?ski wrote: >> During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. >> >> This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Replace remaining constructors with factory methods Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From xuelei at openjdk.java.net Wed Apr 20 14:11:28 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 20 Apr 2022 14:11:28 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v4] In-Reply-To: References: <7OEfIY2-RXBhUkvin77qAGz68TRtzHgSaZ7KhBIFcWE=.00189301-9c42-46a3-8bd1-e0c83ef8c7c1@github.com> Message-ID: On Wed, 20 Apr 2022 10:28:39 GMT, Daniel Jeli?ski wrote: >> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 94: >> >>> 92: AlgorithmConstraints userSpecifiedConstraints, >>> 93: boolean withDefaultCertPathConstraints) { >>> 94: if (nullIfDefault(userSpecifiedConstraints) == null) { >> >> Do you wan to check DEFAULT_SSL_ONLY in the nullIfDefault() implementation? The logic of the block is a little bit hard to understand to me. > > No I don't; it's for the same reason why I'm using `==` and not `equals`: `DEFAULT` is the only `SSLAlgorithmConstraints` instance that is ever used as `userSpecifiedConstraints` here. > > `DEFAULT` is used because [SSLConfiguration sets userSpecifiedAlgorithmConstraints to SSLAlgorithmConstraints.DEFAULT](https://github.com/openjdk/jdk/blob/6d8d156c97b90a9ab4776c6b42563a962d959741/src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java#L129). This feels wrong; the name suggests that the constraints should be specified by user, and should be null if the user doesn't touch them. > `userSpecifiedAlgorithmConstraints` are accessible by `getSSLParameters().getAlgorithmConstraints()` on SSLEngineImpl and SSLSocketImpl. Returning `DEFAULT` here also feels wrong; as a user I would be concerned that setting my own algorithm constraints would replace the default ones. It doesn't, but that is not immediately apparent. > > We could initialize `userSpecifiedAlgorithmConstraints` to null, and back out all the other changes from this PR. The only reason why I didn't do that was because it would change the observable behavior (`getSSLParameters().getAlgorithmConstraints()` would return `null`). If you think we can live with that, I'll be happy to do that change. It is not interested to me to use 'null' constraints in ssl configure. I have no more comments. Thank you for the update! ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From sean.mullan at oracle.com Wed Apr 20 15:01:14 2022 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 20 Apr 2022 11:01:14 -0400 Subject: Command line flag to disable finalizers. In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: <95e54dac-e969-ffc6-cb84-9fa4cd0988c4@oracle.com> On 4/15/22 10:46 PM, Peter Firmstone wrote: > To securely instrument access controls onto public Java API, we need to > have the ability to disable finalizers, to prevent finalizer attacks > from circumventing access controls. > > Since finalizers are planned for removal, as soon as finalizers are > officially deprecated, I propose a command line flag be provided to > disable jvm calls to finalizer methods. This is already supported. JEP 421 added a "--finalization=disabled" option to JDK 18: https://openjdk.java.net/jeps/421#Command-line-option-to-disable-finalization --Sean From xuelei at openjdk.java.net Wed Apr 20 15:12:23 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 20 Apr 2022 15:12:23 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v5] 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: Update to set context method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8136/files - new: https://git.openjdk.java.net/jdk/pull/8136/files/464d3981..83bc4164 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=03-04 Stats: 47 lines in 6 files changed: 29 ins; 9 del; 9 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 xuelei at openjdk.java.net Wed Apr 20 15:24:37 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 20 Apr 2022 15:24:37 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v6] 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 two additional commits since the last revision: - More code cleanup - re-org the code per feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8136/files - new: https://git.openjdk.java.net/jdk/pull/8136/files/83bc4164..232d2a60 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=04-05 Stats: 10 lines in 2 files changed: 2 ins; 6 del; 2 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 dfuchs at openjdk.java.net Wed Apr 20 15:24:40 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 20 Apr 2022 15:24:40 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v5] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 15:12:23 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: > > Update to set context method src/java.security.jgss/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java line 378: > 376: if (pContext != 0 && cleanable != null) { > 377: cleanable.clean(); > 378: pContext = 0; Here and below: should pContext be set to 0 before calling cleanable.clean() to make sure cleanable.clean() is not called twice? Also should there be some synchronized block? ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From ascarpino at openjdk.java.net Wed Apr 20 15:50:27 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 20 Apr 2022 15:50:27 GMT Subject: RFR: 8284291: sun/security/krb5/auto/Renew.java fails intermittently on Windows 11 In-Reply-To: <7cLC6wodHE-fIdkYIcrtWyuR-JDBncmnBM9KUpAluK4=.96ca7029-35c7-4b42-bf18-5d81a7c1dc03@github.com> References: <7cLC6wodHE-fIdkYIcrtWyuR-JDBncmnBM9KUpAluK4=.96ca7029-35c7-4b42-bf18-5d81a7c1dc03@github.com> Message-ID: On Mon, 4 Apr 2022 21:27:51 GMT, Weijun Wang wrote: > `Thread.sleep()` seems not very precise on some systems. Update this test to check the current time continously. Marked as reviewed by ascarpino (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8098 From xuelei at openjdk.java.net Wed Apr 20 15:54:07 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 20 Apr 2022 15:54:07 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v7] 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: change the calling order in dispose() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8136/files - new: https://git.openjdk.java.net/jdk/pull/8136/files/232d2a60..aed8cd32 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=05-06 Stats: 2 lines in 1 file changed: 1 ins; 1 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 xuelei at openjdk.java.net Wed Apr 20 15:54:08 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 20 Apr 2022 15:54:08 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v5] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 15:20:15 GMT, Daniel Fuchs wrote: > Also should there be some synchronized block? I thought about the synchronization issue. It looks like this class is not multiple-threads safe, and thus the upper layer will take care of the synchronization. So I did not add synchronization in this class update. > should pContext be set to 0 before calling cleanable.clean() to make sure cleanable.clean() is not called twice? Cleanable.clean() will work one time only, no matter how many time it is called. But it looks like better to make a change here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From mullan at openjdk.java.net Wed Apr 20 16:13:28 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 20 Apr 2022 16:13:28 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 02:44:01 GMT, Valerie Peng wrote: >> Hmm, I tried the suggested approach in (1), the result looks very lengthy. Actually, the Cipher.init(..) methods already has a few paragraphs describing the behavior for parameter generation, perhaps we should not repeat stating the "If this cipher was initialized" vs "was not initialized" since lengthy description may confuse users and have higher risks of inconsistency. What do you think? >> As for (2), currently only RSASSA-PSS signature impl uses parameters. When specified using PSSParameterSpec, it's possible that some of the parameters are not set, so it's possible for providers to use provider-specific default values for PSS case. So, yes, Signature class may have to updated in the same way to cover this particular scenario. > > For (1), how about something like below: > >> *

The returned parameters may be the same that were used to initialize >> * this cipher, or may contain additional default or random parameter >> * values used by the underlying cipher implementation. If no parameters >> * is supplied and this cipher successfully generated the required >> * parameter values, it will be returned. Otherwise, {@code null} is >> * returned. > Hmm, I tried the suggested approach in (1), the result looks very lengthy. Actually, the Cipher.init(..) methods already has a few paragraphs describing the behavior for parameter generation, perhaps we should not repeat stating the "If this cipher was initialized" vs "was not initialized" since lengthy description may confuse users and have higher risks of inconsistency. What do you think? That's a good point, the `init` methods do go into a lot of detail about that. > As for (2), currently only RSASSA-PSS signature impl uses parameters. When specified using PSSParameterSpec, it's possible that some of the parameters are not set, so it's possible for providers to use provider-specific default values for PSS case. So, yes, Signature class may have to updated in the same way to cover this particular scenario. Ok, I think we should try to make the spec consistent across `Cipher` and `Signature` once we settle on the right wording. I think it would be better to do it as part of this issue, but I would be ok doing it later as long as it is also fixed in 19. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From mullan at openjdk.java.net Wed Apr 20 16:44:29 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 20 Apr 2022 16:44:29 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 16:10:17 GMT, Sean Mullan wrote: >> For (1), how about something like below: >> >>> *

The returned parameters may be the same that were used to initialize >>> * this cipher, or may contain additional default or random parameter >>> * values used by the underlying cipher implementation. If no parameters >>> * is supplied and this cipher successfully generated the required >>> * parameter values, it will be returned. Otherwise, {@code null} is >>> * returned. > >> Hmm, I tried the suggested approach in (1), the result looks very lengthy. Actually, the Cipher.init(..) methods already has a few paragraphs describing the behavior for parameter generation, perhaps we should not repeat stating the "If this cipher was initialized" vs "was not initialized" since lengthy description may confuse users and have higher risks of inconsistency. What do you think? > > That's a good point, the `init` methods do go into a lot of detail about that. > >> As for (2), currently only RSASSA-PSS signature impl uses parameters. When specified using PSSParameterSpec, it's possible that some of the parameters are not set, so it's possible for providers to use provider-specific default values for PSS case. So, yes, Signature class may have to updated in the same way to cover this particular scenario. > > Ok, I think we should try to make the spec consistent across `Cipher` and `Signature` once we settle on the right wording. I think it would be better to do it as part of this issue, but I would be ok doing it later as long as it is also fixed in 19. > For (1), how about something like below: > > > ``` > > *

The returned parameters may be the same that were used to initialize > > * this cipher, or may contain additional default or random parameter > > * values used by the underlying cipher implementation. I like this first sentence. > > If no parameters > > * is supplied and this cipher successfully generated the required > > * parameter values, it will be returned. What does "successfully" mean? If it wasn't successful, what happens? Maybe we should avoid that word. How about: "If parameters were not supplied and this cipher requires parameters, the returned parameters will contain the parameter values generated by the underlying cipher implementation." > > Otherwise, {@code null} is > > * returned. > > ``` ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From valeriep at openjdk.java.net Wed Apr 20 17:25:32 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 20 Apr 2022 17:25:32 GMT Subject: Integrated: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 01:27:35 GMT, Valerie Peng wrote: > This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring. > > The CSR will be filed once review is somewhat finished. > > Thanks, > Valerie This pull request has now been integrated. Changeset: 15ce8c61 Author: Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/15ce8c61956ec433bcb713c694e6cef7a61e3837 Stats: 53 lines in 2 files changed: 15 ins; 18 del; 20 mod 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/8191 From djelinski at openjdk.java.net Wed Apr 20 18:11:16 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 20 Apr 2022 18:11:16 GMT Subject: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice [v5] In-Reply-To: References: Message-ID: <8_9z5V3zNsmmzRbkmA4x4amYi4S5FY9iMpp5uHAPfJs=.fbb12373-bd6e-422b-a573-8de6ab05fcd9@github.com> > During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. > > This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Reduce line length ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8199/files - new: https://git.openjdk.java.net/jdk/pull/8199/files/2a1f0a1d..1a131d9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8199&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8199&range=03-04 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8199.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8199/head:pull/8199 PR: https://git.openjdk.java.net/jdk/pull/8199 From djelinski at openjdk.java.net Wed Apr 20 18:17:44 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 20 Apr 2022 18:17:44 GMT Subject: Integrated: 8284694: Avoid evaluating SSLAlgorithmConstraints twice In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeli?ski wrote: > During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another `SSLAlgorithmConstraints` instance. As a result the constraints defined in `SSLAlgorithmConstraints` are evaluated twice. > > This PR improves the default case; if the user-specified constraints are left at defaults, we use a single `SSLAlgorithmConstraints` instance, and avoid duplicate checks. This pull request has now been integrated. Changeset: d8446b4f Author: Daniel Jeli?ski URL: https://git.openjdk.java.net/jdk/commit/d8446b4f60472b11e4cdaef97288fe143cca4511 Stats: 427 lines in 7 files changed: 385 ins; 1 del; 41 mod 8284694: Avoid evaluating SSLAlgorithmConstraints twice Reviewed-by: redestad, xuelei, coffeys ------------- PR: https://git.openjdk.java.net/jdk/pull/8199 From weijun at openjdk.java.net Wed Apr 20 19:01:26 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 20 Apr 2022 19:01:26 GMT Subject: Integrated: 8284291: sun/security/krb5/auto/Renew.java fails intermittently on Windows 11 In-Reply-To: <7cLC6wodHE-fIdkYIcrtWyuR-JDBncmnBM9KUpAluK4=.96ca7029-35c7-4b42-bf18-5d81a7c1dc03@github.com> References: <7cLC6wodHE-fIdkYIcrtWyuR-JDBncmnBM9KUpAluK4=.96ca7029-35c7-4b42-bf18-5d81a7c1dc03@github.com> Message-ID: <41WRNZOGrgzcV3A-4OREQdtucNBUWdbr4hReoTXU-_I=.5f048894-3acf-4e2c-b695-648413517ca6@github.com> On Mon, 4 Apr 2022 21:27:51 GMT, Weijun Wang wrote: > `Thread.sleep()` seems not very precise on some systems. Update this test to check the current time continously. This pull request has now been integrated. Changeset: 05ae7ed1 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/05ae7ed1aac6fabc9c8820c12b6567fe93a3546f Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod 8284291: sun/security/krb5/auto/Renew.java fails intermittently on Windows 11 Reviewed-by: aturbanov, ascarpino ------------- PR: https://git.openjdk.java.net/jdk/pull/8098 From mullan at openjdk.java.net Wed Apr 20 19:33:22 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 20 Apr 2022 19:33:22 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 15:03:05 GMT, Xue-Lei Andrew Fan wrote: > > I am not quite seeing the rationale for this change. > > There were a lot of effort to clean up the buffering password in JDK. In some circumstances, the PasswordCallback would be called for further using of the password. However, because the call to PasswordCallback, the password cleanup effort was void as PasswordCallback will have a copy of the password in the memory. > > For example, in the P11KeyStore implementation, there is an effort to clean up the password while finalizing. ` Arrays.fill(password, ' ');` However, the password has been set to the PasswordCallback, and where a copy is placed in the memory. > > ``` > PasswordCallback pc = (PasswordCallback)callbacks[0]; > pc.setPassword(password); // this clones the password if not null > ``` Ok, but the [SunPKCS11 code clears the cloned password](https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java#L1513) as soon as it retrieves it from the Callback: pin = pcall.getPassword(); pcall.clearPassword(); > > Are you trying to protect against callers forgetting to call clearPassword? Is that really our responsibility? > > Yes, the clearPassword() method may be not called as expected. It may be not our responsibility, but it would be good to collect the password even if the clearPassword() method is not called. It is just something like to clean up the socket if socket.close() is not called. I may file another PR later, where password cleanup/destroy is should be called, but not actually. Ok, I can see how this can be a good DiD strategy. However, I think that we need to carefully check the interactions between cleaners and methods that explicitly allow the contents to be cleared so that there are not unexpected results. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From mullan at openjdk.java.net Wed Apr 20 20:02:28 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 20 Apr 2022 20:02:28 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: <6kwPo15egFhWziB4JTw9_-Q_3hfRxI0QWVOkBqjxVs0=.20c03513-c6b7-4f3e-a13c-ca2efad17a13@github.com> Message-ID: On Tue, 19 Apr 2022 15:21:49 GMT, Xue-Lei Andrew Fan wrote: > > Won't there be a small performance hit (perhaps negligible) for code that already calls clearPassword? > > The impact should be minimal. If clearPassword() has been called, the cleanup (Cleanerable.clean()) won't happen again in the finalization or setPassword cleanup. I don't think that is true, but maybe I am missing something. From looking at the code, it appears a `clearPassword` followed by a `setPassword` would call `Arrays.fill` twice on the same password. I think this can be fixed by setting the cleaner to null in the `clearPassword` method after the password has been cleared. I think this would address my concern and we may not need a spec. update (though I want to think it thru one more time). > > A specification clarification would provide clarity to applications that they do not have to call clearPassword in between calls to setPassword. > > As far as I know from the JDK code, it might be not common to call clearPassword in between calls to setPassword. I would like to have applications calling clearPassword() methods as before, if it is not missed, to speed up the collection rather than rely on finalization. Yes, I agree calling `clearPassword` should be recommended as a best practice and callers should not solely rely on cleaners. > The relationship among setPassword, getPassword and clearPassword() is complicated. I fully agree that the spec should be clarified. I would like to have the clarify update in another PR, and have this one focus on cleanup if an application forget to call clearPassword properly. See above. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From sean.coffey at oracle.com Wed Apr 20 20:19:48 2022 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 20 Apr 2022 21:19:48 +0100 Subject: AlgorithmConstraints caching [ was Re: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice] In-Reply-To: <08a9602e-1d50-334c-7121-cf3348463429@oracle.com> References: <08a9602e-1d50-334c-7121-cf3348463429@oracle.com> Message-ID: I think the work done with 8284694 will help alot in any case since I suspect the same SSLAlgorithmConstraints Object will be shared much more now (rather than spin off new copies) Some recent JFRs I looked at show that alot of CPU cycles[1] get taken in the HandshakeContext methods of : sun.security.ssl.HandshakeContext#getActiveCipherSuites sun.security.ssl.HandshakeContext#getActiveProtocols Both methods get called per Handshakecontext construction and I think each TLS handshake gets a new Handshakecontext.I was thinking that a cache of the last known variables used to deduce the getActiveCipherSuites and getActiveProtocols Lists could be created. That might have the potential to avoid alot of needless CPU cycles in this area since the parameters used to produce these Lists don't really change that often. I'm still looking into this potential and hope to share a patch shortly. regards, Sean. [1] Stack Trace??? Count??? Percentage TreeMap$Entry java.util.TreeMap.getEntryUsingComparator(Object) 1035??? 100?% TreeMap$Entry java.util.TreeMap.getEntry(Object)??? 1035??? 100?% boolean java.util.TreeMap.containsKey(Object)??? 1035??? 100?% boolean java.util.TreeSet.contains(Object)??? 1035??? 100?% boolean sun.security.util.AbstractAlgorithmConstraints.checkAlgorithm(Set, String, AlgorithmDecomposer)??? 1035??? 100?% boolean sun.security.util.DisabledAlgorithmConstraints.permits(Set, String, AlgorithmParameters)??? 1035??? 100?% boolean sun.security.ssl.SSLAlgorithmConstraints.permits(Set, String, AlgorithmParameters)??? 1035??? 100?% boolean sun.security.ssl.SSLAlgorithmConstraints.permits(Set, String, AlgorithmParameters)??? 553??? 53.4?% boolean sun.security.ssl.HandshakeContext.isActivatable(CipherSuite, AlgorithmConstraints, Map)??? 309??? 29.9?% List sun.security.ssl.HandshakeContext.getActiveCipherSuites(List, List, AlgorithmConstraints)??? 302??? 29.2?% void sun.security.ssl.HandshakeContext.(SSLContextImpl, TransportContext)??? 302??? 29.2?% void sun.security.ssl.ClientHandshakeContext.(SSLContextImpl, TransportContext)??? 302??? 29.2?% void sun.security.ssl.TransportContext.kickstart()??? 302 29.2?% void sun.security.ssl.SSLSocketImpl.startHandshake(boolean) 302??? 29.2?% On 13/04/2022 18:05, Anthony Scarpino wrote: > Hi Sean, > > Caching is an interesting idea.? I've wondered for a while off and on > about how to speed it up, but hadn't come up with a solution I liked. > The complication with caching is while something like an algorithm > name only could be easy in a hashmap, it gets more complicated when > you get into key sizes. Such as, how to represent RSA 1k being > disallowed and but 2k allowed.. or certificate usage.. > > Tony > > On 4/13/22 2:03 AM, Sean Coffey wrote: >> On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeli?ski >> wrote: >> >>> During TLS handshake, hundreds of constraints are evaluated to >>> determine which cipher suites are usable. Most of the evaluations >>> are performed using `HandshakeContext#algorithmConstraints` object. >>> By default that object contains a `SSLAlgorithmConstraints` instance >>> wrapping another `SSLAlgorithmConstraints` instance. As a result the >>> constraints defined in `SSLAlgorithmConstraints` are evaluated twice. >>> >>> This PR improves the default case; if the user-specified constraints >>> are left at defaults, we use a single `SSLAlgorithmConstraints` >>> instance, and avoid duplicate checks. >> >> Nice work. I've been looking at this area myself in recent weeks also >> while debugging some JDK 11u performance issues. JFR shows this area >> as costly. Some other JDK fixes in this area have already improved >> performance. This will certainly help. Pasting a stacktrace[1] from >> an old Oracle JDK 11.0.12 report for history purposes. >> >> I think there are other improvements that can be made in the TLS >> constraints code. Caching the last known values from a constraints >> permits test is something I've begun looking into. >> >> [1] >> Stack Trace??? Count??? Percentage >> boolean java.lang.StringLatin1.regionMatchesCI(byte[], int, byte[], >> int, int)??? 1637??? 100?% >> boolean java.lang.String.regionMatches(boolean, int, String, int, >> int)??? 1637??? 100?% >> boolean java.lang.String.equalsIgnoreCase(String)??? 1637 100?% >> boolean >> sun.security.util.AbstractAlgorithmConstraints.checkAlgorithm(List, >> String, AlgorithmDecomposer)??? 1631??? 99.6?% >> boolean sun.security.util.DisabledAlgorithmConstraints.permits(Set, >> String, AlgorithmParameters)??? 1631??? 99.6?% >> boolean sun.security.ssl.SSLAlgorithmConstraints.permits(Set, String, >> AlgorithmParameters)??? 1631??? 99.6?% >> boolean sun.security.ssl.SSLAlgorithmConstraints.permits(Set, String, >> AlgorithmParameters)??? 836??? 51.1?% >> boolean sun.security.ssl.HandshakeContext.isActivatable(CipherSuite, >> AlgorithmConstraints, Map)??? 428??? 26.1?% >> List sun.security.ssl.HandshakeContext.getActiveCipherSuites(List, >> List, AlgorithmConstraints)??? 418??? 25.5?% >> void sun.security.ssl.HandshakeContext.(SSLContextImpl, >> TransportContext)??? 418??? 25.5?% >> void sun.security.ssl.ClientHandshakeContext.(SSLContextImpl, >> TransportContext)??? 418??? 25.5?% >> void sun.security.ssl.TransportContext.kickstart()??? 418 25.5?% >> void sun.security.ssl.SSLSocketImpl.startHandshake(boolean) 418??? >> 25.5?% >> void sun.security.ssl.SSLSocketImpl.startHandshake()??? 418 25.5?% >> >> ------------- >> >> Marked as reviewed by coffeys (Reviewer). >> >> PR: https://git.openjdk.java.net/jdk/pull/8199 From duke at openjdk.java.net Wed Apr 20 20:33:00 2022 From: duke at openjdk.java.net (Mark Powers) Date: Wed, 20 Apr 2022 20:33:00 GMT Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security Message-ID: <6sHxbbp664HmxXaai8KmIs8gVNX2hWPpflb0yQ5CMqM=.48160444-5c49-496f-9efd-5b24cb0e43a9@github.com> 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 ------------- Commit messages: - 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=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285263 Stats: 665 lines in 100 files changed: 25 ins; 142 del; 498 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 rriggs at openjdk.java.net Wed Apr 20 21:13:26 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 20 Apr 2022 21:13:26 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: <6kwPo15egFhWziB4JTw9_-Q_3hfRxI0QWVOkBqjxVs0=.20c03513-c6b7-4f3e-a13c-ca2efad17a13@github.com> Message-ID: On Wed, 20 Apr 2022 19:59:16 GMT, Sean Mullan wrote: >>> Won't there be a small performance hit (perhaps negligible) for code that already calls clearPassword? >> >> The impact should be minimal. If clearPassword() has been called, the cleanup (Cleanerable.clean()) won't happen again in the finalization or setPassword cleanup. >> >>> A specification clarification would provide clarity to applications that they do not have to call clearPassword in between calls to setPassword. >> >> As far as I know from the JDK code, it might be not common to call clearPassword in between calls to setPassword. I would like to have applications calling clearPassword() methods as before, if it is not missed, to speed up the collection rather than rely on finalization. >> >> The relationship among setPassword, getPassword and clearPassword() is complicated. I fully agree that the spec should be clarified. I would like to have the clarify update in another PR, and have this one focus on cleanup if an application forget to call clearPassword properly. > >> > Won't there be a small performance hit (perhaps negligible) for code that already calls clearPassword? >> >> The impact should be minimal. If clearPassword() has been called, the cleanup (Cleanerable.clean()) won't happen again in the finalization or setPassword cleanup. > > I don't think that is true, but maybe I am missing something. From looking at the code, it appears a `clearPassword` followed by a `setPassword` would call `Arrays.fill` twice on the same password. I think this can be fixed by setting the cleaner to null in the `clearPassword` method after the password has been cleared. I think this would address my concern and we may not need a spec. update (though I want to think it thru one more time). > >> > A specification clarification would provide clarity to applications that they do not have to call clearPassword in between calls to setPassword. >> >> As far as I know from the JDK code, it might be not common to call clearPassword in between calls to setPassword. I would like to have applications calling clearPassword() methods as before, if it is not missed, to speed up the collection rather than rely on finalization. > > Yes, I agree calling `clearPassword` should be recommended as a best practice and callers should not solely rely on cleaners. > >> The relationship among setPassword, getPassword and clearPassword() is complicated. I fully agree that the spec should be clarified. I would like to have the clarify update in another PR, and have this one focus on cleanup if an application forget to call clearPassword properly. > > See above. Calling `Cleanable.clean()` calls the `Runnable` action at-most-once. Each `Cleanable` inserted in a list when it is created and is removed when `clear()` or `clean()` is invoked. The action is called only if it is still in the list. So there is no extra overhead. There is no harm in clearing the cleanable field; but it does not save much. The code in `clearPassword` can be simplified and only test `cleanable != null`; it will be null unless there is an inputPassword to clean. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From smarks at openjdk.java.net Wed Apr 20 23:42:23 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 20 Apr 2022 23:42:23 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: <6kwPo15egFhWziB4JTw9_-Q_3hfRxI0QWVOkBqjxVs0=.20c03513-c6b7-4f3e-a13c-ca2efad17a13@github.com> Message-ID: On Wed, 20 Apr 2022 21:09:54 GMT, Roger Riggs wrote: >>> > Won't there be a small performance hit (perhaps negligible) for code that already calls clearPassword? >>> >>> The impact should be minimal. If clearPassword() has been called, the cleanup (Cleanerable.clean()) won't happen again in the finalization or setPassword cleanup. >> >> I don't think that is true, but maybe I am missing something. From looking at the code, it appears a `clearPassword` followed by a `setPassword` would call `Arrays.fill` twice on the same password. I think this can be fixed by setting the cleaner to null in the `clearPassword` method after the password has been cleared. I think this would address my concern and we may not need a spec. update (though I want to think it thru one more time). >> >>> > A specification clarification would provide clarity to applications that they do not have to call clearPassword in between calls to setPassword. >>> >>> As far as I know from the JDK code, it might be not common to call clearPassword in between calls to setPassword. I would like to have applications calling clearPassword() methods as before, if it is not missed, to speed up the collection rather than rely on finalization. >> >> Yes, I agree calling `clearPassword` should be recommended as a best practice and callers should not solely rely on cleaners. >> >>> The relationship among setPassword, getPassword and clearPassword() is complicated. I fully agree that the spec should be clarified. I would like to have the clarify update in another PR, and have this one focus on cleanup if an application forget to call clearPassword properly. >> >> See above. > > Calling `Cleanable.clean()` calls the `Runnable` action at-most-once. > Each `Cleanable` inserted in a list when it is created and is removed when `clear()` or `clean()` is invoked. > The action is called only if it is still in the list. So there is no extra overhead. > > There is no harm in clearing the cleanable field; but it does not save much. > > The code in `clearPassword` can be simplified and only test `cleanable != null`; it will be null unless there is an inputPassword to clean. I'd recommend setting `cleanable` to null after it's been cleaned to make the state machine easier to reason about. The invariant would be: if `cleanable` is non-null, then we have something dirty that needs to be cleaned. If we don't clear it to null after cleaning, it potentially results in confusing states. For example, suppose the app calls `setPassword(nonNull)` and later calls `setPassword(null)`. The second call will set `inputPassword` to null but leave a stale reference in `cleanable`. This isn't necessarily harmful, but it's confusing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From duke at openjdk.java.net Thu Apr 21 04:18:06 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 21 Apr 2022 04:18:06 GMT Subject: RFR: JDK-8285263 Minor cleanup could be done in java.security [v2] 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 five commits: - 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=01 Stats: 656 lines in 100 files changed: 25 ins; 142 del; 489 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 xuelei at openjdk.java.net Thu Apr 21 06:55:22 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 21 Apr 2022 06:55:22 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v4] In-Reply-To: References: Message-ID: > Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. > > The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Code clean up per feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8272/files - new: https://git.openjdk.java.net/jdk/pull/8272/files/324f89fc..01542bb6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8272/head:pull/8272 PR: https://git.openjdk.java.net/jdk/pull/8272 From xuelei at openjdk.java.net Thu Apr 21 06:55:22 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 21 Apr 2022 06:55:22 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: <6kwPo15egFhWziB4JTw9_-Q_3hfRxI0QWVOkBqjxVs0=.20c03513-c6b7-4f3e-a13c-ca2efad17a13@github.com> Message-ID: On Wed, 20 Apr 2022 23:38:59 GMT, Stuart Marks wrote: >> Calling `Cleanable.clean()` calls the `Runnable` action at-most-once. >> Each `Cleanable` inserted in a list when it is created and is removed when `clear()` or `clean()` is invoked. >> The action is called only if it is still in the list. So there is no extra overhead. >> >> There is no harm in clearing the cleanable field; but it does not save much. >> >> The code in `clearPassword` can be simplified and only test `cleanable != null`; it will be null unless there is an inputPassword to clean. > > I'd recommend setting `cleanable` to null after it's been cleaned to make the state machine easier to reason about. The invariant would be: if `cleanable` is non-null, then we have something dirty that needs to be cleaned. If we don't clear it to null after cleaning, it potentially results in confusing states. For example, suppose the app calls `setPassword(nonNull)` and later calls `setPassword(null)`. The second call will set `inputPassword` to null but leave a stale reference in `cleanable`. This isn't necessarily harmful, but it's confusing. > The code in `clearPassword` can be simplified and only test `cleanable != null`; it will be null unless there is an inputPassword to clean. Yes. The testing of `cleanable != null` is sufficient. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From xuelei at openjdk.java.net Thu Apr 21 06:55:22 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 21 Apr 2022 06:55:22 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: <6kwPo15egFhWziB4JTw9_-Q_3hfRxI0QWVOkBqjxVs0=.20c03513-c6b7-4f3e-a13c-ca2efad17a13@github.com> Message-ID: On Thu, 21 Apr 2022 06:50:58 GMT, Xue-Lei Andrew Fan wrote: >> I'd recommend setting `cleanable` to null after it's been cleaned to make the state machine easier to reason about. The invariant would be: if `cleanable` is non-null, then we have something dirty that needs to be cleaned. If we don't clear it to null after cleaning, it potentially results in confusing states. For example, suppose the app calls `setPassword(nonNull)` and later calls `setPassword(null)`. The second call will set `inputPassword` to null but leave a stale reference in `cleanable`. This isn't necessarily harmful, but it's confusing. > >> The code in `clearPassword` can be simplified and only test `cleanable != null`; it will be null unless there is an inputPassword to clean. > > Yes. The testing of `cleanable != null` is sufficient. > I'd recommend setting `cleanable` to null after it's been cleaned to make the state machine easier to reason about. I like this idea. Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From ihse at openjdk.java.net Thu Apr 21 13:59:04 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 21 Apr 2022 13:59:04 GMT Subject: RFR: 8285380: Fix typos in security Message-ID: 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. ------------- Commit messages: - Pass #2 - Pass #1 Changes: https://git.openjdk.java.net/jdk/pull/8340/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8340&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285380 Stats: 100 lines in 63 files changed: 0 ins; 0 del; 100 mod Patch: https://git.openjdk.java.net/jdk/pull/8340.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8340/head:pull/8340 PR: https://git.openjdk.java.net/jdk/pull/8340 From alanb at openjdk.java.net Thu Apr 21 14:14:26 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 21 Apr 2022 14:14:26 GMT Subject: RFR: 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. The folks on security-dev will know for sure but I assume that the changes to the imported Apache Santuario code should be dropped as it will make upgrades more complicated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8340 From ihse at openjdk.java.net Thu Apr 21 15:27:30 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 21 Apr 2022 15:27:30 GMT Subject: RFR: 8285380: Fix typos in security In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 14:11:08 GMT, Alan Bateman 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. > > The folks on security-dev will know for sure but I assume that the changes to the imported Apache Santuario code should be dropped as it will make upgrades more complicated. @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... ------------- PR: https://git.openjdk.java.net/jdk/pull/8340 From alanb at openjdk.java.net Thu Apr 21 16:14:26 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 21 Apr 2022 16:14:26 GMT Subject: RFR: 8285380: Fix typos in security In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 14:11:08 GMT, Alan Bateman 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. > > The folks on security-dev will know for sure but I assume that the changes to the imported Apache Santuario code should be dropped as it will make upgrades more complicated. > @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). ------------- PR: https://git.openjdk.java.net/jdk/pull/8340 From ihse at openjdk.java.net Thu Apr 21 17:32:32 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 21 Apr 2022 17:32:32 GMT Subject: RFR: 8285380: Fix typos in security [v2] In-Reply-To: References: Message-ID: <8CkpsaXwOu9slGqU9bV9fF9EZx-Q_6BdgaMioe5MJWU=.6e49a022-bd0a-4fec-bdd8-8299381165d7@github.com> > 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. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Revert changes to Apache code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8340/files - new: https://git.openjdk.java.net/jdk/pull/8340/files/74a062cc..760e45c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8340&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8340&range=00-01 Stats: 19 lines in 11 files changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/8340.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8340/head:pull/8340 PR: https://git.openjdk.java.net/jdk/pull/8340 From djelinski at openjdk.java.net Thu Apr 21 20:47:58 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 21 Apr 2022 20:47:58 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: <9aX2MCVDVZtOEyydMLIe_6VQwoQ37GFVTpT2IuB8MU8=.9bb84513-8f3d-411d-80f4-9a69b566cf0c@github.com> On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeli?ski wrote: > Profiling the TLS handshakes using SSLHandshake benchmark shows that a large portion of time is spent in HandshakeContext initialization, specifically in DisabledAlgorithmConstraints class. > > There are only a few instances of that class, and they are immutable. Caching the results should be a low-risk operation. > > The cache is implemented as a softly reachable ConcurrentHashMap; this way it can be removed from memory after a period of inactivity. Under normal circumstances the cache holds no more than 100 algorithms. before: Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake true TLSv1.2 thrpt 5 2165.081 ? 440.204 ops/s SSLHandshake.doHandshake true TLS thrpt 5 534.681 ? 146.931 ops/s SSLHandshake.doHandshake false TLSv1.2 thrpt 5 369.104 ? 11.143 ops/s SSLHandshake.doHandshake false TLS thrpt 5 253.903 ? 58.056 ops/s after: Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake true TLSv1.2 thrpt 5 10440.501 ? 478.177 ops/s SSLHandshake.doHandshake true TLS thrpt 5 762.995 ? 33.842 ops/s SSLHandshake.doHandshake false TLSv1.2 thrpt 5 440.471 ? 52.867 ops/s SSLHandshake.doHandshake false TLS thrpt 5 305.928 ? 57.847 ops/s After this patch the HandshakeContext initialization practically disappears from the CPU profile; it only takes ~5% in TLS1.2 resumption, and much less in the remaining scenarios. ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From djelinski at openjdk.java.net Thu Apr 21 20:47:57 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 21 Apr 2022 20:47:57 GMT Subject: RFR: 8285398: Cache the results of constraint checks Message-ID: Profiling the TLS handshakes using SSLHandshake benchmark shows that a large portion of time is spent in HandshakeContext initialization, specifically in DisabledAlgorithmConstraints class. There are only a few instances of that class, and they are immutable. Caching the results should be a low-risk operation. The cache is implemented as a softly reachable ConcurrentHashMap; this way it can be removed from memory after a period of inactivity. Under normal circumstances the cache holds no more than 100 algorithms. ------------- Commit messages: - Implement constraint cache Changes: https://git.openjdk.java.net/jdk/pull/8349/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8349&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285398 Stats: 26 lines in 1 file changed: 23 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8349/head:pull/8349 PR: https://git.openjdk.java.net/jdk/pull/8349 From peter.firmstone at zeus.net.au Thu Apr 21 20:51:22 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 22 Apr 2022 06:51:22 +1000 Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: <9aX2MCVDVZtOEyydMLIe_6VQwoQ37GFVTpT2IuB8MU8=.9bb84513-8f3d-411d-80f4-9a69b566cf0c@github.com> References: <9aX2MCVDVZtOEyydMLIe_6VQwoQ37GFVTpT2IuB8MU8=.9bb84513-8f3d-411d-80f4-9a69b566cf0c@github.com> Message-ID: <71697808-ad82-f345-0a0b-19347642fc97@zeus.net.au> Nice. On 22/04/2022 6:47 am, Daniel Jeli?ski wrote: > On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeli?ski wrote: > >> Profiling the TLS handshakes using SSLHandshake benchmark shows that a large portion of time is spent in HandshakeContext initialization, specifically in DisabledAlgorithmConstraints class. >> >> There are only a few instances of that class, and they are immutable. Caching the results should be a low-risk operation. >> >> The cache is implemented as a softly reachable ConcurrentHashMap; this way it can be removed from memory after a period of inactivity. Under normal circumstances the cache holds no more than 100 algorithms. > before: > > Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units > SSLHandshake.doHandshake true TLSv1.2 thrpt 5 2165.081 ? 440.204 ops/s > SSLHandshake.doHandshake true TLS thrpt 5 534.681 ? 146.931 ops/s > SSLHandshake.doHandshake false TLSv1.2 thrpt 5 369.104 ? 11.143 ops/s > SSLHandshake.doHandshake false TLS thrpt 5 253.903 ? 58.056 ops/s > > after: > > Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units > SSLHandshake.doHandshake true TLSv1.2 thrpt 5 10440.501 ? 478.177 ops/s > SSLHandshake.doHandshake true TLS thrpt 5 762.995 ? 33.842 ops/s > SSLHandshake.doHandshake false TLSv1.2 thrpt 5 440.471 ? 52.867 ops/s > SSLHandshake.doHandshake false TLS thrpt 5 305.928 ? 57.847 ops/s > > After this patch the HandshakeContext initialization practically disappears from the CPU profile; it only takes ~5% in TLS1.2 resumption, and much less in the remaining scenarios. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/8349 -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From valeriep at openjdk.java.net Thu Apr 21 23:18:27 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 21 Apr 2022 23:18:27 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 16:40:34 GMT, Sean Mullan wrote: >>> Hmm, I tried the suggested approach in (1), the result looks very lengthy. Actually, the Cipher.init(..) methods already has a few paragraphs describing the behavior for parameter generation, perhaps we should not repeat stating the "If this cipher was initialized" vs "was not initialized" since lengthy description may confuse users and have higher risks of inconsistency. What do you think? >> >> That's a good point, the `init` methods do go into a lot of detail about that. >> >>> As for (2), currently only RSASSA-PSS signature impl uses parameters. When specified using PSSParameterSpec, it's possible that some of the parameters are not set, so it's possible for providers to use provider-specific default values for PSS case. So, yes, Signature class may have to updated in the same way to cover this particular scenario. >> >> Ok, I think we should try to make the spec consistent across `Cipher` and `Signature` once we settle on the right wording. I think it would be better to do it as part of this issue, but I would be ok doing it later as long as it is also fixed in 19. > >> For (1), how about something like below: >> >> > ``` >> > *

The returned parameters may be the same that were used to initialize >> > * this cipher, or may contain additional default or random parameter >> > * values used by the underlying cipher implementation. > > I like this first sentence. > >> > If no parameters >> > * is supplied and this cipher successfully generated the required >> > * parameter values, it will be returned. > > What does "successfully" mean? If it wasn't successful, what happens? Maybe we should avoid that word. How about: > > "If parameters were not supplied and this cipher requires parameters, the returned parameters will contain the parameter values generated by the underlying cipher implementation." > >> > Otherwise, {@code null} is >> > * returned. >> > ``` > > Hmm, I tried the suggested approach in (1), the result looks very lengthy. Actually, the Cipher.init(..) methods already has a few paragraphs describing the behavior for parameter generation, perhaps we should not repeat stating the "If this cipher was initialized" vs "was not initialized" since lengthy description may confuse users and have higher risks of inconsistency. What do you think? > > That's a good point, the `init` methods do go into a lot of detail about that. > > > As for (2), currently only RSASSA-PSS signature impl uses parameters. When specified using PSSParameterSpec, it's possible that some of the parameters are not set, so it's possible for providers to use provider-specific default values for PSS case. So, yes, Signature class may have to updated in the same way to cover this particular scenario. > > Ok, I think we should try to make the spec consistent across `Cipher` and `Signature` once we settle on the right wording. I think it would be better to do it as part of this issue, but I would be ok doing it later as long as it is also fixed in 19. I can do the Signature update through https://bugs.openjdk.java.net/browse/JDK-8253176 which I have targeted to fix in 19 also. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From valeriep at openjdk.java.net Thu Apr 21 23:35:27 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 21 Apr 2022 23:35:27 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 23:15:10 GMT, Valerie Peng wrote: >>> For (1), how about something like below: >>> >>> > ``` >>> > *

The returned parameters may be the same that were used to initialize >>> > * this cipher, or may contain additional default or random parameter >>> > * values used by the underlying cipher implementation. >> >> I like this first sentence. >> >>> > If no parameters >>> > * is supplied and this cipher successfully generated the required >>> > * parameter values, it will be returned. >> >> What does "successfully" mean? If it wasn't successful, what happens? Maybe we should avoid that word. How about: >> >> "If parameters were not supplied and this cipher requires parameters, the returned parameters will contain the parameter values generated by the underlying cipher implementation." >> >>> > Otherwise, {@code null} is >>> > * returned. >>> > ``` > >> > Hmm, I tried the suggested approach in (1), the result looks very lengthy. Actually, the Cipher.init(..) methods already has a few paragraphs describing the behavior for parameter generation, perhaps we should not repeat stating the "If this cipher was initialized" vs "was not initialized" since lengthy description may confuse users and have higher risks of inconsistency. What do you think? >> >> That's a good point, the `init` methods do go into a lot of detail about that. >> >> > As for (2), currently only RSASSA-PSS signature impl uses parameters. When specified using PSSParameterSpec, it's possible that some of the parameters are not set, so it's possible for providers to use provider-specific default values for PSS case. So, yes, Signature class may have to updated in the same way to cover this particular scenario. >> >> Ok, I think we should try to make the spec consistent across `Cipher` and `Signature` once we settle on the right wording. I think it would be better to do it as part of this issue, but I would be ok doing it later as long as it is also fixed in 19. > > I can do the Signature update through https://bugs.openjdk.java.net/browse/JDK-8253176 which I have targeted to fix in 19 also. As for the 2nd sentence, it boils down whether we requires provider to generate default parameters and return it when parameter is required. Existing javadoc states that null is returned when parameter is not required. Given Cipher covers many algorithms, if a provider does not want to generate a default parameter when parameter is required, it can't return null when getParameters() is called. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From duke at openjdk.java.net Fri Apr 22 02:21:24 2022 From: duke at openjdk.java.net (David Schlosnagle) Date: Fri, 22 Apr 2022 02:21:24 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeli?ski wrote: > Profiling the TLS handshakes using SSLHandshake benchmark shows that a large portion of time is spent in HandshakeContext initialization, specifically in DisabledAlgorithmConstraints class. > > There are only a few instances of that class, and they are immutable. Caching the results should be a low-risk operation. > > The cache is implemented as a softly reachable ConcurrentHashMap; this way it can be removed from memory after a period of inactivity. Under normal circumstances the cache holds no more than 100 algorithms. src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 969: > 967: result = checkAlgorithm(disabledAlgorithms, algorithm, decomposer); > 968: cache.put(algorithm, result); > 969: return result; Would it be worth using `cache.computeIfAbsent` or do you want to avoid lambda allocation overhead and potentially blocking concurrent handshakes on writer thread? Suggestion: return cache.computeIfAbsent(algorithm, algo -> checkAlgorithm(disabledAlgorithms, algo, decomposer)); ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From ascarpino at openjdk.java.net Fri Apr 22 04:04:26 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 22 Apr 2022 04:04:26 GMT Subject: RFR: 8283022: com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java failing with -Xcomp after 8273297 [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 20:43:06 GMT, Smita Kamath wrote: >> When input length provided to the intrinsic is 8192, only 7680 bytes are processed as the intrinsic operates on multiples of 768 bytes. >> In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method, >> dst.put(bout, 0, PARALLEL_LEN) statement caused the ciphertext mismatch as PARALLEL_LEN was set to 8192. >> Since the intrinsic only processed 7680 bytes, the rest output was incorrect. > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright year I'm not sure if the last commit removed the approval or not.. so i'll approve again ------------- Marked as reviewed by ascarpino (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8280 From xuelei at openjdk.java.net Fri Apr 22 06:33:00 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 22 Apr 2022 06:33:00 GMT Subject: RFR: 8285431: Assertion in NativeGSSContext constructor Message-ID: Hi, May I have the simple update reviewed. In the NativeGSSContext constructor for imported context, the assert is use on the object field, instead of the input parameters. As in a constructor, `'this'` object does not exist yet, this looks like an obvious issue. The fix is straightforward as well. NativeGSSContext(long pCtxt, GSSLibStub stub) throws GSSException { - assert(pContext != 0); + assert(pCtxt != 0); pContext = pCtxt; ... ------------- Commit messages: - 8285431: Assertion in NativeGSSContext constructor Changes: https://git.openjdk.java.net/jdk/pull/8355/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8355&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285431 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8355.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8355/head:pull/8355 PR: https://git.openjdk.java.net/jdk/pull/8355 From djelinski at openjdk.java.net Fri Apr 22 06:36:27 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 22 Apr 2022 06:36:27 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 02:13:14 GMT, David Schlosnagle wrote: >> Profiling the TLS handshakes using SSLHandshake benchmark shows that a large portion of time is spent in HandshakeContext initialization, specifically in DisabledAlgorithmConstraints class. >> >> There are only a few instances of that class, and they are immutable. Caching the results should be a low-risk operation. >> >> The cache is implemented as a softly reachable ConcurrentHashMap; this way it can be removed from memory after a period of inactivity. Under normal circumstances the cache holds no more than 100 algorithms. > > src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 969: > >> 967: result = checkAlgorithm(disabledAlgorithms, algorithm, decomposer); >> 968: cache.put(algorithm, result); >> 969: return result; > > Would it be worth using `cache.computeIfAbsent` or do you want to avoid lambda allocation overhead and potentially blocking concurrent handshakes on writer thread? > > Suggestion: > > return cache.computeIfAbsent(algorithm, algo -> checkAlgorithm(disabledAlgorithms, algo, decomposer)); I generally prefer using `get` over `computeIfAbsent` when optimizing for performance. While `computeIfAbsent` is more concise, it's also much slower than `get` when the entry is already present. ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From djelinski1 at gmail.com Fri Apr 22 10:02:32 2022 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Fri, 22 Apr 2022 12:02:32 +0200 Subject: AlgorithmConstraints caching [ was Re: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice] In-Reply-To: References: <08a9602e-1d50-334c-7121-cf3348463429@oracle.com> Message-ID: Hi Tony & Sean, As it turns out, caching the availability of algorithms is sufficient to get a massive speedup here. Check out the results on https://github.com/openjdk/jdk/pull/8349 and let me know what you think. Regards, Daniel ?r., 20 kwi 2022 o 22:22 Se?n Coffey napisa?(a): > > I think the work done with 8284694 will help alot in any case since I > suspect the same SSLAlgorithmConstraints Object will be shared much more > now (rather than spin off new copies) > > Some recent JFRs I looked at show that alot of CPU cycles[1] get taken > in the HandshakeContext methods of : > sun.security.ssl.HandshakeContext#getActiveCipherSuites > sun.security.ssl.HandshakeContext#getActiveProtocols > > Both methods get called per Handshakecontext construction and I think > each TLS handshake gets a new Handshakecontext.I was thinking that a > cache of the last known variables used to deduce the > getActiveCipherSuites and getActiveProtocols Lists could be created. > That might have the potential to avoid alot of needless CPU cycles in > this area since the parameters used to produce these Lists don't really > change that often. I'm still looking into this potential and hope to > share a patch shortly. > > regards, > Sean. > > [1] > > Stack Trace Count Percentage > TreeMap$Entry java.util.TreeMap.getEntryUsingComparator(Object) 1035 > 100 % > TreeMap$Entry java.util.TreeMap.getEntry(Object) 1035 100 % > boolean java.util.TreeMap.containsKey(Object) 1035 100 % > boolean java.util.TreeSet.contains(Object) 1035 100 % > boolean > sun.security.util.AbstractAlgorithmConstraints.checkAlgorithm(Set, > String, AlgorithmDecomposer) 1035 100 % > boolean sun.security.util.DisabledAlgorithmConstraints.permits(Set, > String, AlgorithmParameters) 1035 100 % > boolean sun.security.ssl.SSLAlgorithmConstraints.permits(Set, String, > AlgorithmParameters) 1035 100 % > boolean sun.security.ssl.SSLAlgorithmConstraints.permits(Set, String, > AlgorithmParameters) 553 53.4 % > boolean sun.security.ssl.HandshakeContext.isActivatable(CipherSuite, > AlgorithmConstraints, Map) 309 29.9 % > List sun.security.ssl.HandshakeContext.getActiveCipherSuites(List, List, > AlgorithmConstraints) 302 29.2 % > void sun.security.ssl.HandshakeContext.(SSLContextImpl, > TransportContext) 302 29.2 % > void sun.security.ssl.ClientHandshakeContext.(SSLContextImpl, > TransportContext) 302 29.2 % > void sun.security.ssl.TransportContext.kickstart() 302 29.2 % > void sun.security.ssl.SSLSocketImpl.startHandshake(boolean) 302 29.2 % > > > On 13/04/2022 18:05, Anthony Scarpino wrote: > > Hi Sean, > > > > Caching is an interesting idea. I've wondered for a while off and on > > about how to speed it up, but hadn't come up with a solution I liked. > > The complication with caching is while something like an algorithm > > name only could be easy in a hashmap, it gets more complicated when > > you get into key sizes. Such as, how to represent RSA 1k being > > disallowed and but 2k allowed.. or certificate usage.. > > > > Tony > > > > On 4/13/22 2:03 AM, Sean Coffey wrote: > >> On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeli?ski > >> wrote: > >> > >>> During TLS handshake, hundreds of constraints are evaluated to > >>> determine which cipher suites are usable. Most of the evaluations > >>> are performed using `HandshakeContext#algorithmConstraints` object. > >>> By default that object contains a `SSLAlgorithmConstraints` instance > >>> wrapping another `SSLAlgorithmConstraints` instance. As a result the > >>> constraints defined in `SSLAlgorithmConstraints` are evaluated twice. > >>> > >>> This PR improves the default case; if the user-specified constraints > >>> are left at defaults, we use a single `SSLAlgorithmConstraints` > >>> instance, and avoid duplicate checks. > >> > >> Nice work. I've been looking at this area myself in recent weeks also > >> while debugging some JDK 11u performance issues. JFR shows this area > >> as costly. Some other JDK fixes in this area have already improved > >> performance. This will certainly help. Pasting a stacktrace[1] from > >> an old Oracle JDK 11.0.12 report for history purposes. > >> > >> I think there are other improvements that can be made in the TLS > >> constraints code. Caching the last known values from a constraints > >> permits test is something I've begun looking into. > >> > >> [1] > >> Stack Trace Count Percentage > >> boolean java.lang.StringLatin1.regionMatchesCI(byte[], int, byte[], > >> int, int) 1637 100 % > >> boolean java.lang.String.regionMatches(boolean, int, String, int, > >> int) 1637 100 % > >> boolean java.lang.String.equalsIgnoreCase(String) 1637 100 % > >> boolean > >> sun.security.util.AbstractAlgorithmConstraints.checkAlgorithm(List, > >> String, AlgorithmDecomposer) 1631 99.6 % > >> boolean sun.security.util.DisabledAlgorithmConstraints.permits(Set, > >> String, AlgorithmParameters) 1631 99.6 % > >> boolean sun.security.ssl.SSLAlgorithmConstraints.permits(Set, String, > >> AlgorithmParameters) 1631 99.6 % > >> boolean sun.security.ssl.SSLAlgorithmConstraints.permits(Set, String, > >> AlgorithmParameters) 836 51.1 % > >> boolean sun.security.ssl.HandshakeContext.isActivatable(CipherSuite, > >> AlgorithmConstraints, Map) 428 26.1 % > >> List sun.security.ssl.HandshakeContext.getActiveCipherSuites(List, > >> List, AlgorithmConstraints) 418 25.5 % > >> void sun.security.ssl.HandshakeContext.(SSLContextImpl, > >> TransportContext) 418 25.5 % > >> void sun.security.ssl.ClientHandshakeContext.(SSLContextImpl, > >> TransportContext) 418 25.5 % > >> void sun.security.ssl.TransportContext.kickstart() 418 25.5 % > >> void sun.security.ssl.SSLSocketImpl.startHandshake(boolean) 418 > >> 25.5 % > >> void sun.security.ssl.SSLSocketImpl.startHandshake() 418 25.5 % > >> > >> ------------- > >> > >> Marked as reviewed by coffeys (Reviewer). > >> > >> PR: https://git.openjdk.java.net/jdk/pull/8199 From djelinski at openjdk.java.net Fri Apr 22 13:18:21 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 22 Apr 2022 13:18:21 GMT Subject: RFR: 8285431: Assertion in NativeGSSContext constructor In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 06:26:01 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have the simple update reviewed. > > In the NativeGSSContext constructor for imported context, the assert is use on the object field, instead of the input parameters. As in a constructor, `'this'` object does not exist yet, this looks like an obvious issue. The fix is straightforward as well. > > > NativeGSSContext(long pCtxt, GSSLibStub stub) throws GSSException { > - assert(pContext != 0); > + assert(pCtxt != 0); > pContext = pCtxt; > ... LGTM ------------- Marked as reviewed by djelinski (Committer). PR: https://git.openjdk.java.net/jdk/pull/8355 From dfuchs at openjdk.java.net Fri Apr 22 13:30:26 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 22 Apr 2022 13:30:26 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v7] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 15:54:07 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: > > change the calling order in dispose() The dispose/cleanable/Cleaner parts look good to me. Please get another reviewer for the security-libs related and native changes. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8136 From weijun at openjdk.java.net Fri Apr 22 17:21:18 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 22 Apr 2022 17:21:18 GMT Subject: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4 Message-ID: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> Compare encoded instead of decoded digest in RSA signature verification. ------------- Commit messages: - RFC 8017 8.2.2 Step 4 Changes: https://git.openjdk.java.net/jdk/pull/8365/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8365&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285404 Stats: 30 lines in 2 files changed: 3 ins; 26 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8365.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8365/head:pull/8365 PR: https://git.openjdk.java.net/jdk/pull/8365 From mstjohns at comcast.net Fri Apr 22 18:07:30 2022 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 22 Apr 2022 14:07:30 -0400 Subject: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4 In-Reply-To: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> References: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> Message-ID: <9d123862-b3e9-d4c7-cfe7-f33e92195dcf@comcast.net> On 4/22/2022 1:21 PM, Weijun Wang wrote: > Compare encoded instead of decoded digest in RSA signature verification. > > ------------- > > Commit messages: > - RFC 8017 8.2.2 Step 4 > > Changes:https://git.openjdk.java.net/jdk/pull/8365/files > Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=8365&range=00 > Issue:https://bugs.openjdk.java.net/browse/JDK-8285404 > Stats: 30 lines in 2 files changed: 3 ins; 26 del; 1 mod > Patch:https://git.openjdk.java.net/jdk/pull/8365.diff > Fetch: git fetchhttps://git.openjdk.java.net/jdk pull/8365/head:pull/8365 > > PR:https://git.openjdk.java.net/jdk/pull/8365 This is a weird one.? AFAICT the way it was being done is valid and allowed by RFC8017 - I would have closed the bug report as notabug.? Here's the relevant text from? RFC8017: > 4. Compare the encoded message EM and the second encoded message > EM'. If they are the same, output "valid signature"; > otherwise, output "invalid signature". > > Note:*_Another way to implement the signature verification operation is to > apply a "decoding" operation (not specified in this document) to the > encoded message to recover the underlying hash value, and then compare > it to a newly computed hash value._* > This has the advantage that it requires less intermediate storage > (two hash values rather than two encoded messages), but the > disadvantage that it requires additional code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun at openjdk.java.net Fri Apr 22 19:08:23 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 22 Apr 2022 19:08:23 GMT Subject: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4 In-Reply-To: <9d123862-b3e9-d4c7-cfe7-f33e92195dcf@comcast.net> References: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> <9d123862-b3e9-d4c7-cfe7-f33e92195dcf@comcast.net> Message-ID: On Fri, 22 Apr 2022 18:09:33 GMT, Michael StJohns wrote: > This is a weird one.? AFAICT the way it was being done is valid and > allowed by RFC8017 - I would have closed the bug report as notabug Yes, I saw the "Note". It's definitely OK to decode but one has to make sure the input is DER encoded. Unfortunately, the old `RsaUtil::decodeSignature` method has not guaranteed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8365 From ascarpino at openjdk.java.net Fri Apr 22 21:11:44 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 22 Apr 2022 21:11:44 GMT Subject: RFR: 8285389: EdDSA trimming zeros Message-ID: Hi, I'd like a code review of this change to EdDSA. ed25519 and ed448 internally was trimming extra zeros off the end of the signature before processing. This can result in some verify testing failures which are strict about the signature length passed into the operation. thanks Tony ------------- Commit messages: - verify length Changes: https://git.openjdk.java.net/jdk/pull/8372/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8372&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285389 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8372/head:pull/8372 PR: https://git.openjdk.java.net/jdk/pull/8372 From valeriep at openjdk.java.net Fri Apr 22 21:40:25 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 22 Apr 2022 21:40:25 GMT Subject: RFR: 8285431: Assertion in NativeGSSContext constructor In-Reply-To: References: Message-ID: <7Ogjb8RRt4hrgmlyqS2D9vzcUfBLmxJvhccSDcWEhv4=.022bf084-099a-435d-baf1-0b30086ad95f@github.com> On Fri, 22 Apr 2022 06:26:01 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have the simple update reviewed. > > In the NativeGSSContext constructor for imported context, the assert is use on the object field, instead of the input parameters. As in a constructor, `'this'` object does not exist yet, this looks like an obvious issue. The fix is straightforward as well. > > > NativeGSSContext(long pCtxt, GSSLibStub stub) throws GSSException { > - assert(pContext != 0); > + assert(pCtxt != 0); > pContext = pCtxt; > ... Marked as reviewed by valeriep (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8355 From valeriep at openjdk.java.net Fri Apr 22 23:24:25 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 22 Apr 2022 23:24:25 GMT Subject: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4 In-Reply-To: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> References: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> Message-ID: <2tN7r156HHsK5S0meYYjRd4CHy-bo3O9K9zrfYF0IRc=.861a3baf-8fd8-46c1-838d-5e9cff7ee925@github.com> On Fri, 22 Apr 2022 17:10:58 GMT, Weijun Wang wrote: > Compare encoded instead of decoded digest in RSA signature verification. Regardless whether we ended up with decode/encode, we should make sure RSASSA-PSS signature impl is also covered and consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/8365 From mbalao at redhat.com Sat Apr 23 02:58:38 2022 From: mbalao at redhat.com (Martin Balao) Date: Fri, 22 Apr 2022 22:58:38 -0400 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: Hi, On 4/8/22 11:13 AM, Sean Mullan wrote: > In general, I think authorization is best done at a higher layer within > the application and not via low-level SM callouts. Authorize the subject > first and if not acceptable, prevent the operation or API from being > called in the first place. Once the operation is in motion, you have > already taken a greater risk that something might go wrong. I completely agree with this vision, and also agree with the other arguments that both Sean Mullan and Andrew Dinn mentioned before in this thread. In my view, authorization decisions at higher layer generally have better context, are more clear and less riskier. At a lower layer there is more complexity and chances of both subtle combinations or unseen paths that may lead to check bypasses. I lean towards not splitting authorization responsibility through different layers, which might create confusion or even a false sense of security in some cases. To illustrate with a trivial example, if a subject is not supposed to access to some information, it's the application that has enough context to decide and block right away. Letting the attempt go though the call stack down to the network or the file system might be the recipe for missing a channel. I won't enter the untrusted code case -which has been extensively discussed already- but want to briefly mention something about the "trusted code performing risky operations" case. My first point is that vulnerabilities at the JVM level (i.e.: memory safety compromises) are serious enough to potentially bypass a SecurityManager. My second point is that the SecurityManager is really unable to deal with tainted data flowing from low to high integrity domains, and sanitation must be performed by the application or the library anyways because there are infinite ways in which it can be harmful. Even when the data is obtained at a low integrity domain, there will be a flow towards a high integrity domain to perform a legitimate action (i.e.: SQL query, OS command execution, etc). The OS and the DB engine, in this example, have the knowledge, granularity and power to be the next level of enforcement after data sanitation. Again, I wouldn't split this responsibility or pass it to the JDK for the same reasons than before. Best, Martin.- From peter.firmstone at zeus.net.au Sat Apr 23 06:57:10 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 23 Apr 2022 16:57:10 +1000 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: <13355019-81d2-59ae-090b-72a39f446507@zeus.net.au> Hi Martin, I'm curious, you sound like you arrived at this opinion from experience?? Rather than being an upper layer only concern, my opinion is that it requires lower layer intervention / controls, with upper layers providing the decision making context. My reason for asking is, we're basically waiting for finalizers to be disabled, so that we can instrument the java api with access controls to replace SM. In our implementation, we use the SM infrastructure like this: 1. Distributed computing - protection domains and ClassLoaders are used for service identity and isolation at the client. (Simplification because a server can also be a client and vice versa). 2. All client subjects are authenticated over secure connections, threads on the server are run with the client subject, from the client jvm, for access control decisions, eg do I trust the data enough to parse it? ? Callbacks for client listeners (services) are run with the server's subject at the client. 3. We re-implemented java de-serialization, with a public api that uses constructors.?? Unlike perl taint mode, we rely on the authenticated subject's principals, to determine whether to allow permission to deserialize (parse data).? SM allows us to handle tainted data, because we put permission checks into our deserialization implementation, if there's no authenticated subject, or the remote end doesn't have the required principal, then deserialization doesn't proceed at all, because no one vouches for the data, it cannot be trusted.?? Our deserialization implementation provides an atomic input validation api, to validate data (sanitize) from trusted sources, in theory it would allow us to parse untrusted data, but we use authentication to reduce our exposure.? Rather than a bolted on external kind of white listing filtering mechanism, it's a class level implementation concern. 4. Clients dynamically download requested proxy jar files, (streams are not annotated like RMI), prior to download, the client authenticates the service's server, after authentication, the client loads the jar files, and deserializes the proxy object state into a designated ClassLoader (unique to the service identity, services that share jar file URI will not share ClassLoader's and don't resolve to the same class type). After authentication, the service provides URI and advisory permissions and the client may dynamically grant the intersection of those permissions which it has permission to grant and those the service requests. 5. Our services are discoverable over multicast IPv6 (globally and on local networks, usually the two are kept somewhat separate). 6. We have service constraints, these are upper layer controls that lower layers use to ensure connections use strongly encrypted TLS protocols for example, or that a connection can be authenticated with a particular principal.? If a service is obtained from another service, our lower layer communications ensure that the same constraints apply to the second service, the client may apply new constraints after receiving a service proxy. JEP411's successor will remove or change the functionality of Java's access controls and will break all our TLS connections and our ability to have different levels of access control for different services. We can of course just do some kind of no op on later versions of Java with missing api's via reflection, which will also disable encrypted connections, then we can allow services to communicate over trusted networks or VPN's, and allow deserialization and jar file downloads, all without any jvm layer security, but we lose our ability to dynamically discover services globally, they will need to be known in advance and the secure network connections established in advance. We solved all problems with SM mentioned in JEP 411, with the exception of the maintenance cost for OpenJDK.? My understanding is it is company policy around security that makes it expensive to maintain.? We have a policy generation tool (based on principles of least privilege), our policy provider has a less than 1% performance impact.?? We have a PermissionComparator that avoids equals calls on Permission's, we have a URI 3986 implementation, that also normalizes IPv6 addresses, uses bitshift operations for case conversions and is extremely fast, it's used by our ClassLoader and Policy implementations. The only remaining irritations were the structures of the Permissions themselves, eg SocketPermission can't constrain communications to subnet IP address ranges. What Li Gong provided was very well designed, Sun just never finished it, and pretty much let it rot on the vine, few people used it, because of the amount of work required to make it work properly, and the fact that security is a nice to have feature, but budget constraints and delivery deadlines, and now it's subject to defenestration.?? Hand edited policy files?? Sorry, that's not a finished product. The other mistake was the Java trusted computing base became too large, it needed to be restricted to core java language features.?? There's too much trusted code in the JVM. Deserialization and XML (data parsing), never required any permissions, so it couldn't be disabled by assigning the necessary permissions to the principal of the authenticating subject. Serialization and XML shouldn't have been part of the trusted code base.? Even if Java deserialization was insecure, as it was for many years, if it required authentication of the data source prior to deserialization proceeding, well maybe history might have been different.? Also too many classes are Serializable. So by removing SM, in effect we're just making the trusted codebase larger, now it will encompass all third party libraries and their dependencies, while also removing the only available mechanism to determine whether data from an external source can be trusted based on who it was provided by (authenticated). Of course there will be those of us who will re-implement an authorization layer, hopefully we'll learn from Java's mistakes, not repeat them, but make a bunch of new mistakes instead. Regards, Peter. On 23/04/2022 12:58 pm, Martin Balao wrote: > Hi, > > On 4/8/22 11:13 AM, Sean Mullan wrote: >> In general, I think authorization is best done at a higher layer within >> the application and not via low-level SM callouts. Authorize the subject >> first and if not acceptable, prevent the operation or API from being >> called in the first place. Once the operation is in motion, you have >> already taken a greater risk that something might go wrong. > I completely agree with this vision, and also agree with the other > arguments that both Sean Mullan and Andrew Dinn mentioned before in this > thread. In my view, authorization decisions at higher layer generally > have better context, are more clear and less riskier. At a lower layer > there is more complexity and chances of both subtle combinations or > unseen paths that may lead to check bypasses. I lean towards not > splitting authorization responsibility through different layers, which > might create confusion or even a false sense of security in some cases. > To illustrate with a trivial example, if a subject is not supposed to > access to some information, it's the application that has enough context > to decide and block right away. Letting the attempt go though the call > stack down to the network or the file system might be the recipe for > missing a channel. > > I won't enter the untrusted code case -which has been extensively > discussed already- but want to briefly mention something about the > "trusted code performing risky operations" case. My first point is that > vulnerabilities at the JVM level (i.e.: memory safety compromises) are > serious enough to potentially bypass a SecurityManager. My second point > is that the SecurityManager is really unable to deal with tainted data > flowing from low to high integrity domains, and sanitation must be > performed by the application or the library anyways because there are > infinite ways in which it can be harmful. Even when the data is obtained > at a low integrity domain, there will be a flow towards a high integrity > domain to perform a legitimate action (i.e.: SQL query, OS command > execution, etc). The OS and the DB engine, in this example, have the > knowledge, granularity and power to be the next level of enforcement > after data sanitation. Again, I wouldn't split this responsibility or > pass it to the JDK for the same reasons than before. > > Best, > Martin.- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei at openjdk.java.net Sat Apr 23 14:32:25 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 23 Apr 2022 14:32:25 GMT Subject: Integrated: 8285431: Assertion in NativeGSSContext constructor In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 06:26:01 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have the simple update reviewed. > > In the NativeGSSContext constructor for imported context, the assert is use on the object field, instead of the input parameters. As in a constructor, `'this'` object does not exist yet, this looks like an obvious issue. The fix is straightforward as well. > > > NativeGSSContext(long pCtxt, GSSLibStub stub) throws GSSException { > - assert(pContext != 0); > + assert(pCtxt != 0); > pContext = pCtxt; > ... This pull request has now been integrated. Changeset: e9d604a3 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/e9d604a3e5dcd26eed21eda4b5251a07dafcb92a Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8285431: Assertion in NativeGSSContext constructor Reviewed-by: djelinski, valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/8355 From xuelei at openjdk.java.net Sat Apr 23 14:43:28 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 23 Apr 2022 14:43:28 GMT Subject: RFR: 8285389: EdDSA trimming zeros In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 21:04:58 GMT, Anthony Scarpino wrote: > ed25519 and ed448 internally was trimming extra zeros off the end of the signature before processing. This can result in some verify testing failures which are strict about the signature length passed into the operation. > Did you want to correct the verify testing so that it could accept trimmed signature? Or do not trimming the extra zeros of the signature any longer? I did not get the point from the patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/8372 From xuelei at openjdk.java.net Sat Apr 23 15:00:15 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 23 Apr 2022 15:00:15 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeli?ski wrote: > Profiling the TLS handshakes using SSLHandshake benchmark shows that a large portion of time is spent in HandshakeContext initialization, specifically in DisabledAlgorithmConstraints class. > > There are only a few instances of that class, and they are immutable. Caching the results should be a low-risk operation. > > The cache is implemented as a softly reachable ConcurrentHashMap; this way it can be removed from memory after a period of inactivity. Under normal circumstances the cache holds no more than 100 algorithms. src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 105: > 103: private final Set disabledAlgorithms; > 104: private final Constraints algorithmConstraints; > 105: private volatile SoftReference> cacheRef = It looks like a one-clear-for-all mechanism. Once the clearing happens, the full map will be collected. For SoftReferences, it clears them fairly eagerly. Maybe, the performance could be further improved in practice by using soft reference for each map entry (See sun.security.util.Cache code for an example). I will have another look next week. ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From xuelei at openjdk.java.net Sat Apr 23 15:50:22 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 23 Apr 2022 15:50:22 GMT Subject: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4 In-Reply-To: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> References: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> Message-ID: On Fri, 22 Apr 2022 17:10:58 GMT, Weijun Wang wrote: > Compare encoded instead of decoded digest in RSA signature verification. src/java.base/share/classes/sun/security/rsa/RSASignature.java line 220: > 218: byte[] encoded = RSAUtil.encodeSignature(digestOID, digest); > 219: byte[] decrypted = RSACore.rsa(sigBytes, publicKey); > 220: byte[] unpadded = padding.unpad(decrypted); It looks like safer to me that decodeSignature() method is removed and the same method get used for the verification. Maybe, these two lines could be moved ahead (at line 215) so that the processing order is consistent with the RFC 8017 described order, for readability. ------------- PR: https://git.openjdk.java.net/jdk/pull/8365 From xuelei at openjdk.java.net Sun Apr 24 05:19:55 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 24 Apr 2022 05:19:55 GMT Subject: RFR: 8285516: clearPassword should be called in a finally try block 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 ------------- Commit messages: - 8285516: clearPassword should be called in a finally try block Changes: https://git.openjdk.java.net/jdk/pull/8377/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8377&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285516 Stats: 7 lines in 1 file changed: 2 ins; 2 del; 3 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 weijun at openjdk.java.net Sun Apr 24 14:38:24 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 24 Apr 2022 14:38:24 GMT Subject: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4 In-Reply-To: <2tN7r156HHsK5S0meYYjRd4CHy-bo3O9K9zrfYF0IRc=.861a3baf-8fd8-46c1-838d-5e9cff7ee925@github.com> References: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> <2tN7r156HHsK5S0meYYjRd4CHy-bo3O9K9zrfYF0IRc=.861a3baf-8fd8-46c1-838d-5e9cff7ee925@github.com> Message-ID: On Fri, 22 Apr 2022 23:20:43 GMT, Valerie Peng wrote: > Regardless whether we ended up with decode/encode, we should make sure RSASSA-PSS signature impl is also covered and consistent. RSASSA-PSS is not affected. Neither with the PKCS11 RSA signature. ------------- PR: https://git.openjdk.java.net/jdk/pull/8365 From ascarpino at openjdk.java.net Sun Apr 24 15:37:26 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Sun, 24 Apr 2022 15:37:26 GMT Subject: RFR: 8285389: EdDSA trimming zeros In-Reply-To: References: Message-ID: <72DYa3MVpZXn05OrdWoyspfjUcd3Vk8BQTqhPJ4veyo=.021f95d4-41e9-4900-85fd-cb0aa30088d7@github.com> On Sat, 23 Apr 2022 14:39:50 GMT, Xue-Lei Andrew Fan wrote: > Did you want to correct the verify testing so that it could > accept trimmed signature? Or do not trimming the extra zeros > of the signature any longer? I did not get the point from the > patch. The test is correct. Perhaps a clear explanation is if the signature length is greater or less than expected an exception should be thrown for the length being wrong instead of trying to verify the signature. In the particular test, zeros at the end of a too long signature, can get trimmed by BigInteger and the signature checked which should have been rejected before processing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8372 From xuelei at openjdk.java.net Sun Apr 24 15:57:37 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 24 Apr 2022 15:57:37 GMT Subject: RFR: 8285389: EdDSA trimming zeros In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 21:04:58 GMT, Anthony Scarpino wrote: > Hi, > > I'd like a code review of this change to EdDSA. ed25519 and ed448 internally was trimming extra zeros off the end of the signature before processing. This can result in some verify testing failures which are strict about the signature length passed into the operation. > > thanks > > Tony Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8372 From xuelei at openjdk.java.net Sun Apr 24 15:57:38 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 24 Apr 2022 15:57:38 GMT Subject: RFR: 8285389: EdDSA trimming zeros In-Reply-To: <72DYa3MVpZXn05OrdWoyspfjUcd3Vk8BQTqhPJ4veyo=.021f95d4-41e9-4900-85fd-cb0aa30088d7@github.com> References: <72DYa3MVpZXn05OrdWoyspfjUcd3Vk8BQTqhPJ4veyo=.021f95d4-41e9-4900-85fd-cb0aa30088d7@github.com> Message-ID: On Sun, 24 Apr 2022 15:34:23 GMT, Anthony Scarpino wrote: > > Did you want to correct the verify testing so that it could > > accept trimmed signature? Or do not trimming the extra zeros > > of the signature any longer? I did not get the point from the > > patch. > > The test is correct. Perhaps a clear explanation is if the signature length is greater or less than expected an exception should be thrown for the length being wrong instead of trying to verify the signature. I like this explanation more. I have no more comment about the patch. Please add a noreg label in JBS. ------------- PR: https://git.openjdk.java.net/jdk/pull/8372 From openjdk at suche.org Sun Apr 24 21:01:37 2022 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Sun, 24 Apr 2022 23:01:37 +0200 Subject: JDK-8221218 - Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16) In-Reply-To: References: Message-ID: Hi, i like to inform you that this problem is not yet fixed. I Use java 18.0.1 and the problem still popup. OS: Win 11 openjdk 18 2022-03-22 OpenJDK Runtime Environment (build 18+36-2087) OpenJDK 64-Bit Server VM (build 18+36-2087, mixed mode, sharing) Espacialy under larger load. Gru? Thomas java.io.IOException: javax.net.ssl.SSLException: Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16) ??????? at org.eclipse.jetty.util.FutureCallback.block(FutureCallback.java:163) ??????? at org.eclipse.jetty.websocket.common.JettyWebSocketRemoteEndpoint.sendBlocking(JettyWebSocketRemoteEndpoint.java:224) ??????? at org.eclipse.jetty.websocket.common.JettyWebSocketRemoteEndpoint.sendString(JettyWebSocketRemoteEndpoint.java:85) ?? ? ? ... Caused by: javax.net.ssl.SSLException: Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16) ??????? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133) ??????? at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371) ??????? at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314) ??????? at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309) ??????? at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:134) ??????? 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) ??????? at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:701) ??????? at org.eclipse.jetty.websocket.core.internal.WebSocketConnection.fillAndParse(WebSocketConnection.java:470) ??????? ... 16 more ??????? Suppressed: java.io.IOException: Broken pipe ??????????????? at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.flush(SslConnection.java:1118) ??????????????? at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:417) ??????????????? at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:272) ??????????????? at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:418) ??????????????? at org.eclipse.jetty.websocket.core.internal.FrameFlusher.process(FrameFlusher.java:329) ??????????????? at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:232) ??????????????? at org.eclipse.jetty.util.IteratingCallback.succeeded(IteratingCallback.java:350) ??????????????? at org.eclipse.jetty.util.Callback$Nested.succeeded(Callback.java:314) ??????????????? at org.eclipse.jetty.io.WriteFlusher.completeWrite(WriteFlusher.java:389) ??????????????? at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint$IncompleteWriteCallback.succeeded(SslConnection.java:1562) ??????????????? at org.eclipse.jetty.io.WriteFlusher.completeWrite(WriteFlusher.java:389) ??????????????? at org.eclipse.jetty.io.SocketChannelEndPoint$2.run(SocketChannelEndPoint.java:116) ??????????????? ... 8 more From ascarpino at openjdk.java.net Sun Apr 24 21:15:45 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Sun, 24 Apr 2022 21:15:45 GMT Subject: RFR: 8285389: EdDSA trimming zeros In-Reply-To: References: Message-ID: <1h06WA_9B-CEzyG6Tibgdf5UaP4JrmB76a1pRPgGjKk=.2cfd456f-4841-432a-9441-bd3de215ac1f@github.com> On Fri, 22 Apr 2022 21:04:58 GMT, Anthony Scarpino wrote: > Hi, > > I'd like a code review of this change to EdDSA. ed25519 and ed448 internally was trimming extra zeros off the end of the signature before processing. This can result in some verify testing failures which are strict about the signature length passed into the operation. > > thanks > > Tony That issue has nothing to do with this. Please file a webbug or start another conversation on the mailing list regarding that problem ------------- PR: https://git.openjdk.java.net/jdk/pull/8372 From xueleifan at tencent.com Mon Apr 25 05:20:43 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Mon, 25 Apr 2022 05:20:43 +0000 Subject: [Internet]JDK-8221218 - Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16) In-Reply-To: References: Message-ID: <4446C848-22C7-4B0F-B0F2-94D1924D5C57@Tencent.Com> Hi Thomas, Did you have a reproducing code that I would play with? Thanks, Xuelei On Apr 24, 2022, at 2:01 PM, Thomas Lu?nig > wrote: Hi, i like to inform you that this problem is not yet fixed. I Use java 18.0.1 and the problem still popup. OS: Win 11 openjdk 18 2022-03-22 OpenJDK Runtime Environment (build 18+36-2087) OpenJDK 64-Bit Server VM (build 18+36-2087, mixed mode, sharing) Espacialy under larger load. Gru? Thomas java.io.IOException: javax.net.ssl.SSLException: Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16) at org.eclipse.jetty.util.FutureCallback.block(FutureCallback.java:163) at org.eclipse.jetty.websocket.common.JettyWebSocketRemoteEndpoint.sendBlocking(JettyWebSocketRemoteEndpoint.java:224) at org.eclipse.jetty.websocket.common.JettyWebSocketRemoteEndpoint.sendString(JettyWebSocketRemoteEndpoint.java:85) ... Caused by: javax.net.ssl.SSLException: Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:134) 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) at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:701) at org.eclipse.jetty.websocket.core.internal.WebSocketConnection.fillAndParse(WebSocketConnection.java:470) ... 16 more Suppressed: java.io.IOException: Broken pipe at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.flush(SslConnection.java:1118) at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:417) at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:272) at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:418) at org.eclipse.jetty.websocket.core.internal.FrameFlusher.process(FrameFlusher.java:329) at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:232) at org.eclipse.jetty.util.IteratingCallback.succeeded(IteratingCallback.java:350) at org.eclipse.jetty.util.Callback$Nested.succeeded(Callback.java:314) at org.eclipse.jetty.io.WriteFlusher.completeWrite(WriteFlusher.java:389) at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint$IncompleteWriteCallback.succeeded(SslConnection.java:1562) at org.eclipse.jetty.io.WriteFlusher.completeWrite(WriteFlusher.java:389) at org.eclipse.jetty.io.SocketChannelEndPoint$2.run(SocketChannelEndPoint.java:116) ... 8 more -------------- next part -------------- An HTML attachment was scrubbed... URL: From xueleifan at tencent.com Mon Apr 25 05:38:44 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Mon, 25 Apr 2022 05:38:44 +0000 Subject: JDK-8221218 is not yet fixed Message-ID: <133D722F-48FE-4133-9F80-FDB51DBA25B6@Tencent.Com> Hi Thomas, Did you have reproducing code that I could play with? Thanks, Xuelei From xuelei at openjdk.java.net Mon Apr 25 05:39:21 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 25 Apr 2022 05:39:21 GMT Subject: RFR: 8285389: EdDSA trimming zeros In-Reply-To: <4446C848-22C7-4B0F-B0F2-94D1924D5C57@Tencent.Com> References: <4446C848-22C7-4B0F-B0F2-94D1924D5C57@Tencent.Com> Message-ID: <2iUghbQocuT63KlYfXLqv8SCbSLMxz-6XNwPNm4m6eg=.ac2e4802-0fde-487a-bca0-8dd905415e7c@github.com> On Mon, 25 Apr 2022 05:22:33 GMT, xueleifan(XueleiFan) wrote: > Hi Thomas, > > Did you have a reproducing code that I would play with? > > Thanks, > Xuelei [mlbridge](https://github.com/apps/mlbridge) copied the comment, but it is not expected to post here. This PR is not related to JDK-8221218. Please don't reply to this email thread any longer. ------------- PR: https://git.openjdk.java.net/jdk/pull/8372 From xuelei at openjdk.java.net Mon Apr 25 05:51:40 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 25 Apr 2022 05:51:40 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 19:30:11 GMT, Sean Mullan wrote: > However, I think that we need to carefully check the interactions between cleaners and methods that explicitly allow the contents to be cleared so that there are not unexpected results. I think @RogerRiggs explained the behavior of Cleanable.clean(), and @stuart-marks' suggestion was added in the last update. I will file another RFE for the specification clarification. Did I miss something? Did you have more comments? ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From xuelei at openjdk.java.net Mon Apr 25 06:07:00 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 25 Apr 2022 06:07:00 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v8] In-Reply-To: References: Message-ID: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> > 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 with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge and resovle merge conflict - change the calling order in dispose() - More code cleanup - re-org the code per feedback - Update to set context method - add test cases - Merge - Update copyright year - the object reference issue for Cleaner - 8284490: Remove finalizer method in java.security.jgss ------------- Changes: https://git.openjdk.java.net/jdk/pull/8136/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=07 Stats: 219 lines in 9 files changed: 185 ins; 11 del; 23 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 djelinski at openjdk.java.net Mon Apr 25 06:49:26 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 25 Apr 2022 06:49:26 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: On Sat, 23 Apr 2022 14:57:01 GMT, Xue-Lei Andrew Fan wrote: >> Profiling the TLS handshakes using SSLHandshake benchmark shows that a large portion of time is spent in HandshakeContext initialization, specifically in DisabledAlgorithmConstraints class. >> >> There are only a few instances of that class, and they are immutable. Caching the results should be a low-risk operation. >> >> The cache is implemented as a softly reachable ConcurrentHashMap; this way it can be removed from memory after a period of inactivity. Under normal circumstances the cache holds no more than 100 algorithms. > > src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 105: > >> 103: private final Set disabledAlgorithms; >> 104: private final Constraints algorithmConstraints; >> 105: private volatile SoftReference> cacheRef = > > It looks like a one-clear-for-all mechanism. Once the clearing happens, the full map will be collected. For SoftReferences, it clears them fairly eagerly. Maybe, the performance could be further improved in practice by using soft reference for each map entry (See sun.security.util.Cache code for an example). > > I will have another look next week. Right, soft references are likely to be cleaned if they are not used in an entire GC cycle. Using a soft reference for each map entry would not help here; note that all keys and all values in this map are GC roots (keys are enum names, values are `TRUE` and `FALSE`), so in practice they would never be collected. Even if we made the entries collectable, it would not help with the TLS case; SSLEngine & SSLSocket only check the constraints once at the beginning of the handshake, so they would all expire at the same time anyway. What's even worse, we would then have to clear the expired entries from the map. I also considered limiting the size of the map. That's a tricky subject; we would need to get the size limit exactly right. Given that the algorithms are always checked in the same order, if the cache were too small, we would get zero hits. With all the above in mind I decided not to use `sun.security.util.Cache` here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From david.lloyd at redhat.com Mon Apr 25 12:53:44 2022 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 25 Apr 2022 07:53:44 -0500 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: On Fri, Apr 22, 2022 at 10:04 PM Martin Balao wrote: > In my view, authorization decisions at higher layer generally > have better context, are more clear and less riskier. At a lower layer > there is more complexity and chances of both subtle combinations or > unseen paths that may lead to check bypasses. I lean towards not > splitting authorization responsibility through different layers, which > might create confusion or even a false sense of security in some cases. > To illustrate with a trivial example, if a subject is not supposed to > access to some information, it's the application that has enough context > to decide and block right away. Letting the attempt go though the call > stack down to the network or the file system might be the recipe for > missing a channel. The point of the proposal is to allow checks at system-level operations _in addition to_ application-level operations. It sounds like you are saying that adding the extra authorization check is somehow less secure? I'm not sure I agree with that reasoning. > I won't enter the untrusted code case -which has been extensively > discussed already- but want to briefly mention something about the > "trusted code performing risky operations" case. My first point is that > vulnerabilities at the JVM level (i.e.: memory safety compromises) are > serious enough to potentially bypass a SecurityManager. My second point > is that the SecurityManager is really unable to deal with tainted data > flowing from low to high integrity domains, and sanitation must be > performed by the application or the library anyways because there are > infinite ways in which it can be harmful. Even when the data is obtained > at a low integrity domain, there will be a flow towards a high integrity > domain to perform a legitimate action (i.e.: SQL query, OS command > execution, etc). The OS and the DB engine, in this example, have the > knowledge, granularity and power to be the next level of enforcement > after data sanitation. Again, I wouldn't split this responsibility or > pass it to the JDK for the same reasons than before. Nothing in the proposal causes splitting or delegation of responsibilities. It is _only_ about preserving security checkpoints in the JDK, which *add* a layer of checks to what the container might already provide. Nothing is being subtracted, and thus I find it hard to accept that preserving these checks somehow reduces security overall. In absolute terms, using a security manager (even with all of its problems) is *more* secure than not using it on the same code base and deployment. I'm not sure how this can be rationally refuted. The proposal is about retaining this incremental increase in security, while both adjusting the user's expectations via documentation *and* significantly reducing the burden of CVEs and maintenance on the JDK itself (and putting it on to the third party authorization framework), which in my estimation is the *real* stakes here. Nothing in the proposal is intended to solve the issue of tainted data; with or without this proposal, this is an unsolved problem. -- - DML ? he/him From mullan at openjdk.java.net Mon Apr 25 13:21:29 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 25 Apr 2022 13:21:29 GMT Subject: RFR: 8285516: clearPassword should be called in a finally try block In-Reply-To: References: Message-ID: <9geGDl2D9nCFU7iWW60M_B7kIksyEEgkW__dWp6DT14=.7dcb57e0-ae12-4b5c-951e-d7beb94c57cc@github.com> 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 Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8377 From dfuchs at openjdk.java.net Mon Apr 25 13:26:47 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 25 Apr 2022 13:26:47 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 06:46:20 GMT, Daniel Jeli?ski wrote: >> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 105: >> >>> 103: private final Set disabledAlgorithms; >>> 104: private final Constraints algorithmConstraints; >>> 105: private volatile SoftReference> cacheRef = >> >> It looks like a one-clear-for-all mechanism. Once the clearing happens, the full map will be collected. For SoftReferences, it clears them fairly eagerly. Maybe, the performance could be further improved in practice by using soft reference for each map entry (See sun.security.util.Cache code for an example). >> >> I will have another look next week. > > Right, soft references are likely to be cleaned if they are not used in an entire GC cycle. > Using a soft reference for each map entry would not help here; note that all keys and all values in this map are GC roots (keys are enum names, values are `TRUE` and `FALSE`), so in practice they would never be collected. > Even if we made the entries collectable, it would not help with the TLS case; SSLEngine & SSLSocket only check the constraints once at the beginning of the handshake, so they would all expire at the same time anyway. What's even worse, we would then have to clear the expired entries from the map. > > I also considered limiting the size of the map. That's a tricky subject; we would need to get the size limit exactly right. Given that the algorithms are always checked in the same order, if the cache were too small, we would get zero hits. > With all the above in mind I decided not to use `sun.security.util.Cache` here. FWIW: I wouldn't expect `SoftReference` (as opposed to `WeakReference`) to be eagerly cleaned. ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From weijun at openjdk.java.net Mon Apr 25 13:28:24 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 25 Apr 2022 13:28:24 GMT Subject: RFR: 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 Change looks fine. One tiny enhancement to make: The "throw" line seems only 3 spaces indented. ------------- PR: https://git.openjdk.java.net/jdk/pull/8377 From djelinski at openjdk.java.net Mon Apr 25 14:03:28 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 25 Apr 2022 14:03:28 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 13:22:34 GMT, Daniel Fuchs wrote: >> Right, soft references are likely to be cleaned if they are not used in an entire GC cycle. >> Using a soft reference for each map entry would not help here; note that all keys and all values in this map are GC roots (keys are enum names, values are `TRUE` and `FALSE`), so in practice they would never be collected. >> Even if we made the entries collectable, it would not help with the TLS case; SSLEngine & SSLSocket only check the constraints once at the beginning of the handshake, so they would all expire at the same time anyway. What's even worse, we would then have to clear the expired entries from the map. >> >> I also considered limiting the size of the map. That's a tricky subject; we would need to get the size limit exactly right. Given that the algorithms are always checked in the same order, if the cache were too small, we would get zero hits. >> With all the above in mind I decided not to use `sun.security.util.Cache` here. > > FWIW: I wouldn't expect `SoftReference` (as opposed to `WeakReference`) to be eagerly cleaned. `SoftReference`s are guaranteed to survive one GC after use; beyond that their lifespan is determined by `SoftRefLRUPolicyMSPerMB` and the amount of memory available. ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From xuelei at openjdk.java.net Mon Apr 25 14:23:17 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 25 Apr 2022 14:23:17 GMT Subject: RFR: 8285516: clearPassword should be called in a finally try block [v2] In-Reply-To: References: Message-ID: <22ryS4pQVqt8m-mifHIFZ8Xc-lzy6__LHaTt_nc14Qw=.61cd0e95-459c-4748-8fac-90e1e82e4ff2@github.com> > 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 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8377/files - new: https://git.openjdk.java.net/jdk/pull/8377/files/123374d1..99079d30 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8377&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8377&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 Mon Apr 25 14:23:18 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 25 Apr 2022 14:23:18 GMT Subject: RFR: 8285516: clearPassword should be called in a finally try block In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 13:23:53 GMT, Weijun Wang wrote: > Change looks fine. One tiny enhancement to make: The "throw" line seems only 3 spaces indented. Nice catch. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/8377 From xuelei at openjdk.java.net Mon Apr 25 14:36:26 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 25 Apr 2022 14:36:26 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 13:59:44 GMT, Daniel Jeli?ski wrote: >> FWIW: I wouldn't expect `SoftReference` (as opposed to `WeakReference`) to be eagerly cleaned. > > `SoftReference`s are guaranteed to survive one GC after use; beyond that their lifespan is determined by `SoftRefLRUPolicyMSPerMB` and the amount of memory available. > With all the above in mind I decided not to use `sun.security.util.Cache` here I was not meant to use Cache and timeout for this update. SoftReference and this patch should work good in larger memory boxes. Performance improvement sometimes is a trade-off game between memory and CPU. Did you have a chance to check the performance in the limited memory circumstance? like '-mx64M". ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From xuelei at openjdk.java.net Mon Apr 25 14:40:26 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 25 Apr 2022 14:40:26 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v7] In-Reply-To: References: Message-ID: <7JUGt0tvd4FMDqVkWrdT9C3jHklvut0vOEkxp3ktbdQ=.ce221d56-a43c-4160-bc84-b72e213d0c30@github.com> On Fri, 22 Apr 2022 13:27:12 GMT, Daniel Fuchs wrote: > Please get another reviewer for the security-libs related and native changes. @wangweij Did you have cycle and have another look at the update? ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From anthony.scarpino at oracle.com Mon Apr 25 15:22:03 2022 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 25 Apr 2022 08:22:03 -0700 Subject: Java Cryptographic Extension Survey In-Reply-To: References: Message-ID: <4643f2ce-9d3f-9f4e-543c-fa7eba67d9c5@oracle.com> Reminder this survey ends Friday. Please fill it out if you have not. Thanks On 4/12/22 8:10 AM, Anthony Scarpino wrote: > Hello, > > Java Cryptographic Extension (JCE) has been in Java SE for a long time > and has made incremental changes over the years.? Looking forward, we > would like to know more about how projects are using JCE and what > changes, features, and API enhancements would be helpful for your projects. > > Below is a survey that we hope you can spend 5 minutes to fill out.? If > you have written or maintain code that uses the JCE API, then we would > appreciate if you would complete this survey: > > https://www.questionpro.com/t/AUzP7ZrFWv > > The survey will be open through April 29. > > Thank you, > Anthony Scarpino > OpenJDK Security Group > https://openjdk.java.net/groups/security/ From ascarpino at openjdk.java.net Mon Apr 25 15:35:33 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 25 Apr 2022 15:35:33 GMT Subject: Integrated: 8285389: EdDSA trimming zeros In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 21:04:58 GMT, Anthony Scarpino wrote: > Hi, > > I'd like a code review of this change to EdDSA. ed25519 and ed448 internally was trimming extra zeros off the end of the signature before processing. This can result in some verify testing failures which are strict about the signature length passed into the operation. > > thanks > > Tony This pull request has now been integrated. Changeset: 414918d9 Author: Anthony Scarpino URL: https://git.openjdk.java.net/jdk/commit/414918d9113b447c9ae774cdfd087f1636b8e5a0 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8285389: EdDSA trimming zeros Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/8372 From ascarpino at openjdk.java.net Mon Apr 25 16:07:27 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 25 Apr 2022 16:07:27 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeli?ski wrote: > Profiling the TLS handshakes using SSLHandshake benchmark shows that a large portion of time is spent in HandshakeContext initialization, specifically in DisabledAlgorithmConstraints class. > > There are only a few instances of that class, and they are immutable. Caching the results should be a low-risk operation. > > The cache is implemented as a softly reachable ConcurrentHashMap; this way it can be removed from memory after a period of inactivity. Under normal circumstances the cache holds no more than 100 algorithms. I'm good with this idea. It's not caching the whole list like I struggled with, but it's a good solution for the algorithm name based constraints. It also shows that more caching probably would help further. I'll let Xuelei finish his review comments ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From mullan at openjdk.java.net Mon Apr 25 16:54:40 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 25 Apr 2022 16:54:40 GMT Subject: RFR: 8285389: EdDSA trimming zeros In-Reply-To: References: <72DYa3MVpZXn05OrdWoyspfjUcd3Vk8BQTqhPJ4veyo=.021f95d4-41e9-4900-85fd-cb0aa30088d7@github.com> Message-ID: <9RJ2qLyH5y0PPaILXMVNSiEshd4R7xm2d8YHpVtV1lc=.871f895d-d3c6-47d2-a0bf-2b0e53bf6481@github.com> On Sun, 24 Apr 2022 15:54:15 GMT, Xue-Lei Andrew Fan wrote: > I like this explanation more. I have no more comment about the patch. Please add a noreg label in JBS. `noreg-sqe` seems appropriate. ------------- PR: https://git.openjdk.java.net/jdk/pull/8372 From coffeys at openjdk.java.net Mon Apr 25 16:59:28 2022 From: coffeys at openjdk.java.net (Sean Coffey) Date: Mon, 25 Apr 2022 16:59:28 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeli?ski wrote: > Profiling the TLS handshakes using SSLHandshake benchmark shows that a large portion of time is spent in HandshakeContext initialization, specifically in DisabledAlgorithmConstraints class. > > There are only a few instances of that class, and they are immutable. Caching the results should be a low-risk operation. > > The cache is implemented as a softly reachable ConcurrentHashMap; this way it can be removed from memory after a period of inactivity. Under normal circumstances the cache holds no more than 100 algorithms. Another nice performance boost in this area. Looks good to me. ------------- Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8349 From djelinski at openjdk.java.net Mon Apr 25 17:26:26 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 25 Apr 2022 17:26:26 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 14:33:13 GMT, Xue-Lei Andrew Fan wrote: >> `SoftReference`s are guaranteed to survive one GC after use; beyond that their lifespan is determined by `SoftRefLRUPolicyMSPerMB` and the amount of memory available. > >> With all the above in mind I decided not to use `sun.security.util.Cache` here > > I was not meant to use Cache and timeout for this update. > > SoftReference and this patch should work good in larger memory boxes. Performance improvement sometimes is a trade-off game between memory and CPU. Did you have a chance to check the performance in the limited memory circumstance? like '-mx64M". I run a few tests: `-Xmx16m`, with this patch, still better than the original version: Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake true TLSv1.2 thrpt 5 4477.444 ? 375.975 ops/s SSLHandshake.doHandshake true TLS thrpt 5 681.471 ? 72.531 ops/s SSLHandshake.doHandshake false TLSv1.2 thrpt 5 335.366 ? 89.056 ops/s SSLHandshake.doHandshake false TLS thrpt 5 308.711 ? 90.134 ops/s `-Xmx8m`, before patch: Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake true TLSv1.2 thrpt 5 153.760 ? 12.025 ops/s SSLHandshake.doHandshake true TLS thrpt 5 70.700 ? 7.506 ops/s SSLHandshake.doHandshake false TLSv1.2 thrpt 5 67.459 ? 4.325 ops/s SSLHandshake.doHandshake false TLS thrpt 5 64.695 ? 1.647 ops/s after: Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake true TLSv1.2 thrpt 5 557.324 ? 50.269 ops/s SSLHandshake.doHandshake true TLS thrpt 5 155.258 ? 13.866 ops/s SSLHandshake.doHandshake false TLSv1.2 thrpt 5 181.755 ? 29.319 ops/s SSLHandshake.doHandshake false TLS thrpt 5 120.627 ? 25.832 ops/s Much slower, but still faster with the patch. With `-Xmx4m` the test failed with OOM. ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From mullan at openjdk.java.net Mon Apr 25 18:17:29 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 25 Apr 2022 18:17:29 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 23:31:37 GMT, Valerie Peng wrote: >>> > Hmm, I tried the suggested approach in (1), the result looks very lengthy. Actually, the Cipher.init(..) methods already has a few paragraphs describing the behavior for parameter generation, perhaps we should not repeat stating the "If this cipher was initialized" vs "was not initialized" since lengthy description may confuse users and have higher risks of inconsistency. What do you think? >>> >>> That's a good point, the `init` methods do go into a lot of detail about that. >>> >>> > As for (2), currently only RSASSA-PSS signature impl uses parameters. When specified using PSSParameterSpec, it's possible that some of the parameters are not set, so it's possible for providers to use provider-specific default values for PSS case. So, yes, Signature class may have to updated in the same way to cover this particular scenario. >>> >>> Ok, I think we should try to make the spec consistent across `Cipher` and `Signature` once we settle on the right wording. I think it would be better to do it as part of this issue, but I would be ok doing it later as long as it is also fixed in 19. >> >> I can do the Signature update through https://bugs.openjdk.java.net/browse/JDK-8253176 which I have targeted to fix in 19 also. > > As for the 2nd sentence, it boils down whether we requires provider to generate default parameters and return it when parameter is required. Existing javadoc states that null is returned when parameter is not required. Given Cipher covers many algorithms, if a provider does not want to generate a default parameter when parameter is required, it can't return null when getParameters() is called. > I can do the Signature update through https://bugs.openjdk.java.net/browse/JDK-8253176 which I have targeted to fix in 19 also. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From duke at openjdk.java.net Mon Apr 25 18:43:46 2022 From: duke at openjdk.java.net (Mark Powers) Date: Mon, 25 Apr 2022 18:43:46 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net Message-ID: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> https://bugs.openjdk.java.net/browse/JDK-8285504 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/net ------------- Commit messages: - second iteration - Merge - Merge - first iteration Changes: https://git.openjdk.java.net/jdk/pull/8384/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8384&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285504 Stats: 128 lines in 20 files changed: 1 ins; 21 del; 106 mod Patch: https://git.openjdk.java.net/jdk/pull/8384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8384/head:pull/8384 PR: https://git.openjdk.java.net/jdk/pull/8384 From alanb at openjdk.java.net Mon Apr 25 18:51:29 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 25 Apr 2022 18:51:29 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net In-Reply-To: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: On Mon, 25 Apr 2022 17:40:13 GMT, Mark Powers wrote: > https://bugs.openjdk.java.net/browse/JDK-8285504 > > 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/net src/java.base/share/classes/javax/net/ssl/SSLSessionContext.java line 110: > 108: */ > 109: void setSessionTimeout(int seconds) > 110: throws IllegalArgumentException; IllegalArgumentException is a runtime exception, it's unusual to have "throws IllegalArgumentException". It would not impact compatibility to drop it. The important thing is that the javadoc has the `@throws` describing when it is thrown. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From duke at openjdk.java.net Mon Apr 25 19:20:27 2022 From: duke at openjdk.java.net (Mark Powers) Date: Mon, 25 Apr 2022 19:20:27 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: On Mon, 25 Apr 2022 18:48:31 GMT, Alan Bateman wrote: >> https://bugs.openjdk.java.net/browse/JDK-8285504 >> >> 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/net > > src/java.base/share/classes/javax/net/ssl/SSLSessionContext.java line 110: > >> 108: */ >> 109: void setSessionTimeout(int seconds) >> 110: throws IllegalArgumentException; > > IllegalArgumentException is a runtime exception, it's unusual to have "throws IllegalArgumentException". It would not impact compatibility to drop it. The important thing is that the javadoc has the `@throws` describing when it is thrown. I'll drop it then. Thanks for noticing this. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From frainone at redhat.com Mon Apr 25 14:45:30 2022 From: frainone at redhat.com (Flavia Rainone) Date: Mon, 25 Apr 2022 11:45:30 -0300 Subject: Reproducer for JDK-8221218 Message-ID: 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). 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RHCC_CareerMnthEmail_Signature.jpg Type: image/jpeg Size: 49278 bytes Desc: not available URL: From starksm64 at gmail.com Mon Apr 25 18:25:45 2022 From: starksm64 at gmail.com (Scott Stark) Date: Mon, 25 Apr 2022 11:25:45 -0700 Subject: Timeframe for JEP-411 completely removing SecurityManager APIs Message-ID: 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. 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. Thanks, Scott Stark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mullan at openjdk.java.net Mon Apr 25 20:45:49 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 25 Apr 2022 20:45:49 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v2] In-Reply-To: References: Message-ID: <8yhg_sr0jA_wfoQ0JR6fytAhLgZpYor6kktNKRoWgIE=.a341d707-d26a-42df-b7f7-dd54da5fe0f5@github.com> On Mon, 25 Apr 2022 05:48:04 GMT, Xue-Lei Andrew Fan wrote: > > However, I think that we need to carefully check the interactions between cleaners and methods that explicitly allow the contents to be cleared so that there are not unexpected results. > > I think @RogerRiggs explained the behavior of Cleanable.clean(), and @stuart-marks' suggestion was added in the last update. I will file another RFE for the specification clarification. Did I miss something? Did you have more comments? I am ok with the fix now but I had a few comments on the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From mullan at openjdk.java.net Mon Apr 25 20:45:59 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 25 Apr 2022 20:45:59 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v4] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 06:55:22 GMT, Xue-Lei Andrew Fan wrote: >> Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. >> >> The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Code clean up per feedback test/jdk/javax/security/auth/callback/PasswordCleanup.java line 58: > 56: } > 57: > 58: private static void clearWithMethod() throws Exception { This looks like the exact same test as `clearAtCollection`. test/jdk/javax/security/auth/callback/PasswordCleanup.java line 74: > 72: } > 73: > 74: private static void checkClearing() throws Exception { How is this test testing that the password is cleared? test/jdk/javax/security/auth/callback/PasswordCleanup.java line 83: > 81: // Check if the object has been collected. > 82: if (weakHashMap.size() > 0) { > 83: throw new RuntimeException("GSSName object is not released"); Did you mean to say "PasswordCallback object is not released"? ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From svkamath at openjdk.java.net Mon Apr 25 22:47:56 2022 From: svkamath at openjdk.java.net (Smita Kamath) Date: Mon, 25 Apr 2022 22:47:56 GMT Subject: Integrated: 8283022: com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java failing with -Xcomp after 8273297 In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 05:06:26 GMT, Smita Kamath wrote: > When input length provided to the intrinsic is 8192, only 7680 bytes are processed as the intrinsic operates on multiples of 768 bytes. > In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method, > dst.put(bout, 0, PARALLEL_LEN) statement caused the ciphertext mismatch as PARALLEL_LEN was set to 8192. > Since the intrinsic only processed 7680 bytes, the rest output was incorrect. This pull request has now been integrated. Changeset: 3416bfa2 Author: Smita Kamath Committer: Anthony Scarpino URL: https://git.openjdk.java.net/jdk/commit/3416bfa2560e240b5e602f10e98e8a06c96852df Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8283022: com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java failing with -Xcomp after 8273297 Reviewed-by: ascarpino ------------- PR: https://git.openjdk.java.net/jdk/pull/8280 From openjdk at suche.org Mon Apr 25 22:52:34 2022 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Tue, 26 Apr 2022 00:52:34 +0200 Subject: [Internet]JDK-8221218 - Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16) In-Reply-To: <4446C848-22C7-4B0F-B0F2-94D1924D5C57@Tencent.Com> References: <4446C848-22C7-4B0F-B0F2-94D1924D5C57@Tencent.Com> Message-ID: <4882b356-5bfa-b4ae-285e-c197feb7c557@suche.org> Hi, i does not have an reproducing right now. But after an deeper look i found out that it is not or not only load dependend. I was able to "reproduce" the error in te full system repeating with the same data over the websocket. Next i will do an TCP-Dump Gru? Thomas Am 25.04.2022 um 07:20 schrieb xueleifan(XueleiFan): > > Hi Thomas, > > Did you have a reproducing code that I would play with? > > Thanks, > > Xuelei > > >> On Apr 24, 2022, at 2:01 PM, Thomas Lu?nig wrote: >> >> Hi, >> >> i like to inform you that this problem is not yet fixed. I Use java >> 18.0.1 and the problem still popup. >> OS: Win 11 >> openjdk 18 2022-03-22 >> OpenJDK Runtime Environment (build 18+36-2087) >> OpenJDK 64-Bit Server VM (build 18+36-2087, mixed mode, sharing) >> >> Espacialy under larger load. >> >> Gru? Thomas >> >> java.io.IOException: javax.net.ssl.SSLException: Insufficient buffer >> remaining for AEAD cipher fragment (2). Needs to be more than tag >> size (16) >> >> ??????? at >> org.eclipse.jetty.util.FutureCallback.block(FutureCallback.java:163) >> ??????? at >> org.eclipse.jetty.websocket.common.JettyWebSocketRemoteEndpoint.sendBlocking(JettyWebSocketRemoteEndpoint.java:224) >> ??????? at >> org.eclipse.jetty.websocket.common.JettyWebSocketRemoteEndpoint.sendString(JettyWebSocketRemoteEndpoint.java:85) >> ?? ? ? ... >> Caused by: javax.net.ssl.SSLException: Insufficient buffer remaining >> for AEAD cipher fragment (2). Needs to be more than tag size (16) >> ??????? at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133) >> ??????? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371) >> ??????? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314) >> ??????? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309) >> ??????? at >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:134) >> ??????? 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) >> ??????? at >> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:701) >> ??????? at >> org.eclipse.jetty.websocket.core.internal.WebSocketConnection.fillAndParse(WebSocketConnection.java:470) >> ??????? ... 16 more >> ??????? Suppressed: java.io.IOException: Broken pipe >> ??????????????? at >> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.flush(SslConnection.java:1118) >> ??????????????? at >> org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:417) >> ??????????????? at >> org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:272) >> ??????????????? at >> org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:418) >> ??????????????? at >> org.eclipse.jetty.websocket.core.internal.FrameFlusher.process(FrameFlusher.java:329) >> ??????????????? at >> org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:232) >> ??????????????? at >> org.eclipse.jetty.util.IteratingCallback.succeeded(IteratingCallback.java:350) >> ??????????????? at >> org.eclipse.jetty.util.Callback$Nested.succeeded(Callback.java:314) >> ??????????????? at >> org.eclipse.jetty.io.WriteFlusher.completeWrite(WriteFlusher.java:389) >> ??????????????? at >> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint$IncompleteWriteCallback.succeeded(SslConnection.java:1562) >> ??????????????? at >> org.eclipse.jetty.io.WriteFlusher.completeWrite(WriteFlusher.java:389) >> ??????????????? at >> org.eclipse.jetty.io.SocketChannelEndPoint$2.run(SocketChannelEndPoint.java:116) >> ??????????????? ... 8 more > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.java.net Tue Apr 26 00:27:43 2022 From: duke at openjdk.java.net (Mark Powers) Date: Tue, 26 Apr 2022 00:27:43 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8285504 > > 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/net Mark Powers has updated the pull request incrementally with one additional commit since the last revision: Alan Bateman comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8384/files - new: https://git.openjdk.java.net/jdk/pull/8384/files/5ac7f1ec..d964c05a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8384&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8384&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8384/head:pull/8384 PR: https://git.openjdk.java.net/jdk/pull/8384 From weijun at openjdk.java.net Tue Apr 26 02:08:01 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 02:08:01 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v8] In-Reply-To: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> References: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> Message-ID: On Mon, 25 Apr 2022 06:07:00 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 with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge and resovle merge conflict > - change the calling order in dispose() > - More code cleanup > - re-org the code per feedback > - Update to set context method > - add test cases > - Merge > - Update copyright year > - the object reference issue for Cleaner > - 8284490: Remove finalizer method in java.security.jgss The latest source change is OK, but I'll look more into it tomorrow. The test needs some enhancement. Or I can consider contributing one. Sorry I'll be a little busy this week. src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java line 54: > 52: private final Cleaner.Cleanable cleanable; > 53: > 54: long pName = 0; // Pointer to the gss_name_t structure Can this be final? test/jdk/sun/security/jgss/GssContextCleanup.java line 61: > 59: if (whm.size() > 0) { > 60: throw new RuntimeException("GSSContext object is not released"); > 61: } I think it's necessary to check the debug message to make sure "[GSSLibStub_deleteContext]" is seen. This test should have already succeeded before your latest update to `NativeGSSContext`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From weijun at openjdk.java.net Tue Apr 26 02:08:02 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 02:08:02 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v8] In-Reply-To: References: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> Message-ID: On Tue, 26 Apr 2022 02:01:10 GMT, Weijun Wang wrote: >> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: >> >> - Merge and resovle merge conflict >> - change the calling order in dispose() >> - More code cleanup >> - re-org the code per feedback >> - Update to set context method >> - add test cases >> - Merge >> - Update copyright year >> - the object reference issue for Cleaner >> - 8284490: Remove finalizer method in java.security.jgss > > test/jdk/sun/security/jgss/GssContextCleanup.java line 61: > >> 59: if (whm.size() > 0) { >> 60: throw new RuntimeException("GSSContext object is not released"); >> 61: } > > I think it's necessary to check the debug message to make sure "[GSSLibStub_deleteContext]" is seen. This test should have already succeeded before your latest update to `NativeGSSContext`. The same for `GSSName`. Where is a test for `GSSCredential`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From valeriep at openjdk.java.net Tue Apr 26 03:05:24 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 26 Apr 2022 03:05:24 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException 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 ------------- Commit messages: - 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException Changes: https://git.openjdk.java.net/jdk/pull/8396/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253176 Stats: 28 lines in 2 files changed: 4 ins; 3 del; 21 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 duke at openjdk.java.net Tue Apr 26 03:19:55 2022 From: duke at openjdk.java.net (duke) Date: Tue, 26 Apr 2022 03:19:55 GMT Subject: Withdrawn: 8273042: TLS Certificate Compression In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 20:15:24 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > Please review the implementation of RFC 8879, TLS Certificate Compression, in JDK. The TLS Certificate Compression standard is an essential part for QUIC connections and performance improvement for TLS connections. More details, please refer to the [JEP](https://bugs.openjdk.java.net/browse/JDK-8281710) proposal. > > The JEP was submitted, and it may take time for the final approval. But let me know you ideas and concerns about the proposal and implementation. > > JEP: https://bugs.openjdk.java.net/browse/JDK-8281710 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7599 From xuelei at openjdk.java.net Tue Apr 26 04:14:02 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 26 Apr 2022 04:14:02 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeli?ski wrote: > Profiling the TLS handshakes using SSLHandshake benchmark shows that a large portion of time is spent in HandshakeContext initialization, specifically in DisabledAlgorithmConstraints class. > > There are only a few instances of that class, and they are immutable. Caching the results should be a low-risk operation. > > The cache is implemented as a softly reachable ConcurrentHashMap; this way it can be removed from memory after a period of inactivity. Under normal circumstances the cache holds no more than 100 algorithms. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From xuelei at openjdk.java.net Tue Apr 26 04:14:04 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 26 Apr 2022 04:14:04 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 16:04:22 GMT, Anthony Scarpino wrote: > It also shows that more caching probably would help further. +1. ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From xuelei at openjdk.java.net Tue Apr 26 04:14:06 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 26 Apr 2022 04:14:06 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: <-1pvsme0lQ162Xl4VyEPtSSvEeg7InlCJKPajGCGKOE=.3ff79ef3-8d1c-429a-aa6e-b05fe37ce21b@github.com> On Mon, 25 Apr 2022 17:22:57 GMT, Daniel Jeli?ski wrote: >>> With all the above in mind I decided not to use `sun.security.util.Cache` here >> >> I was not meant to use Cache and timeout for this update. >> >> SoftReference and this patch should work good in larger memory boxes. Performance improvement sometimes is a trade-off game between memory and CPU. Did you have a chance to check the performance in the limited memory circumstance? like '-mx64M". > > I run a few tests: > `-Xmx16m`, with this patch, still better than the original version: > > Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units > SSLHandshake.doHandshake true TLSv1.2 thrpt 5 4477.444 ? 375.975 ops/s > SSLHandshake.doHandshake true TLS thrpt 5 681.471 ? 72.531 ops/s > SSLHandshake.doHandshake false TLSv1.2 thrpt 5 335.366 ? 89.056 ops/s > SSLHandshake.doHandshake false TLS thrpt 5 308.711 ? 90.134 ops/s > > > `-Xmx8m`, before patch: > > Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units > SSLHandshake.doHandshake true TLSv1.2 thrpt 5 153.760 ? 12.025 ops/s > SSLHandshake.doHandshake true TLS thrpt 5 70.700 ? 7.506 ops/s > SSLHandshake.doHandshake false TLSv1.2 thrpt 5 67.459 ? 4.325 ops/s > SSLHandshake.doHandshake false TLS thrpt 5 64.695 ? 1.647 ops/s > > after: > > Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units > SSLHandshake.doHandshake true TLSv1.2 thrpt 5 557.324 ? 50.269 ops/s > SSLHandshake.doHandshake true TLS thrpt 5 155.258 ? 13.866 ops/s > SSLHandshake.doHandshake false TLSv1.2 thrpt 5 181.755 ? 29.319 ops/s > SSLHandshake.doHandshake false TLS thrpt 5 120.627 ? 25.832 ops/s > > Much slower, but still faster with the patch. > With `-Xmx4m` the test failed with OOM. Thanks for the additional testing. The improvement is impressive. ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From xuelei at openjdk.java.net Tue Apr 26 04:25:04 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 26 Apr 2022 04:25:04 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v4] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 20:37:38 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Code clean up per feedback > > test/jdk/javax/security/auth/callback/PasswordCleanup.java line 83: > >> 81: // Check if the object has been collected. >> 82: if (weakHashMap.size() > 0) { >> 83: throw new RuntimeException("GSSName object is not released"); > > Did you mean to say "PasswordCallback object is not released"? Ooops, bad copy and past of mine. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From xuelei at openjdk.java.net Tue Apr 26 04:33:56 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 26 Apr 2022 04:33:56 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v4] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 20:41:47 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> Code clean up per feedback > > test/jdk/javax/security/auth/callback/PasswordCleanup.java line 58: > >> 56: } >> 57: >> 58: private static void clearWithMethod() throws Exception { > > This looks like the exact same test as `clearAtCollection`. Nice catch. The passwordCallback.clearPassword() should not be called in clearAtCollection. > test/jdk/javax/security/auth/callback/PasswordCleanup.java line 74: > >> 72: } >> 73: >> 74: private static void checkClearing() throws Exception { > > How is this test testing that the password is cleared? The test case is used to check that the Cleaner used is not bind to 'this' object, and the cleaner during finalization could work. Unfortunately, as the cleaner behavior is not visible, I don't find a way to automated test that the password is really cleared during finalization. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From jpai at openjdk.java.net Tue Apr 26 04:40:56 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 26 Apr 2022 04:40:56 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: <8qWiM1OaGDQtVmw-lJLeSwfwfQkhdevDWYY-UgnQOQ0=.251b86c7-fe92-4137-b1ce-34cbcd7ad448@github.com> On Tue, 26 Apr 2022 00:27:43 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8285504 >> >> 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/net > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > Alan Bateman comments src/java.base/share/classes/javax/net/ssl/KeyStoreBuilderParameters.java line 71: > 69: } > 70: > 71: this.parameters = List.copyOf(parameters); Hello Mark, this would actually be a change in behaviour. The `List.copyOf` says: > The given Collection must not be null and it must not contain any null elements. The current implementation of the public constructor on the public `KeyStoreBuilderParameters` mandates no such requirement. So if there's some code which currently passes a list with a null element in it, then this change will now end up throwing a `NullPointerException` as per the contract of `List.copyOf`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From xuelei at openjdk.java.net Tue Apr 26 04:51:48 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 26 Apr 2022 04:51:48 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v5] In-Reply-To: References: Message-ID: > Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. > > The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: correct test typo and test clearPassword() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8272/files - new: https://git.openjdk.java.net/jdk/pull/8272/files/01542bb6..aaedee46 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=03-04 Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8272/head:pull/8272 PR: https://git.openjdk.java.net/jdk/pull/8272 From xuelei at openjdk.java.net Tue Apr 26 05:08:55 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 26 Apr 2022 05:08:55 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v8] In-Reply-To: References: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> Message-ID: On Tue, 26 Apr 2022 01:53:43 GMT, Weijun Wang wrote: >> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: >> >> - Merge and resovle merge conflict >> - change the calling order in dispose() >> - More code cleanup >> - re-org the code per feedback >> - Update to set context method >> - add test cases >> - Merge >> - Update copyright year >> - the object reference issue for Cleaner >> - 8284490: Remove finalizer method in java.security.jgss > > src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java line 54: > >> 52: private final Cleaner.Cleanable cleanable; >> 53: >> 54: long pName = 0; // Pointer to the gss_name_t structure > > Can this be final? Did you mean pName? The dispose() method will reset it to zero. 'pName" is used a lot in native implementation. It may be doable to make it final, but it may be more complicated than I could expect. I would like to leave it as it is in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From xuelei at openjdk.java.net Tue Apr 26 05:08:55 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 26 Apr 2022 05:08:55 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v8] In-Reply-To: References: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> Message-ID: <3kt-EEVAliBRkpvzGg55S8oI4WgCjOod9f1CBwapmyM=.80fd62bc-0b32-4f73-b23c-74367403e479@github.com> On Tue, 26 Apr 2022 02:02:09 GMT, Weijun Wang wrote: > Where is a test for `GSSCredential`? I did not find a way to create a GSSCredential object successfully, exception thrown. Is there an example I can refer to? ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From Alan.Bateman at oracle.com Tue Apr 26 05:26:23 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Apr 2022 06:26:23 +0100 Subject: Reproducer for JDK-8221218 In-Reply-To: References: Message-ID: <83e8358d-13fb-a2f5-5d70-7223da2ecbdc@oracle.com> On 25/04/2022 15:45, 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). > JDK-8221218 says it has been fixed in JDK 17. Have you tested with JDK 17 or JDK 18 ? -Alan From djelinski at openjdk.java.net Tue Apr 26 05:59:03 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 26 Apr 2022 05:59:03 GMT Subject: RFR: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeli?ski wrote: > Profiling the TLS handshakes using SSLHandshake benchmark shows that a large portion of time is spent in HandshakeContext initialization, specifically in DisabledAlgorithmConstraints class. > > There are only a few instances of that class, and they are immutable. Caching the results should be a low-risk operation. > > The cache is implemented as a softly reachable ConcurrentHashMap; this way it can be removed from memory after a period of inactivity. Under normal circumstances the cache holds no more than 100 algorithms. Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From djelinski at openjdk.java.net Tue Apr 26 05:59:04 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 26 Apr 2022 05:59:04 GMT Subject: Integrated: 8285398: Cache the results of constraint checks In-Reply-To: References: Message-ID: <5SiSYp8rf006Y1UGRyLpnjbG3gI2pB-qAZKcAqL3XIE=.1b86f84e-4fea-4988-85ce-f824274a8e0c@github.com> On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeli?ski wrote: > Profiling the TLS handshakes using SSLHandshake benchmark shows that a large portion of time is spent in HandshakeContext initialization, specifically in DisabledAlgorithmConstraints class. > > There are only a few instances of that class, and they are immutable. Caching the results should be a low-risk operation. > > The cache is implemented as a softly reachable ConcurrentHashMap; this way it can be removed from memory after a period of inactivity. Under normal circumstances the cache holds no more than 100 algorithms. This pull request has now been integrated. Changeset: 00e9c96d Author: Daniel Jeli?ski URL: https://git.openjdk.java.net/jdk/commit/00e9c96d51bec53d4ae8a07c9c98af2c62f3d290 Stats: 26 lines in 1 file changed: 23 ins; 1 del; 2 mod 8285398: Cache the results of constraint checks Reviewed-by: coffeys, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/8349 From peter.firmstone at zeus.net.au Tue Apr 26 07:35:45 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 26 Apr 2022 17:35:45 +1000 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: <8c8110fc-47d4-2665-dacd-fe37ddaefa25@zeus.net.au> On 25/04/2022 10:53 pm, David Lloyd wrote: > Nothing in the proposal is intended to solve the issue of tainted > data; with or without this proposal, this is an unsolved problem. Well, actually, the statement "this is an unsolved problem" is not entirely true, I think we came very close to solving it. In any case, security is pretty tight: Perl taint was simple, you parse text data using pattern recognition, the results of pattern matching was considered untainted. Until the data was parsed, it was considered tainted, so it couldn't be used for ODBC etc until it was parsed, it was marked as tainted, so you could delay parsing it if you wanted and Perl would keep track of tainted data. In JGDMS (evolved from Jini and Apache River) we perform input validation with atomic de-serialization, although we don't mark data as tainted, as it is expected to be validated prior to object instantiation. Every Object in the stream must implement @AtomicSerial, or be a primitive, String or Enum, no circular object graphs are allowed. It is expected that strings will be parsed, or pattern matched, during input validation, unlike Perl taint, it's not something that can be enforced, if Java provided a way to mark Strings as tainted, then we could ensure that any Strings received created directly from stream data are not involved in privileged actions. We could maintain a collection of tainted strings, but then some of them may be identical to strings which aren't tainted, so it wouldn't work as expected, the JVM would need to avoid caching tainted strings. The problem is, to make the String tainted, it would require a permanently unprivileged domain and this isn't easy to do for a final class such as String. https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io/AtomicSerial.java However, in our implementation, de-serialization requires permission, these de-serialization permissions should be granted to ProtectionDomain's based on their (CodeSource || ClassLoader) && Principal's. So the CodeSource should be audited and the Principal trusted (Subject authenticated) before these permissions are granted. The Principal is the source of the data. https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io/DeSerializationPermission.java On the server side, the server usually provides the code that will parse data it receives from the client, however on the client side, the server also provides the code to parse proxy data at the client, so we are heavily dependent on authentication, authorization, encryption privacy and encryption message digests. Alone, neither the CodeSource nor the Principal, have permission to deserialize, only when both together have permission, only then is de-serialization permitted. Even though the data source Principal is trusted (and authenticated), the Code must still be audited and trusted to parse the data provided. A CodeSource may receive permission by its CodeSigner identity, or if the server's authenticated Subject is trusted enough to provide signer certificates, or a message digest of the CodeSource, in which case the client grants permission dynamically. A single parameter object class provides access to serial data, for all classes in the object inheritance hierarchy. Every @AtomimcSerial object must check its invariant's, child classes are able to create super class instances, prior to creating an instance of themselves, to allow super classes to check their invariant's. Any object that fails an invariant check, throws an exception prior to calling a super class constructor. Serial parameters have separate namespaces for each class, so a child class cannot see the serial parameters of a superclass, instead it must create an instance of the superclass (which checks it's own invariants) first and then call it's methods and check it's state, the superclass object is not an instance of the child class. Once the child class is satisfied that the superclass instance has been validated, it checks the invariants in its own serial data, prior to creating an object instance of itself (although it is free to check this first, if it is more efficient to do so, eg fail fast). Collection instances are not serialized, not using Java serialization, but replaced in streams using read only collections backed by arrays. Collection types share the same serial form, such that if Set, List and Map would be equal if compared as objects also have equal serial form. It is the responsibility of @AtoimcSerial classes to check invariant's and make defensive copies of Collections. A utility class, Valid, assists with input validation on collections. https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io/Valid.java Limits are placed on array lengths and stream data, this is a countdown, which must be periodically reset, or an exception will be thrown and control returned to the caller when the limit is reached. Invocation constraints also provide a way for callers to communicate their intent to underlying communication layers. https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/constraint/InvocationConstraints.java Note that there are extensible layers: 1. Invocation layer 2. Object Identification layer. 3. Serialization layer. 4. Transport layer. https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/package.html These security precautions will no longer provide protection after SM is degraded, hence the need to re-implement an authorization layer. I had hoped that OpenJDK might assist us by providing hooks we can use to control network access, creation of ClassLoader's or access to properties, or key stores, but it looks as though we have to instrument the Java api's and we are on our own. It also appears due to finalizers, that there will be versions of OpenJDK which we cannot support, eg if SM has been disabled and finalizers are still present, we cannot support this JDK version. Personally I'd like to see SM fully supported until finalizers can be disabled. -- Regards, Peter Firmstone From Alan.Bateman at oracle.com Tue Apr 26 08:28:57 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Apr 2022 09:28:57 +0100 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: On 25/04/2022 13:53, David Lloyd wrote: > Nothing in the proposal causes splitting or delegation of > responsibilities. It is _only_ about preserving security checkpoints > in the JDK, which *add* a layer of checks to what the container might > already provide. Nothing is being subtracted, and thus I find it hard > to accept that preserving these checks somehow reduces security > overall. "preserving security checkpoints in the JDK" suggests just leaving the calls do AccessController.doPrivileged and SecurityManager.checkPermission in place. That amounts to putting a tax on every feature, every JEP, and all ongoing maintenance of the platform. If there is refactoring or a change that forgets to insert a checkPermission somewhere then we have a security issue and everything that goes along with that. No thanks! I think Martin is right that hooking authorization libraries into low level libraries isn't the right way to do this. Aside from the complexity methods I would add that threads pools or any hand-off between threads will typically break when the context is not carried. One other point about authorization libraries wanting to hook into low level code is that it's a minefield of potential issues with recursive initialization, stack overflows and some really hard to diagnose issues. JDK-8155659 [1] is one report that comes to mind. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8155659 From peter.firmstone at zeus.net.au Tue Apr 26 09:06:16 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 26 Apr 2022 19:06:16 +1000 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: On 26/04/2022 6:28 pm, Alan Bateman wrote: > On 25/04/2022 13:53, David Lloyd wrote: >> Nothing in the proposal causes splitting or delegation of >> responsibilities. It is _only_ about preserving security checkpoints >> in the JDK, which *add* a layer of checks to what the container might >> already provide. Nothing is being subtracted, and thus I find it hard >> to accept that preserving these checks somehow reduces security >> overall. > > "preserving security checkpoints in the JDK" suggests just leaving the > calls do AccessController.doPrivileged and > SecurityManager.checkPermission in place. That amounts to putting a > tax on every feature, every JEP, and all ongoing maintenance of the > platform. If there is refactoring or a change that forgets to insert a > checkPermission somewhere then we have a security issue and everything > that goes along with that. No thanks! What about ensuring that all network access occurs through a single location that we can instrument? It would be nice to leave AccessController calls in place, oh well, such is life. > > I think Martin is right that hooking authorization libraries into low > level libraries isn't the right way to do this. Aside from the > complexity methods I would add that threads pools or any hand-off > between threads will typically break when the context is not carried. Yes, we went to a lot of trouble to ensure context is preserved through executors and other thread calls, for executors, it was simple enough to decorate a Callable.?? However this is successful, in that our RemoteEvent's and Event listeners use the preserved AccessControlContext to establish and authenticate secure connections. > > One other point about authorization libraries wanting to hook into low > level code is that it's a minefield of potential issues with recursive > initialization, stack overflows and some really hard to diagnose > issues. JDK-8155659 [1] is one report that comes to mind. Yes, I have also come across this problem, I use a thread local to detect the recursion, in try finally blocks. https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java#L347 One must also be aware of class loading, to ensure necessary classes are loaded at the right time. The following is an example of a complex issue, which was solved using immutability, by avoiding shared state between threads and avoiding blocking where possible.?? Java's PermissionCollection implementations are a minefield of synchronization, so we thread confined PermissionCollection.?? We avoided caching permission check results as Java's policy cache is a huge performance killer.? There is also the issue of DNS calls made in URL and URLClassLoader, so we fixed those issues too.? Instead of relying on DNS we use RFC3986 and RFC5952 normalization.?? The performance difference as you might imagine by removing blocking network calls and replacing it with immutable normalized forms was huge. https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/net/jini/security/policy/DynamicPolicyProvider.java#L265 https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java > > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-8155659 It's just such a shame that we achieved so much and OpenJDK is pulling the rug from underneath us. Regards, Peter. From ecki at zusammenkunft.net Tue Apr 26 09:11:49 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 26 Apr 2022 09:11:49 +0000 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: Hello, I dont agree with the statement that this can be solved on higher level. (Unless higher level means move away from existing architectures which is perfectly fine for some workloads but not for all) IMHO Infrastructure to enforce on lower level is needed either for traditional sandboxing (which suddenly java is no longer a fan of - and at the same time wasm and native sandboxing makes a lot of ground with this feature). Some instrumentation might be possible, but for traditional APIs with files, sockets and processes it looks much more convenient to have callbacks/permission checks like before (or a bit nicer with typed APIs like proposed here). One point however pro new security concepts: if we had better integration in OS and Hypervisor, it might really be better to use different methods. Like having suid on thread context, allowing security context, dropping OS permissions, chroot/jail, modifying and inheriting access tokens, sharing memory with virtual machine or even deploying in sgx.. but not much of that (besides containers) is available of that as of now with Java. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Alan Bateman Gesendet: Tuesday, April 26, 2022 10:28:57 AM An: David Lloyd Cc: OpenJDK Security Betreff: Re: A possible JEP to replace SecurityManager after JEP 411 On 25/04/2022 13:53, David Lloyd wrote: > Nothing in the proposal causes splitting or delegation of > responsibilities. It is _only_ about preserving security checkpoints > in the JDK, which *add* a layer of checks to what the container might > already provide. Nothing is being subtracted, and thus I find it hard > to accept that preserving these checks somehow reduces security > overall. "preserving security checkpoints in the JDK" suggests just leaving the calls do AccessController.doPrivileged and SecurityManager.checkPermission in place. That amounts to putting a tax on every feature, every JEP, and all ongoing maintenance of the platform. If there is refactoring or a change that forgets to insert a checkPermission somewhere then we have a security issue and everything that goes along with that. No thanks! I think Martin is right that hooking authorization libraries into low level libraries isn't the right way to do this. Aside from the complexity methods I would add that threads pools or any hand-off between threads will typically break when the context is not carried. One other point about authorization libraries wanting to hook into low level code is that it's a minefield of potential issues with recursive initialization, stack overflows and some really hard to diagnose issues. JDK-8155659 [1] is one report that comes to mind. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8155659 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Apr 26 10:10:14 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Apr 2022 11:10:14 +0100 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: On 26/04/2022 10:06, Peter Firmstone wrote: > : > > What about ensuring that all network access occurs through a single > location that we can instrument? Network, file, and process launch are potentially interesting but instrumenting them to run arbitrary code may be problematic (for the same reasons that custom security managers can be problematic). -Alan From ecki at zusammenkunft.net Tue Apr 26 10:11:53 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 26 Apr 2022 10:11:53 +0000 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: Just to add to the discussion some more, as I understand it the new (Graal based?) multi language environment running inside a Oracle database is exactly what others want to do here: multimtenant untrusted code execution inside a bigger application. There are a number of complications here, first of all it?s not the OpenJDK launcher/runtime and secondly it gets into native and also GPL territory, so that it?s unlike many but Oracle will be able to do such a solution. Under this light removing the SM hooks makes the situation even more problematic. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Peter Firmstone Gesendet: Tuesday, April 26, 2022 11:06:16 AM An: security-dev at openjdk.java.net Betreff: Re: A possible JEP to replace SecurityManager after JEP 411 On 26/04/2022 6:28 pm, Alan Bateman wrote: > On 25/04/2022 13:53, David Lloyd wrote: >> Nothing in the proposal causes splitting or delegation of >> responsibilities. It is _only_ about preserving security checkpoints >> in the JDK, which *add* a layer of checks to what the container might >> already provide. Nothing is being subtracted, and thus I find it hard >> to accept that preserving these checks somehow reduces security >> overall. > > "preserving security checkpoints in the JDK" suggests just leaving the > calls do AccessController.doPrivileged and > SecurityManager.checkPermission in place. That amounts to putting a > tax on every feature, every JEP, and all ongoing maintenance of the > platform. If there is refactoring or a change that forgets to insert a > checkPermission somewhere then we have a security issue and everything > that goes along with that. No thanks! What about ensuring that all network access occurs through a single location that we can instrument? It would be nice to leave AccessController calls in place, oh well, such is life. > > I think Martin is right that hooking authorization libraries into low > level libraries isn't the right way to do this. Aside from the > complexity methods I would add that threads pools or any hand-off > between threads will typically break when the context is not carried. Yes, we went to a lot of trouble to ensure context is preserved through executors and other thread calls, for executors, it was simple enough to decorate a Callable. However this is successful, in that our RemoteEvent's and Event listeners use the preserved AccessControlContext to establish and authenticate secure connections. > > One other point about authorization libraries wanting to hook into low > level code is that it's a minefield of potential issues with recursive > initialization, stack overflows and some really hard to diagnose > issues. JDK-8155659 [1] is one report that comes to mind. Yes, I have also come across this problem, I use a thread local to detect the recursion, in try finally blocks. https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java#L347 One must also be aware of class loading, to ensure necessary classes are loaded at the right time. The following is an example of a complex issue, which was solved using immutability, by avoiding shared state between threads and avoiding blocking where possible. Java's PermissionCollection implementations are a minefield of synchronization, so we thread confined PermissionCollection. We avoided caching permission check results as Java's policy cache is a huge performance killer. There is also the issue of DNS calls made in URL and URLClassLoader, so we fixed those issues too. Instead of relying on DNS we use RFC3986 and RFC5952 normalization. The performance difference as you might imagine by removing blocking network calls and replacing it with immutable normalized forms was huge. https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/net/jini/security/policy/DynamicPolicyProvider.java#L265 https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java > > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-8155659 It's just such a shame that we achieved so much and OpenJDK is pulling the rug from underneath us. Regards, Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Tue Apr 26 10:37:57 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 26 Apr 2022 20:37:57 +1000 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: <2156bf26-2b09-92a9-9766-7c4ac38203c5@zeus.net.au> On 26/04/2022 8:10 pm, Alan Bateman wrote: > On 26/04/2022 10:06, Peter Firmstone wrote: >> : >> >> What about ensuring that all network access occurs through a single >> location that we can instrument? > > Network, file, and process launch are potentially interesting but > instrumenting them to run arbitrary code may be problematic (for the > same reasons that custom security managers can be problematic). > > -Alan A service provider? Don't specify that's it's for security, just for intercepting network, file and process launching. "can" is the key word here.??? The problems are manageable when you know about them.? If a developer isn't aware, it could create nasty surprises.? So can't we document the gotchas? Regards, Peter. From weijun at openjdk.java.net Tue Apr 26 11:57:52 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 11:57:52 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v8] In-Reply-To: <3kt-EEVAliBRkpvzGg55S8oI4WgCjOod9f1CBwapmyM=.80fd62bc-0b32-4f73-b23c-74367403e479@github.com> References: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> <3kt-EEVAliBRkpvzGg55S8oI4WgCjOod9f1CBwapmyM=.80fd62bc-0b32-4f73-b23c-74367403e479@github.com> Message-ID: On Tue, 26 Apr 2022 05:05:30 GMT, Xue-Lei Andrew Fan wrote: >> The same for `GSSName`. Where is a test for `GSSCredential`? > >> Where is a test for `GSSCredential`? > > I did not find a way to create a GSSCredential object successfully, exception thrown. Is there an example I can refer to? I think there needs a real Kerberos environment to create a real credential. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From weijun at openjdk.java.net Tue Apr 26 11:57:52 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 11:57:52 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v8] In-Reply-To: References: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> Message-ID: On Tue, 26 Apr 2022 05:02:51 GMT, Xue-Lei Andrew Fan wrote: >> src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java line 54: >> >>> 52: private final Cleaner.Cleanable cleanable; >>> 53: >>> 54: long pName = 0; // Pointer to the gss_name_t structure >> >> Can this be final? > > Did you mean pName? The dispose() method will reset it to zero. 'pName" is used a lot in native implementation. It may be doable to make it final, but it may be more complicated than I could expect. I would like to leave it as it is in this PR. IMO, there's no need to reset it to zero in `dispose()`. As for the usage in native implementation, if there is really a case that it gets updated, then the cleanable you registered at the beginning will be useless. Isn't that a real problem? ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From david.lloyd at redhat.com Tue Apr 26 13:07:51 2022 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 26 Apr 2022 08:07:51 -0500 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: On Tue, Apr 26, 2022 at 4:47 AM Alan Bateman wrote: > > On 25/04/2022 13:53, David Lloyd wrote: > > Nothing in the proposal causes splitting or delegation of > > responsibilities. It is _only_ about preserving security checkpoints > > in the JDK, which *add* a layer of checks to what the container might > > already provide. Nothing is being subtracted, and thus I find it hard > > to accept that preserving these checks somehow reduces security > > overall. > > "preserving security checkpoints in the JDK" suggests just leaving the > calls do AccessController.doPrivileged and > SecurityManager.checkPermission in place. The proposal is clear that the JDK 'doPrivileged' calls would not be necessary, and it is not necessary to exactly use `checkPermission` depending on the approach taken. This might or might not counter your argument, but as I said before, even if the proposal is rejected, it should be rejected based on a fair and accurate evaluation of what is proposed. > That amounts to putting a tax > on every feature, every JEP, and all ongoing maintenance of the > platform. If there is refactoring or a change that forgets to insert a > checkPermission somewhere then we have a security issue and everything > that goes along with that. Sure, if you continue to think of SecurityManager as a sandbox, then every case where it is not a perfect sandbox can be a major security issue. In real terms though, was SecurityManager ever _actually_ effective as a sandbox? It is certainly the case that few (if any) of us who do systems and security programming in application servers and containers at Red Hat have ever considered it so. Thus, the proposal as given tries to reflect this reality by treating the SecurityManager as exactly two things: firstly, a central point for any application or library to be able to statically perform an authorization check without needing to rely on any library other than the JDK itself; and secondly, a mechanism by which certain operations performed by the JDK can be authorized by the user. The lack of an authorization check would therefore be less impactful when considered from this perspective. Maybe a security issue, yes, but not a sandbox escape because there _is_ no sandbox. It's not a part of the contract anymore. In fact, part of the contract could even be an _explicit admonition_ that missing checks in the JDK would be considered bugs but not security issues. Even that would be better than removing the whole thing; if doing X has an unacceptable cost, let's stop doing X instead of getting rid of Y. > I think Martin is right that hooking authorization libraries into low > level libraries isn't the right way to do this. Aside from the > complexity methods I would add that threads pools or any hand-off > between threads will typically break when the context is not carried. Propagation of security context is not a problem that needs a solution in the JDK and is not a part of the proposal. It's generally already a solved problem within containers, where this feature is intended to be used, including cases where threads are created or tasks are dispatched to thread pools, fork/join, etc. Thus the proposal establishes that this is 100% the responsibility of the security manager implementation. > One other point about authorization libraries wanting to hook into low > level code is that it's a minefield of potential issues with recursive > initialization, stack overflows and some really hard to diagnose issues. > JDK-8155659 [1] is one report that comes to mind. It is up to the implementation to deal with recursive calls into the security manager today (and we already do so to our own satisfaction), and I don't see any reason why that wouldn't continue to be the case. In my opinion, this would not be an issue that the JDK has to be concerned about (other than maybe as a documentation issue). -- - DML ? he/him From neugens at redhat.com Tue Apr 26 13:16:56 2022 From: neugens at redhat.com (Mario Torre) Date: Tue, 26 Apr 2022 15:16:56 +0200 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: On Mon, Apr 25, 2022 at 2:55 PM David Lloyd wrote: > Nothing in the proposal causes splitting or delegation of > responsibilities. It is _only_ about preserving security checkpoints > in the JDK, which *add* a layer of checks to what the container might > already provide. Nothing is being subtracted, and thus I find it hard > to accept that preserving these checks somehow reduces security > overall. In absolute terms, using a security manager (even with all of > its problems) is *more* secure than not using it on the same code base > and deployment. I'm not sure how this can be rationally refuted. The > proposal is about retaining this incremental increase in security, > while both adjusting the user's expectations via documentation *and* > significantly reducing the burden of CVEs and maintenance on the JDK > itself (and putting it on to the third party authorization framework), > which in my estimation is the *real* stakes here. I think there's a difference between "perceived" security and "actual" one. The SM in today's post Spectre, Meltdown and the likes world is "perceived" security, which may lead to a relaxation on the security of other layers because at least "we have additional security checkpoints in the JDK". Cheers, Mario -- Mario Torre Manager, Software Engineering, core OpenJDK Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From david.lloyd at redhat.com Tue Apr 26 13:35:09 2022 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 26 Apr 2022 08:35:09 -0500 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: On Tue, Apr 26, 2022 at 8:17 AM Mario Torre wrote: > I think there's a difference between "perceived" security and "actual" one. > > The SM in today's post Spectre, Meltdown and the likes world is > "perceived" security, which may lead to a relaxation on the security > of other layers because at least "we have additional security > checkpoints in the JDK". I agree. Perceived security is a problem that has plagued SecurityManager since its inception, due in no small part to the noble (if misguided) apparent initial intention that it was to be an _actual_ sandbox. Fast forward through a quarter of a century of bitter education, and still, nothing in the documentation really refutes this or sets up a realistic expectation for what level of protection is _actually_ provided. Even the deprecation notice doesn't give any indication that SecurityManager is anything less than a perfect sandbox, referring instead to JEP 411. A necessary part of the proposal is a documentation overhaul that defines the exact contract of the API as well as a real-world discussion about what level of protection is (and is not) actually provided. If the user comes away from reading the documentation with the idea that turning on this switch means that they don't have to worry about security anymore, then that is a big problem. And from personal experience, I believe this is the case today, at least to a degree. -- - DML ? he/him From xuelei at openjdk.java.net Tue Apr 26 13:42:04 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 26 Apr 2022 13:42:04 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v8] In-Reply-To: References: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> Message-ID: On Tue, 26 Apr 2022 11:54:36 GMT, Weijun Wang wrote: >> Did you mean pName? The dispose() method will reset it to zero. 'pName" is used a lot in native implementation. It may be doable to make it final, but it may be more complicated than I could expect. I would like to leave it as it is in this PR. > > IMO, there's no need to reset it to zero in `dispose()`. As for the usage in native implementation, if there is really a case that it gets updated, then the cleanable you registered at the beginning will be useless. Isn't that a real problem? The native code does not update pName. As dispose is public, if pName is set to zero, I'm not sure if there is compatibility issues if more methods get called after dispose(). If you are confident with that, I could set pName to final and update the dispose() impl. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From xueleifan at tencent.com Tue Apr 26 14:16:42 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Tue, 26 Apr 2022 14:16:42 +0000 Subject: [Internet]Reproducer for JDK-8221218 In-Reply-To: References: Message-ID: <20A6E533-D210-40B4-8A0E-9CACC8767966@Tencent.Com> 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 openjdk at suche.org Tue Apr 26 14:36:06 2022 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Tue, 26 Apr 2022 16:36:06 +0200 Subject: [Internet]JDK-8221218 - Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16) In-Reply-To: <4882b356-5bfa-b4ae-285e-c197feb7c557@suche.org> References: <4446C848-22C7-4B0F-B0F2-94D1924D5C57@Tencent.Com> <4882b356-5bfa-b4ae-285e-c197feb7c557@suche.org> Message-ID: 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 Tue Apr 26 14:49:28 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Tue, 26 Apr 2022 14:49:28 +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: Is it the same problem as discussed in this thread: https://mail.openjdk.java.net/pipermail/security-dev/2022-April/030129.html 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun at openjdk.java.net Tue Apr 26 15:02:54 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 15:02:54 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException In-Reply-To: References: Message-ID: <77iS1t15rXz0DnqsXKuRifJPbAYGLlJOTnqRt1cdKcE=.11167daf-c2ba-48d3-b14a-26a0914c554a@github.com> 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 src/java.base/share/classes/java/security/Signature.java line 1015: > 1013: * parameters were not supplied and the underlying signature implementation > 1014: * can generate the parameter values, it will be returned. Otherwise, > 1015: * {@code null} is returned. If we cannot guarantee anything but just want to clarify. how about just say "The returned parameters is a combination of user-provided values, default values, and/or random values used by the underlying signature implementation. It can also be {@code null} if there's none." src/java.base/share/classes/java/security/Signature.java line 1510: > 1508: try { > 1509: return cipher.doFinal(); > 1510: } catch (IllegalBlockSizeException | BadPaddingException e) { Is this a revert of a recent fix from someone else? ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From mullan at openjdk.java.net Tue Apr 26 15:22:53 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 26 Apr 2022 15:22:53 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v4] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 04:27:37 GMT, Xue-Lei Andrew Fan wrote: >> test/jdk/javax/security/auth/callback/PasswordCleanup.java line 74: >> >>> 72: } >>> 73: >>> 74: private static void checkClearing() throws Exception { >> >> How is this test testing that the password is cleared? > > The test case is used to check that the Cleaner used is not bind to 'this' object, and the cleaner during finalization could work. Unfortunately, as the cleaner behavior is not visible, I don't find a way to automated test that the password is really cleared during finalization. Ok, then I would suggest changing the name of the test as it is misleading. I suggest creating a directory named "PasswordCallback" and then adding a test named perhaps "CheckCleanerNotBoundToThis" or something like that. I would change the name of the `checkClearing` method as you are not checking if passwords are cleared. Also update the @summary to describe what it is actually testing. Use code comments if you need to explain it further. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From weijun at openjdk.java.net Tue Apr 26 15:47:03 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 15:47:03 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v8] In-Reply-To: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> References: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> Message-ID: On Mon, 25 Apr 2022 06:07:00 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 with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge and resovle merge conflict > - change the calling order in dispose() > - More code cleanup > - re-org the code per feedback > - Update to set context method > - add test cases > - Merge > - Update copyright year > - the object reference issue for Cleaner > - 8284490: Remove finalizer method in java.security.jgss Can you try out this test? diff --git a/test/jdk/sun/security/krb5/auto/Cleaners.java b/test/jdk/sun/security/krb5/auto/Cleaners.java new file mode 100644 index 00000000000..0eac7c21ee6 --- /dev/null +++ b/test/jdk/sun/security/krb5/auto/Cleaners.java @@ -0,0 +1,180 @@ +/* + * 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. + */ + +/* + * @test + * @bug 8284490 + * @summary Remove finalizer method in java.security.jgss + * @library /test/lib + * @compile -XDignore.symbol.file Cleaners.java + * @run main/othervm Cleaners launcher + */ + +import java.nio.charset.StandardCharsets; +import java.nio.file.Files; +import java.nio.file.Paths; +import java.nio.file.attribute.PosixFilePermission; +import java.util.Arrays; +import java.util.Set; + +import jdk.test.lib.Asserts; +import jdk.test.lib.Platform; +import jdk.test.lib.process.Proc; +import org.ietf.jgss.Oid; +import sun.security.krb5.Config; + +public class Cleaners { + + private static final String CONF = "krb5.conf"; + private static final String KTAB_S = "server.ktab"; + private static final String KTAB_B = "backend.ktab"; + + private static final String HOST = "localhost"; + private static final String SERVER = "server/" + HOST; + private static final String BACKEND = "backend/" + HOST; + private static final String USER = "user"; + private static final char[] PASS = "password".toCharArray(); + private static final String REALM = "REALM"; + + private static final byte[] MSG = "12345678".repeat(128) + .getBytes(StandardCharsets.UTF_8); + + public static void main(String[] args) throws Exception { + + Oid oid = new Oid("1.2.840.113554.1.2.2"); + byte[] token, msg; + + switch (args[0]) { + case "launcher" -> { + KDC kdc = KDC.create(REALM, HOST, 0, true); + kdc.addPrincipal(USER, PASS); + kdc.addPrincipalRandKey("krbtgt/" + REALM); + kdc.addPrincipalRandKey(SERVER); + kdc.addPrincipalRandKey(BACKEND); + + // Native lib might do some name lookup + KDC.saveConfig(CONF, kdc, + "dns_lookup_kdc = no", + "ticket_lifetime = 1h", + "dns_lookup_realm = no", + "dns_canonicalize_hostname = false", + "forwardable = true"); + System.setProperty("java.security.krb5.conf", CONF); + Config.refresh(); + + // Create kaytab and ccache files for native clients + kdc.writeKtab(KTAB_S, false, SERVER); + kdc.writeKtab(KTAB_B, false, BACKEND); + kdc.kinit(USER, "ccache"); + if (!Platform.isWindows()) { + Files.setPosixFilePermissions(Paths.get("ccache"), + Set.of(PosixFilePermission.OWNER_READ, + PosixFilePermission.OWNER_WRITE)); + } + Proc pc = proc("client") + .env("KRB5CCNAME", "FILE:ccache") + .env("KRB5_KTNAME", "none") // Do not try system ktab if ccache fails + .start(); + Proc ps = proc("server") + .env("KRB5_KTNAME", KTAB_S) + .start(); + Proc pb = proc("backend") + .env("KRB5_KTNAME", KTAB_B) + .start(); + + // Client and server + ps.println(pc.readData()); // AP-REQ + pc.println(ps.readData()); // AP-REP, mutual auth + ps.println(pc.readData()); // wrap msg + ps.println(pc.readData()); // mic msg + + + // Server and backend + pb.println(ps.readData()); // AP-REQ + ps.println(pb.readData()); // wrap msg + ps.println(pb.readData()); // mic msg + ensureCleanersCalled(pc); + ensureCleanersCalled(ps); + ensureCleanersCalled(pb); + } + case "client" -> { + Context c = Context.fromThinAir(); + c.startAsClient(SERVER, oid); + c.x().requestCredDeleg(true); + c.x().requestMutualAuth(true); + Proc.binOut(c.take(new byte[0])); // AP-REQ + c.take(Proc.binIn()); // AP-REP + Proc.binOut(c.wrap(MSG, true)); + Proc.binOut(c.getMic(MSG)); + } + case "server" -> { + Context s = Context.fromThinAir(); + s.startAsServer(oid); + token = Proc.binIn(); // AP-REQ + Proc.binOut(s.take(token)); // AP-REP + msg = s.unwrap(Proc.binIn(), true); + Asserts.assertTrue(Arrays.equals(msg, MSG)); + s.verifyMic(Proc.binIn(), msg); + Context s2 = s.delegated(); + s2.startAsClient(BACKEND, oid); + s2.x().requestMutualAuth(false); + Proc.binOut(s2.take(new byte[0])); // AP-REQ + msg = s2.unwrap(Proc.binIn(), true); + Asserts.assertTrue(Arrays.equals(msg, MSG)); + s2.verifyMic(Proc.binIn(), msg); + } + case "backend" -> { + Context b = Context.fromThinAir(); + b.startAsServer(oid); + token = b.take(Proc.binIn()); // AP-REQ + Asserts.assertTrue(token == null); + Proc.binOut(b.wrap(MSG, true)); + Proc.binOut(b.getMic(MSG)); + } + } + System.out.println("Prepare for GC"); + for (int i = 0; i < 10; i++) { + System.gc(); + Thread.sleep(100); + } + } + + private static void ensureCleanersCalled(Proc p) throws Exception { + p.output() + .shouldHaveExitValue(0) + .stdoutShouldMatch("Prepare for GC(.|\\n)*GSSLibStub_deleteContext") + .stdoutShouldMatch("Prepare for GC(.|\\n)*GSSLibStub_releaseName") + .stdoutShouldMatch("Prepare for GC(.|\\n)*GSSLibStub_releaseCred"); + } + + private static Proc proc(String type) throws Exception { + return Proc.create("Cleaners") + .args(type) + .debug(type) + .env("KRB5_CONFIG", CONF) + .env("KRB5_TRACE", Platform.isWindows() ? "CON" : "/dev/stderr") + .prop("sun.security.jgss.native", "true") + .prop("javax.security.auth.useSubjectCredsOnly", "false") + .prop("sun.security.nativegss.debug", "true"); + } +} diff --git a/test/lib/jdk/test/lib/process/Proc.java b/test/lib/jdk/test/lib/process/Proc.java index 3541f34144f..574e5761d03 100644 --- a/test/lib/jdk/test/lib/process/Proc.java +++ b/test/lib/jdk/test/lib/process/Proc.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, 2021, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 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 @@ -123,6 +123,7 @@ public class Proc { private String debug; // debug flag, controller will show data // transfer between procs. If debug is set, // it MUST be different between Procs. + private final StringBuilder stdout = new StringBuilder(); final private static String PREFIX = "PROCISFUN:"; @@ -358,6 +359,9 @@ public class Proc { // Reads a line from stdout of proc public String readLine() throws IOException { String s = br.readLine(); + if (s != null) { + stdout.append(s).append('\n'); + } if (debug != null) { System.out.println("PROC: " + debug + " readline: " + (s == null ? "" : s)); @@ -402,6 +406,16 @@ public class Proc { } return p.waitFor(); } + + // Returns an OutputAnalyzer + public OutputAnalyzer output() throws Exception { + int exitCode = waitFor(); + Path stderr = Path.of(getId("stderr")); + return new OutputAnalyzer(stdout.toString(), + Files.exists(stderr) ? Files.readString(stderr) : "", + exitCode); + } + // Wait for process end with expected exit code public void waitFor(int expected) throws Exception { if (p.waitFor() != expected) { ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From weijun at openjdk.java.net Tue Apr 26 15:47:05 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 15:47:05 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v8] In-Reply-To: References: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> Message-ID: On Tue, 26 Apr 2022 13:38:04 GMT, Xue-Lei Andrew Fan wrote: >> IMO, there's no need to reset it to zero in `dispose()`. As for the usage in native implementation, if there is really a case that it gets updated, then the cleanable you registered at the beginning will be useless. Isn't that a real problem? > > The native code does not update pName. As dispose is public, if pName is set to zero, I'm not sure if there is compatibility issues if more methods get called after dispose(). If you are confident with that, I could set pName to final and update the dispose() impl. I don't think anything is guaranteed after a name is disposed. I see no problem in doing this. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From xuelei at openjdk.java.net Tue Apr 26 15:48:51 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 26 Apr 2022 15:48:51 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v4] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 15:19:30 GMT, Sean Mullan wrote: >> The test case is used to check that the Cleaner used is not bind to 'this' object, and the cleaner during finalization could work. Unfortunately, as the cleaner behavior is not visible, I don't find a way to automated test that the password is really cleared during finalization. > > Ok, then I would suggest changing the name of the test as it is misleading. I suggest creating a directory named "PasswordCallback" and then adding a test named perhaps "CheckCleanerNotBoundToThis" or something like that. I would change the name of the `checkClearing` method as you are not checking if passwords are cleared. Also update the @summary to describe what it is actually testing. Use code comments if you need to explain it further. The test has two case now. One is used to check the PasswordCallback object collection at finalization. The other one is check the password clearing for clearPassword() method. Is it better to split into two test files so that the class name could be better fit the purpose? ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From weijun at openjdk.java.net Tue Apr 26 16:02:41 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 16:02:41 GMT Subject: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4 [v2] In-Reply-To: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> References: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> Message-ID: <2h-0IRs5_2jdoK1zyCozkuTaRf9AOFzL8vmppUGWMoI=.f382c6a8-914a-4810-bc6b-69af28b84dc1@github.com> > Compare encoded instead of decoded digest in RSA signature verification. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: only check digest value ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8365/files - new: https://git.openjdk.java.net/jdk/pull/8365/files/a8499bb3..09188779 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8365&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8365&range=00-01 Stats: 37 lines in 2 files changed: 33 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8365.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8365/head:pull/8365 PR: https://git.openjdk.java.net/jdk/pull/8365 From xuelei at openjdk.java.net Tue Apr 26 16:04:14 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 26 Apr 2022 16:04:14 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v6] In-Reply-To: References: Message-ID: > Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. > > The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: rename and split the test case ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8272/files - new: https://git.openjdk.java.net/jdk/pull/8272/files/aaedee46..9d38fdd3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=04-05 Stats: 233 lines in 3 files changed: 136 ins; 97 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8272/head:pull/8272 PR: https://git.openjdk.java.net/jdk/pull/8272 From xuelei at openjdk.java.net Tue Apr 26 16:04:15 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 26 Apr 2022 16:04:15 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v4] In-Reply-To: References: Message-ID: <6ut2pUfhNDlHYU1UuQqpu2mRzdELVnnRfeY6PR8Qkog=.f8550dc2-7f2a-49ed-807d-e9383b94b099@github.com> On Tue, 26 Apr 2022 15:45:47 GMT, Xue-Lei Andrew Fan wrote: >> Ok, then I would suggest changing the name of the test as it is misleading. I suggest creating a directory named "PasswordCallback" and then adding a test named perhaps "CheckCleanerNotBoundToThis" or something like that. I would change the name of the `checkClearing` method as you are not checking if passwords are cleared. Also update the @summary to describe what it is actually testing. Use code comments if you need to explain it further. > > The test has two case now. One is used to check the PasswordCallback object collection at finalization. The other one is check the password clearing for clearPassword() method. Is it better to split into two test files so that the class name could be better fit the purpose? Never mind, I'm splitting the test case into two. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From sean.mullan at oracle.com Tue Apr 26 16:09:22 2022 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 26 Apr 2022 12:09:22 -0400 Subject: Timeframe for JEP-411 completely removing SecurityManager APIs In-Reply-To: References: Message-ID: 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 xueleifan at tencent.com Tue Apr 26 16:13:38 2022 From: xueleifan at tencent.com (xueleifan(XueleiFan)) Date: Tue, 26 Apr 2022 16:13:38 +0000 Subject: [Internet]Re: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4 [v2] In-Reply-To: <2h-0IRs5_2jdoK1zyCozkuTaRf9AOFzL8vmppUGWMoI=.f382c6a8-914a-4810-bc6b-69af28b84dc1@github.com> References: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> <2h-0IRs5_2jdoK1zyCozkuTaRf9AOFzL8vmppUGWMoI=.f382c6a8-914a-4810-bc6b-69af28b84dc1@github.com> Message-ID: <290C3205-8058-45B5-ABCF-428DD66F9D0C@Tencent.Com> With this update, is the purpose of this PR changed? The bug subject and description may need an update. Xuelei > On Apr 26, 2022, at 9:02 AM, Weijun Wang wrote: > >> Compare encoded instead of decoded digest in RSA signature verification. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > only check digest value > > ------------- > > Changes: > - all: https://git.openjdk.java.net/jdk/pull/8365/files > - new: https://git.openjdk.java.net/jdk/pull/8365/files/a8499bb3..09188779 > > Webrevs: > - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8365&range=01 > - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8365&range=00-01 > > Stats: 37 lines in 2 files changed: 33 ins; 3 del; 1 mod > Patch: https://git.openjdk.java.net/jdk/pull/8365.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/8365/head:pull/8365 > > PR: https://git.openjdk.java.net/jdk/pull/8365 > From weijun at openjdk.java.net Tue Apr 26 16:19:00 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 16:19:00 GMT Subject: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4 [v2] In-Reply-To: <2h-0IRs5_2jdoK1zyCozkuTaRf9AOFzL8vmppUGWMoI=.f382c6a8-914a-4810-bc6b-69af28b84dc1@github.com> References: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> <2h-0IRs5_2jdoK1zyCozkuTaRf9AOFzL8vmppUGWMoI=.f382c6a8-914a-4810-bc6b-69af28b84dc1@github.com> Message-ID: On Tue, 26 Apr 2022 16:02:41 GMT, Weijun Wang wrote: >> Compare encoded instead of decoded digest in RSA signature verification. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > only check digest value > _Mailing list message from [xueleifan(XueleiFan)](mailto:xueleifan at tencent.com) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_ > > With this update, is the purpose of this PR changed? The bug subject and description may need an update. > > Xuelei Good catch. I'll reword. ------------- PR: https://git.openjdk.java.net/jdk/pull/8365 From valeriep at openjdk.java.net Tue Apr 26 17:13:55 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 26 Apr 2022 17:13:55 GMT Subject: RFR: 8285404: RSA signature verification should reject non-DER OCTET STRING In-Reply-To: References: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> <2tN7r156HHsK5S0meYYjRd4CHy-bo3O9K9zrfYF0IRc=.861a3baf-8fd8-46c1-838d-5e9cff7ee925@github.com> Message-ID: On Sun, 24 Apr 2022 14:34:46 GMT, Weijun Wang wrote: > Regardless whether we ended up with decode/encode, we should make sure RSASSA-PSS signature impl is also covered and consistent. Never mind, PSS has its own way of verification and its impl is based on RFC 8017. ------------- PR: https://git.openjdk.java.net/jdk/pull/8365 From valeriep at openjdk.java.net Tue Apr 26 17:35:52 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 26 Apr 2022 17:35:52 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException In-Reply-To: <77iS1t15rXz0DnqsXKuRifJPbAYGLlJOTnqRt1cdKcE=.11167daf-c2ba-48d3-b14a-26a0914c554a@github.com> References: <77iS1t15rXz0DnqsXKuRifJPbAYGLlJOTnqRt1cdKcE=.11167daf-c2ba-48d3-b14a-26a0914c554a@github.com> Message-ID: On Tue, 26 Apr 2022 14:51:31 GMT, Weijun Wang 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 > > src/java.base/share/classes/java/security/Signature.java line 1510: > >> 1508: try { >> 1509: return cipher.doFinal(); >> 1510: } catch (IllegalBlockSizeException | BadPaddingException e) { > > Is this a revert of a recent fix from someone else? Must be. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From sean.mullan at oracle.com Tue Apr 26 17:38:28 2022 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 26 Apr 2022 13:38:28 -0400 Subject: Timeframe for JEP-411 completely removing SecurityManager APIs In-Reply-To: References: Message-ID: 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 weijun at openjdk.java.net Tue Apr 26 17:46:00 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 17:46:00 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v8] In-Reply-To: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> References: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> Message-ID: On Mon, 25 Apr 2022 06:07:00 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 with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge and resovle merge conflict > - change the calling order in dispose() > - More code cleanup > - re-org the code per feedback > - Update to set context method > - add test cases > - Merge > - Update copyright year > - the object reference issue for Cleaner > - 8284490: Remove finalizer method in java.security.jgss Sorry, I just updated the test. It should not run on Windows. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From valeriep at openjdk.java.net Tue Apr 26 17:51:45 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 26 Apr 2022 17:51:45 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] 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: Undo un-intentional changes. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8396/files - new: https://git.openjdk.java.net/jdk/pull/8396/files/033d4d85..9be3644d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8396&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 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 Tue Apr 26 18:19:54 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 26 Apr 2022 18:19:54 GMT Subject: RFR: 8285404: RSA signature verification should reject non-DER OCTET STRING [v2] In-Reply-To: <2h-0IRs5_2jdoK1zyCozkuTaRf9AOFzL8vmppUGWMoI=.f382c6a8-914a-4810-bc6b-69af28b84dc1@github.com> References: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> <2h-0IRs5_2jdoK1zyCozkuTaRf9AOFzL8vmppUGWMoI=.f382c6a8-914a-4810-bc6b-69af28b84dc1@github.com> Message-ID: On Tue, 26 Apr 2022 16:02:41 GMT, Weijun Wang wrote: >> Compare encoded instead of decoded digest in RSA signature verification. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > only check digest value Marked as reviewed by valeriep (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8365 From starksm64 at gmail.com Tue Apr 26 17:06:29 2022 From: starksm64 at gmail.com (Scott Stark) Date: Tue, 26 Apr 2022 10:06:29 -0700 Subject: Timeframe for JEP-411 completely removing SecurityManager APIs In-Reply-To: References: Message-ID: 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. 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, 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 valeriep at openjdk.java.net Tue Apr 26 18:30:08 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 26 Apr 2022 18:30:08 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 18:14:07 GMT, Sean Mullan wrote: >> As for the 2nd sentence, it boils down whether we requires provider to generate default parameters and return it when parameter is required. Existing javadoc states that null is returned when parameter is not required. Given Cipher covers many algorithms, if a provider does not want to generate a default parameter when parameter is required, it can't return null when getParameters() is called. > >> I can do the Signature update through https://bugs.openjdk.java.net/browse/JDK-8253176 which I have targeted to fix in 19 also. > > Ok. I have filed the PR for the Signature at: https://github.com/openjdk/jdk/pull/8396 Best to get it done along with this one. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From duke at openjdk.java.net Tue Apr 26 18:38:54 2022 From: duke at openjdk.java.net (Mark Powers) Date: Tue, 26 Apr 2022 18:38:54 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: <8qWiM1OaGDQtVmw-lJLeSwfwfQkhdevDWYY-UgnQOQ0=.251b86c7-fe92-4137-b1ce-34cbcd7ad448@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <8qWiM1OaGDQtVmw-lJLeSwfwfQkhdevDWYY-UgnQOQ0=.251b86c7-fe92-4137-b1ce-34cbcd7ad448@github.com> Message-ID: On Tue, 26 Apr 2022 04:37:58 GMT, Jaikiran Pai wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> Alan Bateman comments > > src/java.base/share/classes/javax/net/ssl/KeyStoreBuilderParameters.java line 71: > >> 69: } >> 70: >> 71: this.parameters = List.copyOf(parameters); > > Hello Mark, this would actually be a change in behaviour. The `List.copyOf` says: > >> The given Collection must not be null and it must not contain any null elements. > > The current implementation of the public constructor on the public `KeyStoreBuilderParameters` mandates no such requirement. So if there's some code which currently passes a list with a null element in it, then this change will now end up throwing a `NullPointerException` as per the contract of `List.copyOf`. You are correct. This is not a good change since it changes behavior. Going back to the original. Thanks for your review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From wetmore at openjdk.java.net Tue Apr 26 18:42:56 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 26 Apr 2022 18:42:56 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: On Tue, 26 Apr 2022 00:27:43 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8285504 >> >> 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/net > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > Alan Bateman comments src/java.base/share/classes/javax/net/ssl/KeyStoreBuilderParameters.java line 72: > 70: > 71: this.parameters = List.copyOf(parameters); > 72: } If you leave this as is, you can use `<>` ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From wetmore at openjdk.java.net Tue Apr 26 18:54:52 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 26 Apr 2022 18:54:52 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: On Tue, 26 Apr 2022 00:27:43 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8285504 >> >> 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/net > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > Alan Bateman comments Other than the comments mentioned, LGTM. src/java.base/share/classes/javax/net/ssl/SSLSessionBindingEvent.java line 37: > 35: * {@link SSLSession#putValue(String, Object)} > 36: * or {@link SSLSession#removeValue(String)}, objects which > 37: * implement the SSLSessionBindingListener will receive an If you're up for it, you could fix the missing `` or `@link` throughout this small file. Ignore otherwise. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8384 From duke at openjdk.java.net Tue Apr 26 19:13:57 2022 From: duke at openjdk.java.net (Mark Powers) Date: Tue, 26 Apr 2022 19:13:57 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v3] In-Reply-To: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: <9Qa7tyrFI12SxhLr-WLQBHjTe0Kxnu0Ua_jNSxoZ52U=.2520bead-1d46-4365-9c19-924551e3d5a9@github.com> > https://bugs.openjdk.java.net/browse/JDK-8285504 > > 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/net Mark Powers has updated the pull request incrementally with one additional commit since the last revision: jaikiran comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8384/files - new: https://git.openjdk.java.net/jdk/pull/8384/files/d964c05a..7624f4a9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8384&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8384&range=01-02 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8384/head:pull/8384 PR: https://git.openjdk.java.net/jdk/pull/8384 From weijun at openjdk.java.net Tue Apr 26 19:14:03 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 19:14:03 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: <6DEFUs_-0PDbYcjWfy-bMr0b8h-o6w9IUY__JzVWugI=.457626e6-daf1-4305-844c-becb861ef777@github.com> On Tue, 26 Apr 2022 00:27:43 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8285504 >> >> 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/net > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > Alan Bateman comments Looks fine. Some small comments. src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java line 69: > 67: String type; > 68: type = AccessController.doPrivileged((PrivilegedAction) () -> > 69: Security.getProperty("ssl.KeyManagerFactory.algorithm")); We can probably use `sun.security.action.GetPropertyAction::privilegedGetProperty`. This is inside `java.base` so that class is always available. src/java.base/share/classes/javax/net/ssl/SSLSocketFactory.java line 96: > 94: s = s.trim(); > 95: if (s.isEmpty()) { > 96: s = null; According to the implementation of `Security::getProperty`. The return value is already trimmed. src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java line 81: > 79: String type; > 80: type = AccessController.doPrivileged((PrivilegedAction) () -> > 81: Security.getProperty( "ssl.TrustManagerFactory.algorithm")); Another `GetPropertyAction::privilegedGetProperty` candidate. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From mullan at openjdk.java.net Tue Apr 26 19:29:55 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 26 Apr 2022 19:29:55 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 18:28:03 GMT, Valerie Peng wrote: >>> I can do the Signature update through https://bugs.openjdk.java.net/browse/JDK-8253176 which I have targeted to fix in 19 also. >> >> Ok. > > I have filed the PR for the Signature at: https://github.com/openjdk/jdk/pull/8396 > Best to get it done along with this one. > As for the 2nd sentence, it boils down whether we requires provider to generate default parameters and return it when parameter is required. Existing javadoc states that null is returned when parameter is not required. Given Cipher covers many algorithms, if a provider does not want to generate a default parameter when parameter is required, it can't return null when getParameters() is called. Ok, maybe we need to reset the context. What was the main issue with the current specification that you were trying to fix? I read the associated bug report. It sounds like there were two issues: - ProviderException can be thrown, but the method does not declare it in the throws clause. That doesn't seem to be addressed here - do you think it should be? - cases when null may be returned as opposed to throwing a ProviderException It could be that what is really just needed is an @throws ProviderException, ex: "If this cipher implementation requires algorithm parameters to be passed in at initialization but was not initialized with any". and a slight tweak to the description (changes in italics): "... if this cipher _can generate required_ algorithm parameters but was not initialized with any." ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From duke at openjdk.java.net Tue Apr 26 19:30:55 2022 From: duke at openjdk.java.net (Mark Powers) Date: Tue, 26 Apr 2022 19:30:55 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: On Tue, 26 Apr 2022 18:39:33 GMT, Bradford Wetmore wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> Alan Bateman comments > > src/java.base/share/classes/javax/net/ssl/KeyStoreBuilderParameters.java line 72: > >> 70: >> 71: this.parameters = List.copyOf(parameters); >> 72: } > > If you leave this as is, you can use `<>` Using <>. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From wetmore at openjdk.java.net Tue Apr 26 19:52:47 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 26 Apr 2022 19:52:47 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: <6DEFUs_-0PDbYcjWfy-bMr0b8h-o6w9IUY__JzVWugI=.457626e6-daf1-4305-844c-becb861ef777@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <6DEFUs_-0PDbYcjWfy-bMr0b8h-o6w9IUY__JzVWugI=.457626e6-daf1-4305-844c-becb861ef777@github.com> Message-ID: <_xKqXJpVgw9hYRf9VG1n2KKu74Py5BGpatA20GM5xxc=.d63a97a7-aec1-4e22-92d3-18061ac4ab12@github.com> On Tue, 26 Apr 2022 19:05:05 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> Alan Bateman comments > > src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java line 69: > >> 67: String type; >> 68: type = AccessController.doPrivileged((PrivilegedAction) () -> >> 69: Security.getProperty("ssl.KeyManagerFactory.algorithm")); > > We can probably use `sun.security.action.GetPropertyAction::privilegedGetProperty`. This is inside `java.base` so that class is always available. Wasn't there another bug to address this? ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From weijun at openjdk.java.net Tue Apr 26 19:53:49 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 19:53:49 GMT Subject: RFR: 8285380: Fix typos in security [v2] In-Reply-To: <8CkpsaXwOu9slGqU9bV9fF9EZx-Q_6BdgaMioe5MJWU=.6e49a022-bd0a-4fec-bdd8-8299381165d7@github.com> References: <8CkpsaXwOu9slGqU9bV9fF9EZx-Q_6BdgaMioe5MJWU=.6e49a022-bd0a-4fec-bdd8-8299381165d7@github.com> Message-ID: <6xTxlkJIWyv2Us0EnyQQXEBUHHk8ekLOzso7Bz_W3og=.7cc111de-b4c8-42cd-bae6-ae95d36b58a0@github.com> On Thu, 21 Apr 2022 17:32:32 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. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes to Apache code Looks good to me. Thanks. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8340 From mullan at openjdk.java.net Tue Apr 26 20:15:52 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 26 Apr 2022 20:15:52 GMT Subject: RFR: 8209935: Test to cover CodeSource.getCodeSigners() [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 13:26:30 GMT, Sibabrata Sahoo wrote: >> A Test updated to cover the getCodeSigners. > > Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision: > > Update Implies.java Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8286 From mullan at openjdk.java.net Tue Apr 26 20:27:43 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 26 Apr 2022 20:27:43 GMT Subject: RFR: 8225433: Clarify behavior of PKIXParameters.setRevocationEnabled when PKIXRevocationChecker is used In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 13:35:25 GMT, Sean Mullan wrote: > This change improves the specification for the case when a `PKIXRevocationChecker` is supplied as one of the `CertPathChecker` parameters. Specifically, it makes it more clear that a `PKIXRevocationChecker` overrides the default revocation checking mechanism of a PKIX service provider, and will be used to check revocation irrespective of the setting of the RevocationEnabled parameter. > > Will also file a CSR. ping ... CSR also ready for review at https://bugs.openjdk.java.net/browse/JDK-8285262 ------------- PR: https://git.openjdk.java.net/jdk/pull/8287 From wetmore at openjdk.java.net Tue Apr 26 20:40:52 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 26 Apr 2022 20:40:52 GMT Subject: RFR: 8285380: Fix typos in security [v2] In-Reply-To: <8CkpsaXwOu9slGqU9bV9fF9EZx-Q_6BdgaMioe5MJWU=.6e49a022-bd0a-4fec-bdd8-8299381165d7@github.com> References: <8CkpsaXwOu9slGqU9bV9fF9EZx-Q_6BdgaMioe5MJWU=.6e49a022-bd0a-4fec-bdd8-8299381165d7@github.com> Message-ID: On Thu, 21 Apr 2022 17:32:32 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. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes to Apache code LGTM. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8340 From wetmore at openjdk.java.net Tue Apr 26 20:43:56 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 26 Apr 2022 20:43:56 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: <_xKqXJpVgw9hYRf9VG1n2KKu74Py5BGpatA20GM5xxc=.d63a97a7-aec1-4e22-92d3-18061ac4ab12@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <6DEFUs_-0PDbYcjWfy-bMr0b8h-o6w9IUY__JzVWugI=.457626e6-daf1-4305-844c-becb861ef777@github.com> <_xKqXJpVgw9hYRf9VG1n2KKu74Py5BGpatA20GM5xxc=.d63a97a7-aec1-4e22-92d3-18061ac4ab12@github.com> Message-ID: On Tue, 26 Apr 2022 19:49:11 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java line 69: >> >>> 67: String type; >>> 68: type = AccessController.doPrivileged((PrivilegedAction) () -> >>> 69: Security.getProperty("ssl.KeyManagerFactory.algorithm")); >> >> We can probably use `sun.security.action.GetPropertyAction::privilegedGetProperty`. This is inside `java.base` so that class is always available. > > Wasn't there another bug to address this? Perhaps as part of [JDK-6725221](https://bugs.openjdk.java.net/browse/JDK-6725221)? ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From weijun at openjdk.java.net Tue Apr 26 20:51:56 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 20:51:56 GMT Subject: Integrated: 8285404: RSA signature verification should reject non-DER OCTET STRING In-Reply-To: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> References: <8hc3urNfRrU2ikT7JhVx0JYsgTDUZPcc6OZv-GNz2tk=.1024b122-b99e-4a97-b884-dd1d37226406@github.com> Message-ID: On Fri, 22 Apr 2022 17:10:58 GMT, Weijun Wang wrote: > Compare encoded instead of decoded digest in RSA signature verification. This pull request has now been integrated. Changeset: 14e7d911 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/14e7d911997d33eba2893991fa0e2f507aa977f8 Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 mod 8285404: RSA signature verification should reject non-DER OCTET STRING Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/8365 From libaem03 at gmail.com Tue Apr 26 20:59:25 2022 From: libaem03 at gmail.com (Lilian Castro) Date: Tue, 26 Apr 2022 15:59:25 -0500 Subject: No subject Message-ID: Security mailing list -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun at openjdk.java.net Tue Apr 26 21:11:16 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 21:11:16 GMT Subject: RFR: 8285493: ECC calculation error Message-ID: Only numbers from the same modular fields can be involved in arithmetic calculations. Add `assert` to guarantee this. Also, found one broken case and rewrote it. ------------- Commit messages: - ECC calculation error fix Changes: https://git.openjdk.java.net/jdk/pull/8409/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8409&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285493 Stats: 16 lines in 2 files changed: 3 ins; 4 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8409.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8409/head:pull/8409 PR: https://git.openjdk.java.net/jdk/pull/8409 From duke at openjdk.java.net Tue Apr 26 21:15:49 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 26 Apr 2022 21:15:49 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: References: Message-ID: <_wwF-r6XfbTRC-aiQsjlgLYH_jvXK5izdteClNxqnoU=.60c86172-6b83-418e-b0f0-2ebae9c6b5ec@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 Let's wait a bit ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From vitaly.provodin at jetbrains.com Thu Apr 21 00:06:57 2022 From: vitaly.provodin at jetbrains.com (Vitaly Provodin) Date: Thu, 21 Apr 2022 07:06:57 +0700 Subject: zlib before 1.2.12 allows memory corruption (CVE-2018-25032) Message-ID: <8EA8A007-5C47-46CF-B126-6C57DCDAB281@jetbrains.com> 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 msj at nthpermutation.com Thu Apr 21 22:39:38 2022 From: msj at nthpermutation.com (Michael StJohns) Date: Thu, 21 Apr 2022 18:39:38 -0400 Subject: CVE-2022-21449: Psychic Signatures in Java Message-ID: <4edf7356-862b-f4cc-44e2-0bedde161f30@nthpermutation.com> Hi - FYI - This is currently getting some play time on the Crypto Forum Research Group (related to the IETF): https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/ The thread starts here: https://mailarchive.ietf.org/arch/msg/cfrg/wlIuVws-pmccvbGbBrIBVBhN2GQ/ It's probably covered by an existing patch, but I thought the thread was a useful pointer to some tools. Later, Mike From peter.firmstone at zeus.net.au Tue Apr 26 22:03:42 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 27 Apr 2022 08:03:42 +1000 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: Well said, we're not trying to sandbox untrusted code.? We're simply trying to provide authorization controls on authenticated users and in my particular case, service proxy's.?? It's well known the JVM can't handle untrusted code, nor does it have well designed defenses against parsing untrusted data, all these things happen to be bolted on afterthoughts. Regards, Peter. On 26/04/2022 11:07 pm, David Lloyd wrote: > On Tue, Apr 26, 2022 at 4:47 AM Alan Bateman wrote: >> On 25/04/2022 13:53, David Lloyd wrote: >>> Nothing in the proposal causes splitting or delegation of >>> responsibilities. It is _only_ about preserving security checkpoints >>> in the JDK, which *add* a layer of checks to what the container might >>> already provide. Nothing is being subtracted, and thus I find it hard >>> to accept that preserving these checks somehow reduces security >>> overall. >> "preserving security checkpoints in the JDK" suggests just leaving the >> calls do AccessController.doPrivileged and >> SecurityManager.checkPermission in place. > The proposal is clear that the JDK 'doPrivileged' calls would not be > necessary, and it is not necessary to exactly use `checkPermission` > depending on the approach taken. This might or might not counter your > argument, but as I said before, even if the proposal is rejected, it > should be rejected based on a fair and accurate evaluation of what is > proposed. > >> That amounts to putting a tax >> on every feature, every JEP, and all ongoing maintenance of the >> platform. If there is refactoring or a change that forgets to insert a >> checkPermission somewhere then we have a security issue and everything >> that goes along with that. > Sure, if you continue to think of SecurityManager as a sandbox, then > every case where it is not a perfect sandbox can be a major security > issue. In real terms though, was SecurityManager ever _actually_ > effective as a sandbox? It is certainly the case that few (if any) of > us who do systems and security programming in application servers and > containers at Red Hat have ever considered it so. Thus, the proposal > as given tries to reflect this reality by treating the SecurityManager > as exactly two things: firstly, a central point for any application or > library to be able to statically perform an authorization check > without needing to rely on any library other than the JDK itself; and > secondly, a mechanism by which certain operations performed by the JDK > can be authorized by the user. > > The lack of an authorization check would therefore be less impactful > when considered from this perspective. Maybe a security issue, yes, > but not a sandbox escape because there _is_ no sandbox. It's not a > part of the contract anymore. In fact, part of the contract could even > be an _explicit admonition_ that missing checks in the JDK would be > considered bugs but not security issues. Even that would be better > than removing the whole thing; if doing X has an unacceptable cost, > let's stop doing X instead of getting rid of Y. > >> I think Martin is right that hooking authorization libraries into low >> level libraries isn't the right way to do this. Aside from the >> complexity methods I would add that threads pools or any hand-off >> between threads will typically break when the context is not carried. > Propagation of security context is not a problem that needs a solution > in the JDK and is not a part of the proposal. It's generally already a > solved problem within containers, where this feature is intended to be > used, including cases where threads are created or tasks are > dispatched to thread pools, fork/join, etc. Thus the proposal > establishes that this is 100% the responsibility of the security > manager implementation. > >> One other point about authorization libraries wanting to hook into low >> level code is that it's a minefield of potential issues with recursive >> initialization, stack overflows and some really hard to diagnose issues. >> JDK-8155659 [1] is one report that comes to mind. > It is up to the implementation to deal with recursive calls into the > security manager today (and we already do so to our own satisfaction), > and I don't see any reason why that wouldn't continue to be the case. > In my opinion, this would not be an issue that the JDK has to be > concerned about (other than maybe as a documentation issue). > From weijun at openjdk.java.net Tue Apr 26 22:11:06 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 26 Apr 2022 22:11:06 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <6DEFUs_-0PDbYcjWfy-bMr0b8h-o6w9IUY__JzVWugI=.457626e6-daf1-4305-844c-becb861ef777@github.com> <_xKqXJpVgw9hYRf9VG1n2KKu74Py5BGpatA20GM5xxc=.d63a97a7-aec1-4e22-92d3-18061ac4ab12@github.com> Message-ID: On Tue, 26 Apr 2022 20:40:50 GMT, Bradford Wetmore wrote: >> Wasn't there another bug to address this? > > Perhaps as part of [JDK-6725221](https://bugs.openjdk.java.net/browse/JDK-6725221)? No problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From darcy at openjdk.java.net Tue Apr 26 22:33:21 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 26 Apr 2022 22:33:21 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces Message-ID: To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). I'll update copyright years before pushing. ------------- Commit messages: - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces Changes: https://git.openjdk.java.net/jdk/pull/8410/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285676 Stats: 76 lines in 40 files changed: 76 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410 PR: https://git.openjdk.java.net/jdk/pull/8410 From ecki at zusammenkunft.net Tue Apr 26 22:49:48 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 26 Apr 2022 22:49:48 +0000 Subject: CVE-2022-21449: Psychic Signatures in Java In-Reply-To: <4edf7356-862b-f4cc-44e2-0bedde161f30@nthpermutation.com> References: <4edf7356-862b-f4cc-44e2-0bedde161f30@nthpermutation.com> Message-ID: Hello Michael, thanks for the pointer, interesting read. I think the key takeaway from that discussion is, that the Wycheproof Testcases would have catched this problem and should probably be added to the OpenJDK tests. (I wonder, does Google not run those in qualification builds?) The discussion itself is a bit strange in regards to expensive validations since the null test is rather fast, but I suppose it is a sore point of non-safe curves with Java having previously good track records. BTW for completeness the change from the April update is here, it does not only cover ECDSA but also DSA: https://github.com/openjdk/jdk/commit/e2f8ce9c3ff4518e070960bafa70ba780746aa5c While the ECDSA Bug is introduced in java 15 the DSA part of the patch affects Java for ages (CVE is 7+). Those 7/8 fixes are available from some of the vendors (like Oracle and Azul), however the OpenJDK 8u Repo seems to be not yet fixed: https://github.com/openjdk/jdk8u/blob/d91ee59b3c8cd76b945b517336351f496ab3ff56/jdk/src/share/classes/sun/security/provider/DSA.java#L302 Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Michael StJohns Gesendet: Friday, April 22, 2022 12:39:38 AM An: security-dev at openjdk.java.net Betreff: CVE-2022-21449: Psychic Signatures in Java Hi - FYI - This is currently getting some play time on the Crypto Forum Research Group (related to the IETF): https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/ The thread starts here: https://mailarchive.ietf.org/arch/msg/cfrg/wlIuVws-pmccvbGbBrIBVBhN2GQ/ It's probably covered by an existing patch, but I thought the thread was a useful pointer to some tools. Later, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From wetmore at openjdk.java.net Tue Apr 26 23:02:19 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 26 Apr 2022 23:02:19 GMT Subject: RFR: 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields Message-ID: Two new constant fields `MGF1ParameterSpec.SHA512_224` and `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293). This bug addresses this issue. ------------- Commit messages: - 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields Changes: https://git.openjdk.java.net/jdk/pull/8411/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8411&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285683 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8411.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8411/head:pull/8411 PR: https://git.openjdk.java.net/jdk/pull/8411 From wetmore at openjdk.java.net Tue Apr 26 23:05:58 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 26 Apr 2022 23:05:58 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. The two `java.security` ones LGTM. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8410 From bradford.wetmore at oracle.com Tue Apr 26 23:09:30 2022 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 26 Apr 2022 16:09:30 -0700 Subject: zlib before 1.2.12 allows memory corruption (CVE-2018-25032) In-Reply-To: <8EA8A007-5C47-46CF-B126-6C57DCDAB281@jetbrains.com> References: <8EA8A007-5C47-46CF-B126-6C57DCDAB281@jetbrains.com> Message-ID: <98dea46a-eb60-d360-bb8f-22d515d1feb6@oracle.com> On 4/20/2022 5:06 PM, Vitaly Provodin wrote: > 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 Hi Vitaly, A better forum might be core-lib-dev[1], and build-dev as you already cc'd. Brad [1] https://mail.openjdk.java.net/mailman/listinfo/core-libs-dev From hchao at openjdk.java.net Tue Apr 26 23:12:58 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 26 Apr 2022 23:12:58 GMT Subject: RFR: 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:55:29 GMT, Bradford Wetmore wrote: > Two new constant fields `MGF1ParameterSpec.SHA512_224` and `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293). > > This bug addresses this issue. Marked as reviewed by hchao (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8411 From ecki at zusammenkunft.net Tue Apr 26 23:20:27 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 26 Apr 2022 23:20:27 +0000 Subject: zlib before 1.2.12 allows memory corruption (CVE-2018-25032) In-Reply-To: <8EA8A007-5C47-46CF-B126-6C57DCDAB281@jetbrains.com> References: <8EA8A007-5C47-46CF-B126-6C57DCDAB281@jetbrains.com> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjg at openjdk.java.net Tue Apr 26 23:38:42 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 26 Apr 2022 23:38:42 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. src/java.base/share/classes/java/lang/ClassValue.java line 43: > 41: * it can use a {@code ClassValue} to cache information needed to > 42: * perform the message send quickly, for each class encountered. > 43: * @param type of the derived value stylistically, compared to other comments, you are missing an initial "the" ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From valeriep at openjdk.java.net Wed Apr 27 00:12:40 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 27 Apr 2022 00:12:40 GMT Subject: RFR: 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:55:29 GMT, Bradford Wetmore wrote: > Two new constant fields `MGF1ParameterSpec.SHA512_224` and `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293). > > This bug addresses this issue. Looks good. Thanks~ ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8411 From valeriep at openjdk.java.net Wed Apr 27 00:15:43 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 27 Apr 2022 00:15:43 GMT Subject: RFR: 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields In-Reply-To: References: Message-ID: <_UZrkZrdGUmjoGgy0ZvMwkztK1NZ7fk5QlhzToY71bk=.46ad4d6f-e7ff-4152-aa43-b6a67cc416f8@github.com> On Tue, 26 Apr 2022 22:55:29 GMT, Bradford Wetmore wrote: > Two new constant fields `MGF1ParameterSpec.SHA512_224` and `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293). > > This bug addresses this issue. Is a CSR needed? ------------- PR: https://git.openjdk.java.net/jdk/pull/8411 From wetmore at openjdk.java.net Wed Apr 27 00:25:43 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 27 Apr 2022 00:25:43 GMT Subject: RFR: 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields In-Reply-To: <_UZrkZrdGUmjoGgy0ZvMwkztK1NZ7fk5QlhzToY71bk=.46ad4d6f-e7ff-4152-aa43-b6a67cc416f8@github.com> References: <_UZrkZrdGUmjoGgy0ZvMwkztK1NZ7fk5QlhzToY71bk=.46ad4d6f-e7ff-4152-aa43-b6a67cc416f8@github.com> Message-ID: On Wed, 27 Apr 2022 00:12:32 GMT, Valerie Peng wrote: > Is a CSR needed? @valeriepeng I would be surprised. I don't think so, but checking with CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8411 From valeriep at openjdk.java.net Wed Apr 27 00:40:07 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 27 Apr 2022 00:40:07 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: <77iS1t15rXz0DnqsXKuRifJPbAYGLlJOTnqRt1cdKcE=.11167daf-c2ba-48d3-b14a-26a0914c554a@github.com> References: <77iS1t15rXz0DnqsXKuRifJPbAYGLlJOTnqRt1cdKcE=.11167daf-c2ba-48d3-b14a-26a0914c554a@github.com> Message-ID: On Tue, 26 Apr 2022 14:59:35 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Undo un-intentional changes. > > src/java.base/share/classes/java/security/Signature.java line 1015: > >> 1013: * parameters were not supplied and the underlying signature implementation >> 1014: * can generate the parameter values, it will be returned. Otherwise, >> 1015: * {@code null} is returned. > > If we cannot guarantee anything but just want to clarify. how about just say "The returned parameters is a combination of user-provided values, implementation default values, and/or random values used by the underlying signature implementation. It can also be {@code null} if there's none." > > I assume that if a value is necessary but user has not provided one, then there will be a default or a random one. I searched about "and/or" and it is said that "or" covers "and". So, "and/or" should just be "or". I am on the fence for requiring provider to generate default parameters (using provider-specific or random values). Could there be scenarios where users are required to supply parameters? That aside, this javadoc is lastly updated by JDK-8243424. It seems that JDK's EdDSA signature impl has some interesting usage of AlgorithmParameterSpec which this javadoc has to cover/allow. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From duke at openjdk.java.net Wed Apr 27 00:43:54 2022 From: duke at openjdk.java.net (Mat Carter) Date: Wed, 27 Apr 2022 00:43:54 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider In-Reply-To: References: Message-ID: <0cT-_dw8IdRJ-iIPH0IWD1nTmldL8KCpBDpNf_2q3-w=.7b3f8c63-1374-47b2-b0e1-d3eabc1a8c34@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 Please see draft CSR: https://bugs.openjdk.java.net/browse/JDK-8284850 ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From smarks at openjdk.java.net Wed Apr 27 01:48:49 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 27 Apr 2022 01:48:49 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. I've looked at the changes in java.util (but not sub packages). They're fine, modulo some minor wording changes. src/java.base/share/classes/java/util/AbstractMap.java line 601: > 599: * {@code Map.entrySet().toArray}. > 600: * > 601: * @param the type of keys maintained Please update to match java.util.Map, which says "the type of keys maintained by this map" src/java.base/share/classes/java/util/AbstractMap.java line 748: > 746: * > 747: * @param the type of keys maintained > 748: * @param the type of mapped values Please update to match Map.Entry, which says simply "the type of key" and "the type of the value" src/java.base/share/classes/java/util/Dictionary.java line 44: > 42: * @param the type of keys > 43: * @param the type of mapped values > 44: * Urgh. This class is obsolete, but it was retrofitted to implement Map and was subsequently generified, so I'd update these to match java.util.Map. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8410 From xuelei at openjdk.java.net Wed Apr 27 02:19:38 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 02:19:38 GMT Subject: RFR: 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:55:29 GMT, Bradford Wetmore wrote: > Two new constant fields `MGF1ParameterSpec.SHA512_224` and `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293). > > This bug addresses this issue. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8411 From duke at openjdk.java.net Wed Apr 27 02:24:43 2022 From: duke at openjdk.java.net (Bernd) Date: Wed, 27 Apr 2022 02:24:43 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 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 src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 419: > 417: __leave; > 418: } > 419: if ((pszCertStoreLocation = env->GetStringUTFChars(jCertStoreLocation, NULL)) Would it be easier to use a int argument here, it?s a internal api with only two enumerated Types. That safes the jstring conversion and the Strcmp. ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Wed Apr 27 02:29:52 2022 From: duke at openjdk.java.net (Bernd) Date: Wed, 27 Apr 2022 02:29:52 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 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 src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 487: > 485: // Check if private key available - client authentication certificate > 486: // must have private key available. > 487: HCRYPTPROV_OR_NCRYPT_KEY_HANDLE hCryptProv = NULL; It is not quite clear from the CSR, was this a bug (previous JDK-8026953 incomplete) or is that only a type cleanup and using ncrypt keys worked before? (In that Case does it need to be mentioned in csr?) ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Wed Apr 27 02:36:41 2022 From: duke at openjdk.java.net (Bernd) Date: Wed, 27 Apr 2022 02:36:41 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider In-Reply-To: References: Message-ID: <08kPGJRnG_Evtq3WCMH6nssW4Otk7AvaDHGWpTnBE1k=.e372fba4-2d0a-424d-975a-03335e0b1e34@github.com> On Wed, 27 Apr 2022 02:21:07 GMT, Bernd 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 > > src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 419: > >> 417: __leave; >> 418: } >> 419: if ((pszCertStoreLocation = env->GetStringUTFChars(jCertStoreLocation, NULL)) > > Would it be easier to use a int argument here, it?s a internal api with only two enumerated Types. That safes the jstring conversion and the Strcmp. And also, is there a ReleaseString missing? ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From xuelei at openjdk.java.net Wed Apr 27 06:14:41 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 06:14:41 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:51:45 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: > > Undo un-intentional changes. src/java.base/share/classes/java/security/Signature.java line 1012: > 1010: * values used by the underlying signature implementation if the underlying > 1011: * signature implementation supports returning the parameters as > 1012: * {@code AlgorithmParameters}. If the required "... if the underlying signature implementation supports returning the parameters a {@code AlgorithmParameters}", it looks this part is duplicated and may be removed. src/java.base/share/classes/java/security/Signature.java line 1014: > 1012: * {@code AlgorithmParameters}. If the required > 1013: * parameters were not supplied and the underlying signature implementation > 1014: * can generate the parameter values, it will be returned. Otherwise, > If the required parameters were not supplied and the underlying signature implementation can generate the parameter values, it will be returned. What does it refer to with 'it'? Is 'it' refer to the implementation generated parameter values? > If the required parameters were not supplied and the underlying signature implementation can generate the parameter values, it will be returned. Otherwise, {@code null} is returned. The logic looks like if (A & B) { // it will be returned } else { // {@code null} is returned. } If I read it correctly, the behavior may look like: 1. If the required parameters were supplied, {@code null} is returned; (if !A) 2. if the underlying signature implementation cannot generate the parameter values, {@code null} is returned; (if !B) 3. if not 1 and 2, ... (if A & B) It does not look like right. The expected behavior may be: if (A) { if (B) { // it will be returned } else { // {@code null} is returned. } } Maybe, the confusion could be mitigated by re-org the logic: if (A & !B) { // {@code null} is returned. } // Otherwise, refer to 1st sentence. "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} is returned if the required parameters were not supplied and the underlying signature implementation cannot generate the parameter values." Similar comment to [PR 8117](https://github.com/openjdk/jdk/pull/8117), if you want to use similar description there as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From xuelei at openjdk.java.net Wed Apr 27 06:31:37 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 06:31:37 GMT Subject: RFR: 8285493: ECC calculation error In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 21:02:49 GMT, Weijun Wang wrote: > Only numbers from the same modular fields can be involved in arithmetic calculations. Add `assert` to guarantee this. > > Also, found one broken case and rewrote it. src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSAOperations.java line 261: > 259: IntegerModuloP result = p1.asAffine().getX(); > 260: b2a(result, orderField, temp1); > 261: return MessageDigest.isEqual(temp1, r); I did not get the point of this update. Is it the broken case you mentioned in the PR description? What's the issue of the original code? src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSAOperations.java line 261: > 259: IntegerModuloP result = p1.asAffine().getX(); > 260: b2a(result, orderField, temp1); > 261: return MessageDigest.isEqual(temp1, r); I did not get the point of this update. Is it the broken case you mentioned in the PR description? What's the issue of the original code? ------------- PR: https://git.openjdk.java.net/jdk/pull/8409 From xuelei at openjdk.java.net Wed Apr 27 06:50:39 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 06:50:39 GMT Subject: RFR: 8225433: Clarify behavior of PKIXParameters.setRevocationEnabled when PKIXRevocationChecker is used In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 13:35:25 GMT, Sean Mullan wrote: > This change improves the specification for the case when a `PKIXRevocationChecker` is supplied as one of the `CertPathChecker` parameters. Specifically, it makes it more clear that a `PKIXRevocationChecker` overrides the default revocation checking mechanism of a PKIX service provider, and will be used to check revocation irrespective of the setting of the RevocationEnabled parameter. > > Will also file a CSR. Looks good to me, except a minor nit. src/java.base/share/classes/java/security/cert/PKIXParameters.java line 339: > 337: * #setCertPathCheckers setCertPathCheckers} methods). > 338: *

> 339: * However, if a {@code PKIXRevocationChecker} is passed in as a parameter The word "However" may be not necessary as the previous paragraph is ending with a substitute mechanism. This sentence could be a further explanation of the substitute mechanism. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8287 From xuelei at openjdk.java.net Wed Apr 27 06:58:41 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 06:58:41 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2] In-Reply-To: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> References: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> Message-ID: On Thu, 7 Apr 2022 20:17:28 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 two additional commits since the last revision: > > - typo blank linke correction > - revise the update ping ... ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From xuelei at openjdk.java.net Wed Apr 27 07:17:44 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 07:17:44 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v9] 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: final pName and new test case ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8136/files - new: https://git.openjdk.java.net/jdk/pull/8136/files/69fe16d0..32e0a469 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=07-08 Stats: 199 lines in 3 files changed: 195 ins; 1 del; 3 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 xuelei at openjdk.java.net Wed Apr 27 07:17:44 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 07:17:44 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v8] In-Reply-To: References: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> Message-ID: <_KLCUQopmdBH44wO7gCClBxx9pxF-zXOxFZNaYfmpAM=.e0bbb2ee-3567-4070-88e8-e44906c357bd@github.com> On Tue, 26 Apr 2022 15:43:09 GMT, Weijun Wang wrote: > Can you try out this test? > > ``` > diff --git a/test/jdk/sun/security/krb5/auto/Cleaners.java b/test/jdk/sun/security/krb5/auto/Cleaners.java > new file mode 100644 > index 00000000000..43f06cb9f60 > --- /dev/null > +++ b/test/jdk/sun/security/krb5/auto/Cleaners.java > @@ -0,0 +1,179 @@ > +/* > + * 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. > + */ > + > +/* > + * @test > + * @bug 8284490 > + * @summary Remove finalizer method in java.security.jgss > + * @requires os.family != "windows" > + * @library /test/lib > + * @compile -XDignore.symbol.file Cleaners.java > + * @run main/othervm Cleaners launcher > + */ > + > +import java.nio.charset.StandardCharsets; > +import java.nio.file.Files; > +import java.nio.file.Paths; > +import java.nio.file.attribute.PosixFilePermission; > +import java.util.Arrays; > +import java.util.Set; > + > +import jdk.test.lib.Asserts; > +import jdk.test.lib.process.Proc; > +import org.ietf.jgss.Oid; > +import sun.security.krb5.Config; > + > +public class Cleaners { > + > + private static final String CONF = "krb5.conf"; > + private static final String KTAB_S = "server.ktab"; > + private static final String KTAB_B = "backend.ktab"; > + > + private static final String HOST = "localhost"; > + private static final String SERVER = "server/" + HOST; > + private static final String BACKEND = "backend/" + HOST; > + private static final String USER = "user"; > + private static final char[] PASS = "password".toCharArray(); > + private static final String REALM = "REALM"; > + > + private static final byte[] MSG = "12345678".repeat(128) > + .getBytes(StandardCharsets.UTF_8); > + > + public static void main(String[] args) throws Exception { > + > + Oid oid = new Oid("1.2.840.113554.1.2.2"); > + byte[] token, msg; > + > + switch (args[0]) { > + case "launcher" -> { > + KDC kdc = KDC.create(REALM, HOST, 0, true); > + kdc.addPrincipal(USER, PASS); > + kdc.addPrincipalRandKey("krbtgt/" + REALM); > + kdc.addPrincipalRandKey(SERVER); > + kdc.addPrincipalRandKey(BACKEND); > + > + // Native lib might do some name lookup > + KDC.saveConfig(CONF, kdc, > + "dns_lookup_kdc = no", > + "ticket_lifetime = 1h", > + "dns_lookup_realm = no", > + "dns_canonicalize_hostname = false", > + "forwardable = true"); > + System.setProperty("java.security.krb5.conf", CONF); > + Config.refresh(); > + > + // Create kaytab and ccache files for native clients > + kdc.writeKtab(KTAB_S, false, SERVER); > + kdc.writeKtab(KTAB_B, false, BACKEND); > + kdc.kinit(USER, "ccache"); > + Files.setPosixFilePermissions(Paths.get("ccache"), > + Set.of(PosixFilePermission.OWNER_READ, > + PosixFilePermission.OWNER_WRITE)); > + > + Proc pc = proc("client") > + .env("KRB5CCNAME", "FILE:ccache") > + .env("KRB5_KTNAME", "none") // Do not try system ktab if ccache fails > + .start(); > + Proc ps = proc("server") > + .env("KRB5_KTNAME", KTAB_S) > + .start(); > + Proc pb = proc("backend") > + .env("KRB5_KTNAME", KTAB_B) > + .start(); > + > + // Client and server > + ps.println(pc.readData()); // AP-REQ > + pc.println(ps.readData()); // AP-REP, mutual auth > + ps.println(pc.readData()); // wrap msg > + ps.println(pc.readData()); // mic msg > + > + // Server and backend > + pb.println(ps.readData()); // AP-REQ > + ps.println(pb.readData()); // wrap msg > + ps.println(pb.readData()); // mic msg > + > + ensureCleanersCalled(pc); > + ensureCleanersCalled(ps); > + ensureCleanersCalled(pb); > + } > + case "client" -> { > + Context c = Context.fromThinAir(); > + c.startAsClient(SERVER, oid); > + c.x().requestCredDeleg(true); > + c.x().requestMutualAuth(true); > + Proc.binOut(c.take(new byte[0])); // AP-REQ > + c.take(Proc.binIn()); // AP-REP > + Proc.binOut(c.wrap(MSG, true)); > + Proc.binOut(c.getMic(MSG)); > + } > + case "server" -> { > + Context s = Context.fromThinAir(); > + s.startAsServer(oid); > + token = Proc.binIn(); // AP-REQ > + Proc.binOut(s.take(token)); // AP-REP > + msg = s.unwrap(Proc.binIn(), true); > + Asserts.assertTrue(Arrays.equals(msg, MSG)); > + s.verifyMic(Proc.binIn(), msg); > + Context s2 = s.delegated(); > + s2.startAsClient(BACKEND, oid); > + s2.x().requestMutualAuth(false); > + Proc.binOut(s2.take(new byte[0])); // AP-REQ > + msg = s2.unwrap(Proc.binIn(), true); > + Asserts.assertTrue(Arrays.equals(msg, MSG)); > + s2.verifyMic(Proc.binIn(), msg); > + } > + case "backend" -> { > + Context b = Context.fromThinAir(); > + b.startAsServer(oid); > + token = b.take(Proc.binIn()); // AP-REQ > + Asserts.assertTrue(token == null); > + Proc.binOut(b.wrap(MSG, true)); > + Proc.binOut(b.getMic(MSG)); > + } > + } > + System.out.println("Prepare for GC"); > + for (int i = 0; i < 10; i++) { > + System.gc(); > + Thread.sleep(100); > + } > + } > + > + private static void ensureCleanersCalled(Proc p) throws Exception { > + p.output() > + .shouldHaveExitValue(0) > + .stdoutShouldMatch("Prepare for GC(.|\\n)*GSSLibStub_deleteContext") > + .stdoutShouldMatch("Prepare for GC(.|\\n)*GSSLibStub_releaseName") > + .stdoutShouldMatch("Prepare for GC(.|\\n)*GSSLibStub_releaseCred"); > + } > + > + private static Proc proc(String type) throws Exception { > + return Proc.create("Cleaners") > + .args(type) > + .debug(type) > + .env("KRB5_CONFIG", CONF) > + .env("KRB5_TRACE", "/dev/stderr") > + .prop("sun.security.jgss.native", "true") > + .prop("javax.security.auth.useSubjectCredsOnly", "false") > + .prop("sun.security.nativegss.debug", "true"); > + } > +} > diff --git a/test/lib/jdk/test/lib/process/Proc.java b/test/lib/jdk/test/lib/process/Proc.java > index 3541f34144f..574e5761d03 100644 > --- a/test/lib/jdk/test/lib/process/Proc.java > +++ b/test/lib/jdk/test/lib/process/Proc.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2013, 2021, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2013, 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 > @@ -123,6 +123,7 @@ public class Proc { > private String debug; // debug flag, controller will show data > // transfer between procs. If debug is set, > // it MUST be different between Procs. > + private final StringBuilder stdout = new StringBuilder(); > > final private static String PREFIX = "PROCISFUN:"; > > @@ -358,6 +359,9 @@ public class Proc { > // Reads a line from stdout of proc > public String readLine() throws IOException { > String s = br.readLine(); > + if (s != null) { > + stdout.append(s).append('\n'); > + } > if (debug != null) { > System.out.println("PROC: " + debug + " readline: " + > (s == null ? "" : s)); > @@ -402,6 +406,16 @@ public class Proc { > } > return p.waitFor(); > } > + > + // Returns an OutputAnalyzer > + public OutputAnalyzer output() throws Exception { > + int exitCode = waitFor(); > + Path stderr = Path.of(getId("stderr")); > + return new OutputAnalyzer(stdout.toString(), > + Files.exists(stderr) ? Files.readString(stderr) : "", > + exitCode); > + } > + > // Wait for process end with expected exit code > public void waitFor(int expected) throws Exception { > if (p.waitFor() != expected) { > ``` ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From xuelei at openjdk.java.net Wed Apr 27 07:17:44 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 07:17:44 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v8] In-Reply-To: <_KLCUQopmdBH44wO7gCClBxx9pxF-zXOxFZNaYfmpAM=.e0bbb2ee-3567-4070-88e8-e44906c357bd@github.com> References: <7Jy22QmwpD3r_KKh09qZJ-gDNE2HvrpqNFiyfo1rsiU=.e3b45b02-b866-4e37-a332-17addb5c2bf5@github.com> <_KLCUQopmdBH44wO7gCClBxx9pxF-zXOxFZNaYfmpAM=.e0bbb2ee-3567-4070-88e8-e44906c357bd@github.com> Message-ID: On Wed, 27 Apr 2022 07:11:16 GMT, Xue-Lei Andrew Fan wrote: > Can you try out this test? Awesome! Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From xuelei at openjdk.java.net Wed Apr 27 07:48:44 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 07:48:44 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v10] 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: Correct test failure ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8136/files - new: https://git.openjdk.java.net/jdk/pull/8136/files/32e0a469..dbbb5d53 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=08-09 Stats: 12 lines in 1 file changed: 9 ins; 0 del; 3 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 volker.simonis at gmail.com Wed Apr 27 07:59:35 2022 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Apr 2022 09:59:35 +0200 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: 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 dfuchs at openjdk.java.net Wed Apr 27 10:59:43 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 27 Apr 2022 10:59:43 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. Hi Joe, just two suggestions about the javax.management changes. Otherwise looks good! src/java.management/share/classes/javax/management/openmbean/ArrayType.java line 96: > 94: * > 95: * @param the Java type that instances described by this type must > 96: * have. Instead of "instances" - would it be more correct to say "array elements"? src/java.management/share/classes/javax/management/openmbean/SimpleType.java line 60: > 58: * @param the Java type that instances described by this type must > 59: * have. > 60: * I would suggest to say "that values described by this type"... ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From prappo at openjdk.java.net Wed Apr 27 11:13:27 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 27 Apr 2022 11:13:27 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. I note that many years ago you filed JDK-6327933, which I'm currently looking at. If implemented, many of the issues from this PR will be addressed automatically, including those in `java.util.concurrent`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From mullan at openjdk.java.net Wed Apr 27 12:26:43 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 27 Apr 2022 12:26:43 GMT Subject: RFR: 8225433: Clarify behavior of PKIXParameters.setRevocationEnabled when PKIXRevocationChecker is used In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 06:44:37 GMT, Xue-Lei Andrew Fan wrote: >> This change improves the specification for the case when a `PKIXRevocationChecker` is supplied as one of the `CertPathChecker` parameters. Specifically, it makes it more clear that a `PKIXRevocationChecker` overrides the default revocation checking mechanism of a PKIX service provider, and will be used to check revocation irrespective of the setting of the RevocationEnabled parameter. >> >> Will also file a CSR. > > src/java.base/share/classes/java/security/cert/PKIXParameters.java line 339: > >> 337: * #setCertPathCheckers setCertPathCheckers} methods). >> 338: *

>> 339: * However, if a {@code PKIXRevocationChecker} is passed in as a parameter > > The word "However" may be not necessary as the previous paragraph is ending with a substitute mechanism. This sentence could be a further explanation of the substitute mechanism. Yes, that's a fair point. I am going to change "However, if" to "Note that when". The reason is that I want to use some words to call special attention to this paragraph as the most important point of this is "it will be used to check revocation irrespective of the setting of the RevocationEnabled flag.", which the previous paragraphs did not explain. ------------- PR: https://git.openjdk.java.net/jdk/pull/8287 From mullan at openjdk.java.net Wed Apr 27 12:48:29 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 27 Apr 2022 12:48:29 GMT Subject: RFR: 8225433: Clarify behavior of PKIXParameters.setRevocationEnabled when PKIXRevocationChecker is used [v2] In-Reply-To: References: Message-ID: > This change improves the specification for the case when a `PKIXRevocationChecker` is supplied as one of the `CertPathChecker` parameters. Specifically, it makes it more clear that a `PKIXRevocationChecker` overrides the default revocation checking mechanism of a PKIX service provider, and will be used to check revocation irrespective of the setting of the RevocationEnabled parameter. > > Will also file a CSR. Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: Change wording of "However". ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8287/files - new: https://git.openjdk.java.net/jdk/pull/8287/files/36a0ff13..99ee66f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8287&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8287&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8287.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8287/head:pull/8287 PR: https://git.openjdk.java.net/jdk/pull/8287 From weijun at openjdk.java.net Wed Apr 27 13:00:41 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 27 Apr 2022 13:00:41 GMT Subject: RFR: 8285493: ECC calculation error In-Reply-To: References: Message-ID: <4Vt6zp832RNRPRBfmp82vxDgFUjytnzDNq2fyobEmhM=.2b09f226-6fe9-448f-96eb-6399a01a4286@github.com> On Wed, 27 Apr 2022 06:28:27 GMT, Xue-Lei Andrew Fan wrote: >> Only numbers from the same modular fields can be involved in arithmetic calculations. Add `assert` to guarantee this. >> >> Also, found one broken case and rewrote it. > > src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSAOperations.java line 261: > >> 259: IntegerModuloP result = p1.asAffine().getX(); >> 260: b2a(result, orderField, temp1); >> 261: return MessageDigest.isEqual(temp1, r); > > I did not get the point of this update. Is it the broken case you mentioned in the PR description? What's the issue of the original code? Here, `result`'s modulus is `field`, and `ri`'s is `orderField`. Therefore you cannot simply subtract one from the other. One new `assert` would fail. ------------- PR: https://git.openjdk.java.net/jdk/pull/8409 From mullan at openjdk.java.net Wed Apr 27 13:11:43 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 27 Apr 2022 13:11:43 GMT Subject: RFR: 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:55:29 GMT, Bradford Wetmore wrote: > Two new constant fields `MGF1ParameterSpec.SHA512_224` and `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293). > > This bug addresses this issue. src/java.base/share/classes/java/security/spec/MGF1ParameterSpec.java line 98: > 96: > 97: /** > 98: * The MGF1ParameterSpec which uses SHA-512/224 message digest Feel free to cover this as a separate issue, but I think these constant descriptions should end with a period. Also, I would say "... uses _a_ SHA-512/224 message digest." (change in italics). There is also some inconsistency in the constants, some put the digest algorithm in double-quotes while others don't - it would be good to be consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/8411 From hchao at openjdk.java.net Wed Apr 27 13:21:43 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 27 Apr 2022 13:21:43 GMT Subject: RFR: 8225433: Clarify behavior of PKIXParameters.setRevocationEnabled when PKIXRevocationChecker is used [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 12:48:29 GMT, Sean Mullan wrote: >> This change improves the specification for the case when a `PKIXRevocationChecker` is supplied as one of the `CertPathChecker` parameters. Specifically, it makes it more clear that a `PKIXRevocationChecker` overrides the default revocation checking mechanism of a PKIX service provider, and will be used to check revocation irrespective of the setting of the RevocationEnabled parameter. >> >> Will also file a CSR. > > Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: > > Change wording of "However". Marked as reviewed by hchao (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8287 From mullan at openjdk.java.net Wed Apr 27 13:56:44 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 27 Apr 2022 13:56:44 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v6] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 16:04:14 GMT, Xue-Lei Andrew Fan wrote: >> Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. >> >> The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > rename and split the test case test/jdk/javax/security/auth/callback/PasswordCallback/PasswordCleanup.java line 27: > 25: * @test > 26: * @bug 8284910 > 27: * @summary Buffer clean in PasswordCallback Make the summary more specific, ex: "Check that PasswordCallback.clearPassword() clears the password." test/jdk/javax/security/auth/callback/PasswordCallback/PasswordCleanup.java line 55: > 53: } > 54: > 55: // Check if the PasswordCallback object could be collected. Since you are already checking if the Cleaner works properly in the `CheckCleanerBound` test, I don't see a reason why you need to test that again. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From djelinski at openjdk.java.net Wed Apr 27 14:21:23 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 27 Apr 2022 14:21:23 GMT Subject: RFR: 8285696: AlgorithmConstraints:permits not throwing IllegalArgumentException when 'alg' is null Message-ID: Please review this follow up to #8349. As JCK pointed out, `permits` is supposed to throw IAE on null input. However, now that we're looking up the result in a `ConcurrentHashMap`, a `NullPointerException` is thrown. This patch restores the original behavior. Verified that the JCK test passes with this change. ------------- Commit messages: - Permits should throw IAE on null input Changes: https://git.openjdk.java.net/jdk/pull/8427/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8427&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285696 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8427.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8427/head:pull/8427 PR: https://git.openjdk.java.net/jdk/pull/8427 From weijun at openjdk.java.net Wed Apr 27 15:13:43 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 27 Apr 2022 15:13: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 Wed, 27 Apr 2022 00:35:49 GMT, Valerie Peng wrote: >> src/java.base/share/classes/java/security/Signature.java line 1015: >> >>> 1013: * parameters were not supplied and the underlying signature implementation >>> 1014: * can generate the parameter values, it will be returned. Otherwise, >>> 1015: * {@code null} is returned. >> >> If we cannot guarantee anything but just want to clarify. how about just say "The returned parameters is a combination of user-provided values, implementation default values, and/or random values used by the underlying signature implementation. It can also be {@code null} if there's none." >> >> I assume that if a value is necessary but user has not provided one, then there will be a default or a random one. > > I searched about "and/or" and it is said that "or" covers "and". So, "and/or" should just be "or". > > I am on the fence for requiring provider to generate default parameters (using provider-specific or random values). Could there be scenarios where users are required to supply parameters? > That aside, this javadoc is lastly updated by JDK-8243424. It seems that JDK's EdDSA signature impl has some interesting usage of AlgorithmParameterSpec which this javadoc has to cover/allow. RSASSA-PSS always requires a user-provided params. I think one thing we can guarantee is that the default/random values generated by the impl will never overwrite the user-provided ones, they will only be supplemented. Also, I think the real usage of this method is that the result -- after converting to a spec -- can be set on the verify side and the verification should succeed. I don't quite understand EdDSA. Looks like the params is not stored along with the signature in the algorithm identifier. I also haven't found different OIDs defined when prehash or context is used. How does the verifier know this kind of flavor settings? ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From xuelei at openjdk.java.net Wed Apr 27 15:16:44 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 15:16:44 GMT Subject: RFR: 8285493: ECC calculation error In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 21:02:49 GMT, Weijun Wang wrote: > Only numbers from the same modular fields can be involved in arithmetic calculations. Add `assert` to guarantee this. > > Also, found one broken case and rewrote it. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8409 From xuelei at openjdk.java.net Wed Apr 27 15:16:44 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 15:16:44 GMT Subject: RFR: 8285493: ECC calculation error In-Reply-To: <4Vt6zp832RNRPRBfmp82vxDgFUjytnzDNq2fyobEmhM=.2b09f226-6fe9-448f-96eb-6399a01a4286@github.com> References: <4Vt6zp832RNRPRBfmp82vxDgFUjytnzDNq2fyobEmhM=.2b09f226-6fe9-448f-96eb-6399a01a4286@github.com> Message-ID: On Wed, 27 Apr 2022 12:57:20 GMT, Weijun Wang wrote: >> src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSAOperations.java line 261: >> >>> 259: IntegerModuloP result = p1.asAffine().getX(); >>> 260: b2a(result, orderField, temp1); >>> 261: return MessageDigest.isEqual(temp1, r); >> >> I did not get the point of this update. Is it the broken case you mentioned in the PR description? What's the issue of the original code? > > Here, `result`'s modulus is `field`, and `ri`'s is `orderField`. Therefore you cannot simply subtract one from the other. One new `assert` would fail. Got it. It looks like a safe update. ------------- PR: https://git.openjdk.java.net/jdk/pull/8409 From duke at openjdk.java.net Wed Apr 27 15:25:59 2022 From: duke at openjdk.java.net (Mark Powers) Date: Wed, 27 Apr 2022 15:25:59 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: <2nQFWBChiu-GJzGPP6LoJ0sPKDltE36_rK8OsraLOcI=.3a6cab16-b816-4ba9-9db8-48ce32d298a9@github.com> On Tue, 26 Apr 2022 18:46:02 GMT, Bradford Wetmore wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> Alan Bateman comments > > src/java.base/share/classes/javax/net/ssl/SSLSessionBindingEvent.java line 37: > >> 35: * {@link SSLSession#putValue(String, Object)} >> 36: * or {@link SSLSession#removeValue(String)}, objects which >> 37: * implement the SSLSessionBindingListener will receive an > > If you're up for it, you could fix the missing `` or `@link` throughout this small file. Ignore otherwise. I'll ignore for now. Javadoc issues are already being tracked for javax.crypto with JDK-8284851. This bug could easily be expanded to include javax.net. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From xuelei at openjdk.java.net Wed Apr 27 15:29:42 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 15:29:42 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v7] In-Reply-To: References: Message-ID: > Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. > > The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Remove duplicated test case ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8272/files - new: https://git.openjdk.java.net/jdk/pull/8272/files/9d38fdd3..7acd0ca8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=05-06 Stats: 23 lines in 1 file changed: 0 ins; 22 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8272/head:pull/8272 PR: https://git.openjdk.java.net/jdk/pull/8272 From xuelei at openjdk.java.net Wed Apr 27 15:29:42 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 15:29:42 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v6] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 13:44:14 GMT, Sean Mullan wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> rename and split the test case > > test/jdk/javax/security/auth/callback/PasswordCallback/PasswordCleanup.java line 55: > >> 53: } >> 54: >> 55: // Check if the PasswordCallback object could be collected. > > Since you are already checking if the Cleaner works properly in the `CheckCleanerBound` test, I don't see a reason why you need to test that again. It's a fair point. Since the cleaner test is pretty slow, I'm going to remove that part in this test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From jpai at openjdk.java.net Wed Apr 27 15:40:44 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 27 Apr 2022 15:40:44 GMT Subject: RFR: 8285696: AlgorithmConstraints:permits not throwing IllegalArgumentException when 'alg' is null In-Reply-To: References: Message-ID: <-F_ba5IeIJ6GGQBrW0wDnSe64AHGxYcATIbPq-wWzto=.6cfd5868-d5a0-4295-bcdc-a88531325369@github.com> On Wed, 27 Apr 2022 14:03:15 GMT, Daniel Jeli?ski wrote: > Please review this follow up to #8349. > > As JCK pointed out, `permits` is supposed to throw IAE on null input. However, now that we're looking up the result in a `ConcurrentHashMap`, a `NullPointerException` is thrown. This patch restores the original behavior. > > Verified that the JCK test passes with this change. Marked as reviewed by jpai (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8427 From xuelei at openjdk.java.net Wed Apr 27 15:40:44 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 15:40:44 GMT Subject: RFR: 8285696: AlgorithmConstraints:permits not throwing IllegalArgumentException when 'alg' is null In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:03:15 GMT, Daniel Jeli?ski wrote: > Please review this follow up to #8349. > > As JCK pointed out, `permits` is supposed to throw IAE on null input. However, now that we're looking up the result in a `ConcurrentHashMap`, a `NullPointerException` is thrown. This patch restores the original behavior. > > Verified that the JCK test passes with this change. Maybe, the checking could be placed in permits() method (line 158-173) so that it follows the spec, and easier to check. ------------- PR: https://git.openjdk.java.net/jdk/pull/8427 From xuelei at openjdk.java.net Wed Apr 27 16:06:32 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 16:06:32 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v8] In-Reply-To: References: Message-ID: > Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. > > The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: remove trailing whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8272/files - new: https://git.openjdk.java.net/jdk/pull/8272/files/7acd0ca8..6b07617e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8272/head:pull/8272 PR: https://git.openjdk.java.net/jdk/pull/8272 From rriggs at openjdk.java.net Wed Apr 27 16:06:32 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 27 Apr 2022 16:06:32 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v8] In-Reply-To: References: Message-ID: <4JtEKRgU1ufwYVtVEkPeVh6l5D4WsJAWL7p0PKc08nA=.2c82c2b1-f2de-493f-9d37-d31b1d739fb7@github.com> On Wed, 27 Apr 2022 16:02:05 GMT, Xue-Lei Andrew Fan wrote: >> Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. >> >> The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > remove trailing whitespace test/jdk/javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java line 50: > 48: for (int i = 0; i < 10 && weakHashMap.size() != 0; i++) { > 49: System.gc(); > 50: Thread.sleep(100); You can drop this sleep to 10ms to cut the average test time. It might be interesting to know how many retries are typical. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From djelinski at openjdk.java.net Wed Apr 27 16:16:18 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 27 Apr 2022 16:16:18 GMT Subject: RFR: 8285696: AlgorithmConstraints:permits not throwing IllegalArgumentException when 'alg' is null [v2] In-Reply-To: References: Message-ID: > Please review this follow up to #8349. > > As JCK pointed out, `permits` is supposed to throw IAE on null input. However, now that we're looking up the result in a `ConcurrentHashMap`, a `NullPointerException` is thrown. This patch restores the original behavior. > > Verified that the JCK test passes with this change. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Move check to permits method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8427/files - new: https://git.openjdk.java.net/jdk/pull/8427/files/35361a31..6eb0d50e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8427&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8427&range=00-01 Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8427.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8427/head:pull/8427 PR: https://git.openjdk.java.net/jdk/pull/8427 From djelinski at openjdk.java.net Wed Apr 27 16:16:19 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 27 Apr 2022 16:16:19 GMT Subject: RFR: 8285696: AlgorithmConstraints:permits not throwing IllegalArgumentException when 'alg' is null [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 15:37:27 GMT, Xue-Lei Andrew Fan wrote: > Maybe, the checking could be placed in permits() method (line 158-173) so that it follows the spec, and easier to check. Good point! ------------- PR: https://git.openjdk.java.net/jdk/pull/8427 From xuelei at openjdk.java.net Wed Apr 27 16:22:38 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 16:22:38 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v9] In-Reply-To: References: Message-ID: > Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. > > The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: no sleep for waiting cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8272/files - new: https://git.openjdk.java.net/jdk/pull/8272/files/6b07617e..fe4698a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8272&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8272/head:pull/8272 PR: https://git.openjdk.java.net/jdk/pull/8272 From xuelei at openjdk.java.net Wed Apr 27 16:22:42 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 16:22:42 GMT Subject: RFR: 8285696: AlgorithmConstraints:permits not throwing IllegalArgumentException when 'alg' is null [v2] In-Reply-To: References: Message-ID: <_OcSzyYpp9QP6nxANv-pLbbEJJWugvvwjclo2kLIrXM=.bbb61f22-bb38-4a48-bc59-d036dcb8654f@github.com> On Wed, 27 Apr 2022 16:16:18 GMT, Daniel Jeli?ski wrote: >> Please review this follow up to #8349. >> >> As JCK pointed out, `permits` is supposed to throw IAE on null input. However, now that we're looking up the result in a `ConcurrentHashMap`, a `NullPointerException` is thrown. This patch restores the original behavior. >> >> Verified that the JCK test passes with this change. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Move check to permits method Looks good to me. Thanks! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8427 From xuelei at openjdk.java.net Wed Apr 27 16:22:39 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 16:22:39 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v8] In-Reply-To: <4JtEKRgU1ufwYVtVEkPeVh6l5D4WsJAWL7p0PKc08nA=.2c82c2b1-f2de-493f-9d37-d31b1d739fb7@github.com> References: <4JtEKRgU1ufwYVtVEkPeVh6l5D4WsJAWL7p0PKc08nA=.2c82c2b1-f2de-493f-9d37-d31b1d739fb7@github.com> Message-ID: On Wed, 27 Apr 2022 16:02:04 GMT, Roger Riggs wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> remove trailing whitespace > > test/jdk/javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java line 50: > >> 48: for (int i = 0; i < 10 && weakHashMap.size() != 0; i++) { >> 49: System.gc(); >> 50: Thread.sleep(100); > > You can drop this sleep to 10ms to cut the average test time. It might be interesting to know how many retries are typical. Hm, it looks like a good idea to improve the testing performance (code updated). The cleaner get called in the 1st GC collection on my local laptop. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From wetmore at openjdk.java.net Wed Apr 27 16:46:44 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 27 Apr 2022 16:46:44 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: <2nQFWBChiu-GJzGPP6LoJ0sPKDltE36_rK8OsraLOcI=.3a6cab16-b816-4ba9-9db8-48ce32d298a9@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <2nQFWBChiu-GJzGPP6LoJ0sPKDltE36_rK8OsraLOcI=.3a6cab16-b816-4ba9-9db8-48ce32d298a9@github.com> Message-ID: On Wed, 27 Apr 2022 15:22:08 GMT, Mark Powers wrote: >> src/java.base/share/classes/javax/net/ssl/SSLSessionBindingEvent.java line 37: >> >>> 35: * {@link SSLSession#putValue(String, Object)} >>> 36: * or {@link SSLSession#removeValue(String)}, objects which >>> 37: * implement the SSLSessionBindingListener will receive an >> >> If you're up for it, you could fix the missing `` or `@link` throughout this small file. Ignore otherwise. > > I'll ignore for now. Javadoc issues are already being tracked for javax.crypto with JDK-8284851. This bug could easily be expanded to include javax.net. Ok. I'm going to do a little surgery in a java.security this morning, but JDK-8284851 could probably be expanded to address both the JCA/JCE code. (java/security, javax/crypto). ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From duke at openjdk.java.net Wed Apr 27 16:53:43 2022 From: duke at openjdk.java.net (Mark Powers) Date: Wed, 27 Apr 2022 16:53:43 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: <6DEFUs_-0PDbYcjWfy-bMr0b8h-o6w9IUY__JzVWugI=.457626e6-daf1-4305-844c-becb861ef777@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <6DEFUs_-0PDbYcjWfy-bMr0b8h-o6w9IUY__JzVWugI=.457626e6-daf1-4305-844c-becb861ef777@github.com> Message-ID: On Tue, 26 Apr 2022 19:08:50 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> Alan Bateman comments > > src/java.base/share/classes/javax/net/ssl/SSLSocketFactory.java line 96: > >> 94: s = s.trim(); >> 95: if (s.isEmpty()) { >> 96: s = null; > > According to the implementation of `Security::getProperty`. The return value is already trimmed. Removed those lines. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From wetmore at openjdk.java.net Wed Apr 27 17:08:31 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 27 Apr 2022 17:08:31 GMT Subject: RFR: 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields [v2] In-Reply-To: References: Message-ID: > Two new constant fields `MGF1ParameterSpec.SHA512_224` and `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293). > > This bug addresses this issue. Bradford Wetmore has updated the pull request incrementally with two additional commits since the last revision: - Minor IJ suggestion cleanup. - Addressed codereview comments on javadoc style. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8411/files - new: https://git.openjdk.java.net/jdk/pull/8411/files/8f3981c1..e79b5d87 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8411&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8411&range=00-01 Stats: 17 lines in 1 file changed: 5 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/8411.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8411/head:pull/8411 PR: https://git.openjdk.java.net/jdk/pull/8411 From wetmore at openjdk.java.net Wed Apr 27 17:10:28 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 27 Apr 2022 17:10:28 GMT Subject: RFR: 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields [v3] In-Reply-To: References: Message-ID: <2fzPE1MMaFlEJ-aSIcgrXKwuEFa-jf6YcJP2yWxq8Hw=.de70e138-d86f-45c2-a638-4265fcd2dbd6@github.com> > Two new constant fields `MGF1ParameterSpec.SHA512_224` and `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293). > > This bug addresses this issue. Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Missed one minor codereview suggestion. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8411/files - new: https://git.openjdk.java.net/jdk/pull/8411/files/e79b5d87..00edca0d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8411&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8411&range=01-02 Stats: 16 lines in 1 file changed: 5 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8411.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8411/head:pull/8411 PR: https://git.openjdk.java.net/jdk/pull/8411 From wetmore at openjdk.java.net Wed Apr 27 17:12:30 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 27 Apr 2022 17:12:30 GMT Subject: RFR: 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields [v3] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 13:08:03 GMT, Sean Mullan wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Missed one minor codereview suggestion. > > src/java.base/share/classes/java/security/spec/MGF1ParameterSpec.java line 98: > >> 96: >> 97: /** >> 98: * The MGF1ParameterSpec which uses SHA-512/224 message digest > > Feel free to cover this as a separate issue, but I think these constant descriptions should end with a period. Also, I would say "... uses _a_ SHA-512/224 message digest." (change in italics). There is also some inconsistency in the constants, some put the digest algorithm in double-quotes while others don't - it would be good to be consistent. Updated for consistency. ------------- PR: https://git.openjdk.java.net/jdk/pull/8411 From rhalade at openjdk.java.net Wed Apr 27 17:18:46 2022 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 27 Apr 2022 17:18:46 GMT Subject: RFR: 8285493: ECC calculation error In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 21:02:49 GMT, Weijun Wang wrote: > Only numbers from the same modular fields can be involved in arithmetic calculations. Add `assert` to guarantee this. > > Also, found one broken case and rewrote it. Please update bug with applicable noreg label. ------------- PR: https://git.openjdk.java.net/jdk/pull/8409 From weijun at openjdk.java.net Wed Apr 27 17:29:51 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 27 Apr 2022 17:29:51 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v10] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 07:48:44 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: > > Correct test failure I see you are still using the 1st version of the `Cleaners.java` test which runs on Windows. Please update to the current version (I've updated the code in place). ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From mbalao at redhat.com Wed Apr 27 17:37:33 2022 From: mbalao at redhat.com (Martin Balao) Date: Wed, 27 Apr 2022 13:37:33 -0400 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: David, I understand the reasons behind seeing authorization checks at the runtime layer as something that just adds, without any harm in the worst case (all of this putting the maintenance cost and other arguments aside.) My concern is more about the general security principles underpinning the idea. We will probably agree that half-barriers are not barriers, and might cause a false sense of security. If we have authorization checks at the runtime level, they must be comprehensive, coherent and well-maintained. Their availability suggests that mixing high-level checks with runtime-level ones can be part of a good security design in modern application development. For the reasons that we've been discussing, I'm not convinced of that. And even when subtle, I prefer the runtime not to make the suggestion. If you still want it, you can go ahead with instrumentation; but it's clear that for the runtime developers that is a workaround and not a desirable security design. What I mean by splitting responsibility is that application developers can use a mix of high and low level checks, at different layers, with more complexity. As Sean said, letting the unauthorized user to move towards the edge of the action is more risky. We can lose sight of workarounds and holes with the additional attack surface and complexity that comes at a lower layer. What I want to stress is the value of clarity, simplicity and division of responsibilities as a general security principle. Martin.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mullan at openjdk.java.net Wed Apr 27 18:47:05 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 27 Apr 2022 18:47:05 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v9] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 16:22:38 GMT, Xue-Lei Andrew Fan wrote: >> Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. >> >> The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > no sleep for waiting cleanup Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From mullan at openjdk.java.net Wed Apr 27 18:53:43 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 27 Apr 2022 18:53:43 GMT Subject: RFR: 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields [v3] In-Reply-To: <2fzPE1MMaFlEJ-aSIcgrXKwuEFa-jf6YcJP2yWxq8Hw=.de70e138-d86f-45c2-a638-4265fcd2dbd6@github.com> References: <2fzPE1MMaFlEJ-aSIcgrXKwuEFa-jf6YcJP2yWxq8Hw=.de70e138-d86f-45c2-a638-4265fcd2dbd6@github.com> Message-ID: <8cgm_u-kP-23f2WJmoR88Lix1IS-IEFTY0G42gXC6yE=.bb0fb14f-a251-4571-9e22-a398bfd6f22f@github.com> On Wed, 27 Apr 2022 17:10:28 GMT, Bradford Wetmore wrote: >> Two new constant fields `MGF1ParameterSpec.SHA512_224` and `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293). >> >> This bug addresses this issue. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Missed one minor codereview suggestion. Marked as reviewed by mullan (Reviewer). src/java.base/share/classes/java/security/spec/MGF1ParameterSpec.java line 68: > 66: > 67: /** > 68: * The MGF1ParameterSpec which uses a "SHA-1" message digest. Nit, use `{@code}` instead of ``. Otherwise, looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/8411 From duke at openjdk.java.net Wed Apr 27 19:16:45 2022 From: duke at openjdk.java.net (Mark Powers) Date: Wed, 27 Apr 2022 19:16:45 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <6DEFUs_-0PDbYcjWfy-bMr0b8h-o6w9IUY__JzVWugI=.457626e6-daf1-4305-844c-becb861ef777@github.com> <_xKqXJpVgw9hYRf9VG1n2KKu74Py5BGpatA20GM5xxc=.d63a97a7-aec1-4e22-92d3-18061ac4ab12@github.com> Message-ID: On Tue, 26 Apr 2022 22:08:42 GMT, Weijun Wang wrote: >> Perhaps as part of [JDK-6725221](https://bugs.openjdk.java.net/browse/JDK-6725221)? > > No problem. JDK-6725221 is about obtaining boolean properties, so not an exact match. The suggested change is so easy, I'm going to do it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From duke at openjdk.java.net Wed Apr 27 19:16:46 2022 From: duke at openjdk.java.net (Mark Powers) Date: Wed, 27 Apr 2022 19:16:46 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: <6DEFUs_-0PDbYcjWfy-bMr0b8h-o6w9IUY__JzVWugI=.457626e6-daf1-4305-844c-becb861ef777@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <6DEFUs_-0PDbYcjWfy-bMr0b8h-o6w9IUY__JzVWugI=.457626e6-daf1-4305-844c-becb861ef777@github.com> Message-ID: <7h8mYltsGlLpGhAgwN_nVJYzTgEwlUCzQY-KwS7hVjw=.bf5ee348-8add-44be-81bb-238f32ce7c36@github.com> On Tue, 26 Apr 2022 19:09:46 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> Alan Bateman comments > > src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java line 81: > >> 79: String type; >> 80: type = AccessController.doPrivileged((PrivilegedAction) () -> >> 81: Security.getProperty( "ssl.TrustManagerFactory.algorithm")); > > Another `GetPropertyAction::privilegedGetProperty` candidate. Making the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From mullan at openjdk.java.net Wed Apr 27 19:19:59 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 27 Apr 2022 19:19:59 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms In-Reply-To: References: Message-ID: <0hTMKCJjfuWzcVuVGHsrcTeyly3NkAojQvWAHBQKbcs=.c72451eb-a98d-4f7c-b6c6-31a0dc5b3c8b@github.com> 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. src/java.base/share/conf/security/java.security line 657: > 655: # implementations. > 656: > 657: jdk.security.legacyAlgorithms=SHA1, \ Since we are now warning about weak symmetric key algorithms, we should make the description of this property more general. I would change lines 641-2 to "Legacy cryptographic algorithms and key lengths". src/java.base/share/conf/security/java.security line 657: > 655: # implementations. > 656: > 657: jdk.security.legacyAlgorithms=SHA1, \ Since we are now warning about weak symmetric key algorithms, we should make the description of this property more general. I would change lines 641-2 to "Legacy cryptographic algorithms and key lengths". ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From weijun at openjdk.java.net Wed Apr 27 19:32:39 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 27 Apr 2022 19:32:39 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 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 The CSR looks fine. It's not necessary to attach a patch there. At least don't name it `specdiff` because it's not about spec. BTW, how do you think of the names proposed in https://github.com/openjdk/jdk/pull/8211#issuecomment-1099925744? ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Wed Apr 27 19:36:42 2022 From: duke at openjdk.java.net (Mat Carter) Date: Wed, 27 Apr 2022 19:36:42 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider In-Reply-To: <08kPGJRnG_Evtq3WCMH6nssW4Otk7AvaDHGWpTnBE1k=.e372fba4-2d0a-424d-975a-03335e0b1e34@github.com> References: <08kPGJRnG_Evtq3WCMH6nssW4Otk7AvaDHGWpTnBE1k=.e372fba4-2d0a-424d-975a-03335e0b1e34@github.com> Message-ID: On Wed, 27 Apr 2022 02:33:24 GMT, Bernd wrote: >> src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 419: >> >>> 417: __leave; >>> 418: } >>> 419: if ((pszCertStoreLocation = env->GetStringUTFChars(jCertStoreLocation, NULL)) >> >> Would it be easier to use a int argument here, it?s a internal api with only two enumerated Types. That safes the jstring conversion and the Strcmp. > > And also, is there a ReleaseString missing? Thanks for the feedback, I'm going to incorporate that into the PR ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From weijun at openjdk.java.net Wed Apr 27 19:36:43 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 27 Apr 2022 19:36:43 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 02:26:48 GMT, Bernd 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 > > src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 487: > >> 485: // Check if private key available - client authentication certificate >> 486: // must have private key available. >> 487: HCRYPTPROV_OR_NCRYPT_KEY_HANDLE hCryptProv = NULL; > > It is not quite clear from the CSR, was this a bug (previous JDK-8026953 incomplete) or is that only a type cleanup and using ncrypt keys worked before? (In that Case does it need to be mentioned in csr?) Same question. Does a new type name automagically add support for CNG? ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From mullan at openjdk.java.net Wed Apr 27 19:38:40 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 27 Apr 2022 19:38:40 GMT Subject: RFR: 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. Changes requested by mullan (Reviewer). src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1876: > 1874: > 1875: CertPathConstraintsParameters cpcp = > 1876: new CertPathConstraintsParameters(secKey, null, null, null); Using `CertPathConstraintsParameters` is a little odd here, even though it works. I suggest creating a local `SecretKeyConstraintsParameters` subclass with a ctor with just the parameters you need and overriding the methods as needed. And changing `checkWeakConstraint` to take a `ConstraintsParameters` instead of `CertPathConstraintsParameters`. src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1876: > 1874: > 1875: CertPathConstraintsParameters cpcp = > 1876: new CertPathConstraintsParameters(secKey, null, null, null); Using `CertPathConstraintsParameters` is a little odd here, even though it works. I suggest creating a local `SecretKeyConstraintsParameters` subclass with a ctor with just the parameters you need and overriding the methods as needed. And changing `checkWeakConstraints` to take a `ConstraintsParameters` instead of `CertPathConstraintsParameters`. test/jdk/sun/security/tools/keytool/ReadJar.java line 162: > 160: .shouldContain("Certificate #2:") > 161: .shouldContain("Signer #2:") > 162: .shouldNotMatch("The certificate #.* of signer #.*" + "uses the SHA1withRSA.*will be disabled") You probably don't need to check for a non-occurrence here since the message has been changed and can no longer occur. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From valeriep at openjdk.java.net Wed Apr 27 19:51:44 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 27 Apr 2022 19:51:44 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 19:26:41 GMT, Sean Mullan wrote: >> I have filed the PR for the Signature at: https://github.com/openjdk/jdk/pull/8396 >> Best to get it done along with this one. > >> As for the 2nd sentence, it boils down whether we requires provider to generate default parameters and return it when parameter is required. Existing javadoc states that null is returned when parameter is not required. Given Cipher covers many algorithms, if a provider does not want to generate a default parameter when parameter is required, it can't return null when getParameters() is called. > > Ok, maybe we need to reset the context. What was the main issue with the current specification that you were trying to fix? I read the associated bug report. It sounds like there were two issues: > > - ProviderException can be thrown, but the method does not declare it in the throws clause. That doesn't seem to be addressed here - do you think it should be? > - cases when null may be returned as opposed to throwing a ProviderException > > It could be that what is really just needed is an @throws ProviderException, ex: > > "If this cipher implementation requires algorithm parameters to be passed in at initialization but was not initialized with any". > > and a slight tweak to the description (changes in italics): > > "... if this cipher _can generate required_ algorithm parameters but was not initialized with any." I don't see the ProviderException being mentioned? Per the description under JDK-8209038, the requests are: 1) describe the returned parameters following what's in Signature class, i.e. if this object has been initialized with parameters then ..., if this object has not been initialized with parameters, then ..... (<= Xuelei raises compatibility concern and trying to describe all this would make it very lengthy, so the proposed changes reverted back to the original syntax, e.g. describing the returned parameters but not including the scenarios) 2) allow null to be returned if providers cannot generate default parameters. (<= this is addressed in the proposed changes) 3) accommodate algorithm-specific/provider-specific implementation on how parameters is handled. (<= this is addressed in the proposed changes as well. However, this part in Signature class needs update since it states the the SAME parameters are returned but AlgorithmParameterSpec may not require all parameter values to be specified.) ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From mullan at openjdk.java.net Wed Apr 27 20:04:42 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 27 Apr 2022 20:04:42 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 19:48:01 GMT, Valerie Peng wrote: >>> As for the 2nd sentence, it boils down whether we requires provider to generate default parameters and return it when parameter is required. Existing javadoc states that null is returned when parameter is not required. Given Cipher covers many algorithms, if a provider does not want to generate a default parameter when parameter is required, it can't return null when getParameters() is called. >> >> Ok, maybe we need to reset the context. What was the main issue with the current specification that you were trying to fix? I read the associated bug report. It sounds like there were two issues: >> >> - ProviderException can be thrown, but the method does not declare it in the throws clause. That doesn't seem to be addressed here - do you think it should be? >> - cases when null may be returned as opposed to throwing a ProviderException >> >> It could be that what is really just needed is an @throws ProviderException, ex: >> >> "If this cipher implementation requires algorithm parameters to be passed in at initialization but was not initialized with any". >> >> and a slight tweak to the description (changes in italics): >> >> "... if this cipher _can generate required_ algorithm parameters but was not initialized with any." > > I don't see the ProviderException being mentioned? > Per the description under JDK-8209038, the requests are: > 1) describe the returned parameters following what's in Signature class, i.e. if this object has been initialized with parameters then ..., if this object has not been initialized with parameters, then ..... (<= Xuelei raises compatibility concern and trying to describe all this would make it very lengthy, so the proposed changes reverted back to the original syntax, e.g. describing the returned parameters but not including the scenarios) > 2) allow null to be returned if providers cannot generate default parameters. (<= this is addressed in the proposed changes) > 3) accommodate algorithm-specific/provider-specific implementation on how parameters is handled. (<= this is addressed in the proposed changes as well. However, this part in Signature class needs update since it states the the SAME parameters are returned but AlgorithmParameterSpec may not require all parameter values to be specified.) Sorry, I should have been more specific. JDK-8209038 references JDK-8206171 which I think was filed by the TCK team. In that bug description, it says: > This bug is filed for clarification of specification (see comment) > Please clarify the specification to include a possible exception being thrown (ProviderException for RSASSA-PSS) or other possible exceptions for future Signature algorithms that require mandatory parameters by the user before any operations could be performed, and user did not set any parameters before using the Signature operations (sign, update, verify). > Or > null could be returned (as per specification) I assumed the `ProviderException` case could potentially apply to a `Cipher` algorithm as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From duke at openjdk.java.net Wed Apr 27 20:25:39 2022 From: duke at openjdk.java.net (Mark Powers) Date: Wed, 27 Apr 2022 20:25:39 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <6DEFUs_-0PDbYcjWfy-bMr0b8h-o6w9IUY__JzVWugI=.457626e6-daf1-4305-844c-becb861ef777@github.com> <_xKqXJpVgw9hYRf9VG1n2KKu74Py5BGpatA20GM5xxc=.d63a97a7-aec1-4e22-92d3-18061ac4ab12@github.com> Message-ID: <_YwQOsVyKgKab9SSmOqN3nySXG7tQuyaA6x2LZrvjHs=.9737e68e-06f5-4e0d-9816-f15d683685dc@github.com> On Wed, 27 Apr 2022 19:12:37 GMT, Mark Powers wrote: >> No problem. > > JDK-6725221 is about obtaining boolean properties, so not an exact match. The suggested change is so easy, I'm going to do it. sun.security.action.GetPropertyAction::privilegedGetProperty doesn't trim the return value. Could this be a problem? ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From weijun at openjdk.java.net Wed Apr 27 21:08:43 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 27 Apr 2022 21:08:43 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 19:35:04 GMT, Sean Mullan 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. > > 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? ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From xuelei at openjdk.java.net Wed Apr 27 21:24:43 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 21:24:43 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v11] In-Reply-To: References: Message-ID: <-OJP7zoU6S4wHInqibqZNh_mtOCzER36wIwHOY_vOJE=.1656b096-a556-49fc-9763-e5ac6fb838de@github.com> > 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: renew the Cleaners.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8136/files - new: https://git.openjdk.java.net/jdk/pull/8136/files/dbbb5d53..35599747 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=09-10 Stats: 10 lines in 1 file changed: 2 ins; 3 del; 5 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 xuelei at openjdk.java.net Wed Apr 27 21:24:43 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 27 Apr 2022 21:24:43 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v10] In-Reply-To: References: Message-ID: <2YoLkXvtvqRFoPWRpltWezJKXZLmaeMq-SON29BTq4Y=.e7ad08df-a083-4569-8ab8-b7ae3eb4764f@github.com> On Wed, 27 Apr 2022 17:25:52 GMT, Weijun Wang wrote: > I see you are still using the 1st version of the `Cleaners.java` test which runs on Windows. Please update to the current version (I've updated the code in place). Oops, I missed it. Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From wetmore at openjdk.java.net Wed Apr 27 21:33:24 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 27 Apr 2022 21:33:24 GMT Subject: RFR: 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields [v4] In-Reply-To: References: Message-ID: <-KuFZQ4h5iGn9wuUgXlUvZM8oMsARUbm28M_ITAAWnc=.576808b9-d06a-445c-9c1b-1384c78a586f@github.com> > Two new constant fields `MGF1ParameterSpec.SHA512_224` and `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293). > > This bug addresses this issue. Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Use @ code tags instead of raw HTML ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8411/files - new: https://git.openjdk.java.net/jdk/pull/8411/files/00edca0d..e733085f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8411&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8411&range=02-03 Stats: 17 lines in 1 file changed: 0 ins; 6 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8411.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8411/head:pull/8411 PR: https://git.openjdk.java.net/jdk/pull/8411 From duke at openjdk.java.net Wed Apr 27 21:44:55 2022 From: duke at openjdk.java.net (Mat Carter) Date: Wed, 27 Apr 2022 21:44:55 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 19:33:10 GMT, Weijun Wang wrote: >> src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 487: >> >>> 485: // Check if private key available - client authentication certificate >>> 486: // must have private key available. >>> 487: HCRYPTPROV_OR_NCRYPT_KEY_HANDLE hCryptProv = NULL; >> >> It is not quite clear from the CSR, was this a bug (previous JDK-8026953 incomplete) or is that only a type cleanup and using ncrypt keys worked before? (In that Case does it need to be mentioned in csr?) > > 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, 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 ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From duke at openjdk.java.net Wed Apr 27 21:50:46 2022 From: duke at openjdk.java.net (Mat Carter) Date: Wed, 27 Apr 2022 21:50:46 GMT Subject: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider In-Reply-To: References: <08kPGJRnG_Evtq3WCMH6nssW4Otk7AvaDHGWpTnBE1k=.e372fba4-2d0a-424d-975a-03335e0b1e34@github.com> Message-ID: On Wed, 27 Apr 2022 19:33:37 GMT, Mat Carter wrote: >> And also, is there a ReleaseString missing? > > 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 :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8211 From valeriep at openjdk.java.net Wed Apr 27 22:57:45 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 27 Apr 2022 22:57:45 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 Wed, 27 Apr 2022 15:10:42 GMT, Weijun Wang wrote: >> I searched about "and/or" and it is said that "or" covers "and". So, "and/or" should just be "or". >> >> I am on the fence for requiring provider to generate default parameters (using provider-specific or random values). Could there be scenarios where users are required to supply parameters? >> That aside, this javadoc is lastly updated by JDK-8243424. It seems that JDK's EdDSA signature impl has some interesting usage of AlgorithmParameterSpec which this javadoc has to cover/allow. > > RSASSA-PSS always requires a user-provided params. > > I think one thing we can guarantee is that the default/random values generated by the impl will never overwrite the user-provided ones, they will only be supplemented. Also, I think the real usage of this method is that the result -- after converting to a spec -- can be set on the verify side and the verification should succeed. > > I don't quite understand EdDSA. Looks like the params is not stored along with the signature in the algorithm identifier. I also haven't found different OIDs defined when prehash or context is used. How does the verifier know this kind of flavor settings? Right, the user-supplied values takes precedence and provider-specific default/random values should just be supplemental. As for EdDSA, looks like the prehash and context are only in RFC 8032 and NOT RFC 8410. caller has to pass these settings/values to the other entity through some other means since the getParameters() return null as there is no ASN.1 definition for the parameters. Looks like these values are packaged into a parameter spec and passed into the underlying EdDSA signature implementation in order to fit into existing API without adding new algorithm specific APIs. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From weijun at openjdk.java.net Wed Apr 27 23:00:44 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 27 Apr 2022 23:00:44 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v11] In-Reply-To: <-OJP7zoU6S4wHInqibqZNh_mtOCzER36wIwHOY_vOJE=.1656b096-a556-49fc-9763-e5ac6fb838de@github.com> References: <-OJP7zoU6S4wHInqibqZNh_mtOCzER36wIwHOY_vOJE=.1656b096-a556-49fc-9763-e5ac6fb838de@github.com> Message-ID: <8Bj4fnJTqicTJB2NtfkzdOlhfZl8vOhhEJrbh9Qkm04=.2274778f-375d-47be-9df7-e4920549e198@github.com> On Wed, 27 Apr 2022 21:24:43 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: > > renew the Cleaners.java Oops, one test failed. The test output shows native bridge is not used. Since the new tests are setting system properties, please change them to use `othervm`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From weijun at openjdk.java.net Wed Apr 27 23:05:45 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 27 Apr 2022 23:05:45 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 Wed, 27 Apr 2022 22:54:47 GMT, Valerie Peng wrote: >> RSASSA-PSS always requires a user-provided params. >> >> I think one thing we can guarantee is that the default/random values generated by the impl will never overwrite the user-provided ones, they will only be supplemented. Also, I think the real usage of this method is that the result -- after converting to a spec -- can be set on the verify side and the verification should succeed. >> >> I don't quite understand EdDSA. Looks like the params is not stored along with the signature in the algorithm identifier. I also haven't found different OIDs defined when prehash or context is used. How does the verifier know this kind of flavor settings? > > Right, the user-supplied values takes precedence and provider-specific default/random values should just be supplemental. > > As for EdDSA, looks like the prehash and context are only in RFC 8032 and NOT RFC 8410. caller has to pass these settings/values to the other entity through some other means since the getParameters() return null as there is no ASN.1 definition for the parameters. Looks like these values are packaged into a parameter spec and passed into the underlying EdDSA signature implementation in order to fit into existing API without adding new algorithm specific APIs. So, "the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}" is quite necessary. Xuelei's suggestion is quite good, just change the last "and" to "or". ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From ascarpino at openjdk.java.net Wed Apr 27 23:07:51 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 27 Apr 2022 23:07:51 GMT Subject: RFR: 8285493: ECC calculation error In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 21:02:49 GMT, Weijun Wang wrote: > Only numbers from the same modular fields can be involved in arithmetic calculations. Add `assert` to guarantee this. > > Also, found one broken case and rewrote it. Changes look good ------------- Marked as reviewed by ascarpino (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8409 From darcy at openjdk.java.net Wed Apr 27 23:10:43 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 27 Apr 2022 23:10:43 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 01:39:27 GMT, Stuart Marks wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > src/java.base/share/classes/java/util/AbstractMap.java line 601: > >> 599: * {@code Map.entrySet().toArray}. >> 600: * >> 601: * @param the type of keys maintained > > Please update to match java.util.Map, which says "the type of keys maintained by this map" I said "keys maintained", omitting "by this map" to finesse the question of if the SimpleEntry class *is* a map, or is used to implement a map, etc. I can change it to include "by this map" if the map/entry distinction is okay to be blurred. > src/java.base/share/classes/java/util/Dictionary.java line 44: > >> 42: * @param the type of keys >> 43: * @param the type of mapped values >> 44: * > > Urgh. This class is obsolete, but it was retrofitted to implement Map and was subsequently generified, so I'd update these to match java.util.Map. The javadoc of Dictionary states "The Dictionary class [...] maps keys to values." which was my guide for the wording, but I don't mind changing it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From darcy at openjdk.java.net Wed Apr 27 23:15:42 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 27 Apr 2022 23:15:42 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 10:54:00 GMT, Daniel Fuchs wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > src/java.management/share/classes/javax/management/openmbean/ArrayType.java line 96: > >> 94: * >> 95: * @param the Java type that instances described by this type must >> 96: * have. > > Instead of "instances" - would it be more correct to say "array elements"? Will change to "the Java component type that arrays described by ArrayType must have" ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From valeriep at openjdk.java.net Wed Apr 27 23:19:46 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 27 Apr 2022 23:19:46 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 05:25:42 GMT, Xue-Lei Andrew Fan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Undo un-intentional changes. > > src/java.base/share/classes/java/security/Signature.java line 1012: > >> 1010: * values used by the underlying signature implementation if the underlying >> 1011: * signature implementation supports returning the parameters as >> 1012: * {@code AlgorithmParameters}. If the required > > "... if the underlying signature implementation supports returning the parameters a {@code AlgorithmParameters}", it looks this part is duplicated and may be removed. I am not sure which part duplicates the text that you quoted? The original text only mentions the supplied values. The proposed changes add that there may be additional parameters. Are you saying that these additional parameters are "implied" by the part that you quoted? > What does it refer to with 'it'? Is 'it' refer to the implementation generated parameter values? 'It' refers to the parameters containing all of the parameter values including the supplied ones and provider-generated ones if any. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From darcy at openjdk.java.net Wed Apr 27 23:21:40 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 27 Apr 2022 23:21:40 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v2] In-Reply-To: References: Message-ID: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Respond to review feedback. - Merge branch 'master' into JDK-8285676 - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8410/files - new: https://git.openjdk.java.net/jdk/pull/8410/files/fe47dd2f..e0ac5dcb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=00-01 Stats: 5958 lines in 128 files changed: 4827 ins; 485 del; 646 mod Patch: https://git.openjdk.java.net/jdk/pull/8410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410 PR: https://git.openjdk.java.net/jdk/pull/8410 From darcy at openjdk.java.net Wed Apr 27 23:21:52 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 27 Apr 2022 23:21:52 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 10:55:22 GMT, Daniel Fuchs wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Respond to review feedback. >> - Merge branch 'master' into JDK-8285676 >> - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces > > src/java.management/share/classes/javax/management/openmbean/SimpleType.java line 60: > >> (failed to retrieve contents of file, check the PR for context) > I would suggest to say "that values described by this type"... Will change to "the Java type that values described by this SimpleType must have." ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From valeriep at openjdk.java.net Wed Apr 27 23:22:07 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 27 Apr 2022 23:22:07 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 23:15:41 GMT, Valerie Peng wrote: >> src/java.base/share/classes/java/security/Signature.java line 1014: >> >>> 1012: * {@code AlgorithmParameters}. If the required >>> 1013: * parameters were not supplied and the underlying signature implementation >>> 1014: * can generate the parameter values, it will be returned. Otherwise, >> >>> If the required parameters were not supplied and the underlying signature implementation can generate the parameter values, it will be returned. >> >> What does it refer to with 'it'? Is 'it' refer to the implementation generated parameter values? >> >>> If the required parameters were not supplied and the underlying signature implementation can generate the parameter values, it will be returned. Otherwise, {@code null} is returned. >> >> The logic looks like >> >> if (A & B) { >> // it will be returned >> } else { >> // {@code null} is returned. >> } >> >> If I read it correctly, the behavior may look like: >> 1. If the required parameters were supplied, {@code null} is returned; (if !A) >> 2. if the underlying signature implementation cannot generate the parameter values, {@code null} is returned; (if !B) >> 3. if not 1 and 2, ... (if A & B) >> >> It does not look like right. The expected behavior may be: >> >> if (A) { >> if (B) { >> // it will be returned >> } else { >> // {@code null} is returned. >> } >> } >> >> >> Maybe, the confusion could be mitigated by re-org the logic: >> >> if (A & !B) { >> // {@code null} is returned. >> } // Otherwise, refer to 1st sentence. >> >> >> "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} is returned if the required parameters were not supplied and the underlying signature implementation cannot generate the parameter values." >> >> Similar comment to [PR 8117](https://github.com/openjdk/jdk/pull/8117), if you want to use similar description there as well. > >> What does it refer to with 'it'? Is 'it' refer to the implementation generated parameter values? > > 'It' refers to the parameters containing all of the parameter values including the supplied ones and provider-generated ones if any. Can you clarify what is the A and B that you are referring to? The way I read it, it has more than 2 conditions... So, best to clarify the conditions first. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From smarks at openjdk.java.net Wed Apr 27 23:31:55 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 27 Apr 2022 23:31:55 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 23:04:47 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/util/AbstractMap.java line 601: >> >>> 599: * {@code Map.entrySet().toArray}. >>> 600: * >>> 601: * @param the type of keys maintained >> >> Please update to match java.util.Map, which says "the type of keys maintained by this map" > > I said "keys maintained", omitting "by this map" to finesse the question of if the SimpleEntry class *is* a map, or is used to implement a map, etc. I can change it to include "by this map" if the map/entry distinction is okay to be blurred. Whoops, sorry, this is `SimpleEntry`, which is _not_ a `Map`. In this case I'd follow `Map.Entry` which says "the type of the key" and "the type of the map". >> src/java.base/share/classes/java/util/Dictionary.java line 44: >> >>> 42: * @param the type of keys >>> 43: * @param the type of mapped values >>> 44: * >> >> Urgh. This class is obsolete, but it was retrofitted to implement Map and was subsequently generified, so I'd update these to match java.util.Map. > > The javadoc of Dictionary states "The Dictionary class [...] maps keys to values." which was my guide for the wording, but I don't mind changing it. My bad, `Dictionary` was not retrofitted to implement `Map` but it gained `K` and `V` type parameters to align with `Map`. No need to change this; it doesn't really matter. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From valeriep at openjdk.java.net Wed Apr 27 23:33:43 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 27 Apr 2022 23:33:43 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 23:19:56 GMT, Valerie Peng wrote: >>> What does it refer to with 'it'? Is 'it' refer to the implementation generated parameter values? >> >> 'It' refers to the parameters containing all of the parameter values including the supplied ones and provider-generated ones if any. > > Can you clarify what is the A and B that you are referring to? The way I read it, it has more than 2 conditions... So, best to clarify the conditions first. > I see your point with the wording suggestion at the end. Was a bit lost when trying to go through the various if-else logic and figure out what you mean... With Signature class, there is a caveat for EdDSA, the supplied parameters are set but null is being returned when getParameters() is called. This is currently covered by the condition `if the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}` as the underlying signature does not support AlgorithmParameters for the supplied EdDSAParameterSpec object due to lack of ASN.1 definition. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From valeriep at openjdk.java.net Wed Apr 27 23:38:43 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 27 Apr 2022 23:38:43 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 23:30:22 GMT, Valerie Peng wrote: >> Can you clarify what is the A and B that you are referring to? The way I read it, it has more than 2 conditions... So, best to clarify the conditions first. >> I see your point with the wording suggestion at the end. Was a bit lost when trying to go through the various if-else logic and figure out what you mean... > > With Signature class, there is a caveat for EdDSA, the supplied parameters are set but null is being returned when getParameters() is called. This is currently covered by the condition `if the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}` as the underlying signature does not support AlgorithmParameters for the supplied EdDSAParameterSpec object due to lack of ASN.1 definition. Besides this Signature-specific condition, there is the common condition where provider cannot (or do not) generate default parameter values. {@code null} is used as the catch-all result, but as you said, describe various conditions tersely and correctly is key. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From wetmore at openjdk.java.net Wed Apr 27 23:58:45 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 27 Apr 2022 23:58:45 GMT Subject: Integrated: 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:55:29 GMT, Bradford Wetmore wrote: > Two new constant fields `MGF1ParameterSpec.SHA512_224` and `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293). > > This bug addresses this issue. This pull request has now been integrated. Changeset: cf1b00a6 Author: Bradford Wetmore URL: https://git.openjdk.java.net/jdk/commit/cf1b00a60483c2c45b9465aa2bdb7072c92b7072 Stats: 21 lines in 1 file changed: 8 ins; 0 del; 13 mod 8285683: Missing @ since 11 in java.security.spec.MGF1ParameterSpec fields Reviewed-by: hchao, valeriep, xuelei, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/8411 From ecki at zusammenkunft.net Thu Apr 28 00:19:06 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 28 Apr 2022 00:19:06 +0000 Subject: [openjdk/jdk] JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider (PR #8211) In-Reply-To: References: Message-ID: Hello, > Correct, it does enable access to certificates and keys that require next (second) generation, That?s strange, I am quite sure I tried CNG RSA and EC Keys after OpenJDK claimed to support it. So maybe there is more than one condition to it (or the handle just works transparently regardless of its type?) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Mat Carter Gesendet: Wednesday, April 27, 2022 11:41:45 PM An: openjdk/jdk Cc: Bernd ; Comment Betreff: Re: [openjdk/jdk] JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider (PR #8211) @macarte commented on this pull request. ________________________________ In src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp: > @@ -469,7 +484,7 @@ JNIEXPORT void JNICALL Java_sun_security_mscapi_CKeyStore_loadKeysOrCertificateC PP("--------------------------"); // Check if private key available - client authentication certificate // must have private key available. - HCRYPTPROV hCryptProv = NULL; + HCRYPTPROV_OR_NCRYPT_KEY_HANDLE hCryptProv = NULL; Correct, it does enable access to certificates and keys that require next (second) generation, 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 ? Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.java.net Thu Apr 28 01:34:19 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Apr 2022 01:34:19 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3] In-Reply-To: References: Message-ID: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to more review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8410/files - new: https://git.openjdk.java.net/jdk/pull/8410/files/e0ac5dcb..db4919a9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410 PR: https://git.openjdk.java.net/jdk/pull/8410 From prr at openjdk.java.net Thu Apr 28 01:34:19 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 28 Apr 2022 01:34:19 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 01:31:13 GMT, Joe Darcy wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to more review feedback. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From darcy at openjdk.java.net Thu Apr 28 01:34:19 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Apr 2022 01:34:19 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 23:24:57 GMT, Stuart Marks wrote: >> I said "keys maintained", omitting "by this map" to finesse the question of if the SimpleEntry class *is* a map, or is used to implement a map, etc. I can change it to include "by this map" if the map/entry distinction is okay to be blurred. > > Whoops, sorry, this is `SimpleEntry`, which is _not_ a `Map`. In this case I'd follow `Map.Entry` which says "the type of the key" and "the type of the map". Will change to the Map.Entry wording "the type of key" and "the type of the value", respectively. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From duke at openjdk.java.net Thu Apr 28 02:33:49 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 28 Apr 2022 02:33:49 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v4] In-Reply-To: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8285504 > > 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/net Mark Powers 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 eight additional commits since the last revision: - Merge - Max and Brad comments - jaikiran comments - Alan Bateman comments - second iteration - Merge - Merge - first iteration ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8384/files - new: https://git.openjdk.java.net/jdk/pull/8384/files/7624f4a9..6997837f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8384&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8384&range=02-03 Stats: 12840 lines in 345 files changed: 9325 ins; 1407 del; 2108 mod Patch: https://git.openjdk.java.net/jdk/pull/8384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8384/head:pull/8384 PR: https://git.openjdk.java.net/jdk/pull/8384 From xuelei at openjdk.java.net Thu Apr 28 02:51:46 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Apr 2022 02:51:46 GMT Subject: Integrated: 8284910: Buffer clean in PasswordCallback In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 15:45:21 GMT, Xue-Lei Andrew Fan wrote: > Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. > > The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. This pull request has now been integrated. Changeset: 89fd6d34 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/89fd6d34f859d61d9cf5a1edf9419eee7c338390 Stats: 147 lines in 3 files changed: 141 ins; 0 del; 6 mod 8284910: Buffer clean in PasswordCallback Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From weijun at openjdk.java.net Thu Apr 28 02:56:45 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Apr 2022 02:56:45 GMT Subject: Integrated: 8285493: ECC calculation error In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 21:02:49 GMT, Weijun Wang wrote: > Only numbers from the same modular fields can be involved in arithmetic calculations. Add `assert` to guarantee this. > > Also, found one broken case and rewrote it. This pull request has now been integrated. Changeset: c1173c24 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/c1173c24bff271e26013126ff1746c480e2fe1a9 Stats: 16 lines in 2 files changed: 3 ins; 4 del; 9 mod 8285493: ECC calculation error Reviewed-by: xuelei, ascarpino ------------- PR: https://git.openjdk.java.net/jdk/pull/8409 From xuelei at openjdk.java.net Thu Apr 28 04:34:36 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Apr 2022 04:34:36 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v12] 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: change to use othervm ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8136/files - new: https://git.openjdk.java.net/jdk/pull/8136/files/35599747..c0890841 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=10-11 Stats: 4 lines in 2 files changed: 2 ins; 2 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 xuelei at openjdk.java.net Thu Apr 28 04:34:36 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Apr 2022 04:34:36 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v11] In-Reply-To: <8Bj4fnJTqicTJB2NtfkzdOlhfZl8vOhhEJrbh9Qkm04=.2274778f-375d-47be-9df7-e4920549e198@github.com> References: <-OJP7zoU6S4wHInqibqZNh_mtOCzER36wIwHOY_vOJE=.1656b096-a556-49fc-9763-e5ac6fb838de@github.com> <8Bj4fnJTqicTJB2NtfkzdOlhfZl8vOhhEJrbh9Qkm04=.2274778f-375d-47be-9df7-e4920549e198@github.com> Message-ID: On Wed, 27 Apr 2022 22:56:08 GMT, Weijun Wang wrote: > please change them to use `othervm`. Thanks for the catch. Updated to use othervm. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From xuelei at openjdk.java.net Thu Apr 28 04:47:41 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Apr 2022 04:47:41 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: References: Message-ID: <7qogGHJ9jGPj6K6qqYVFnDfSUcSqJNB0jLifgJshstY=.be9bb286-dbce-446c-9684-dfa77ec2d0a4@github.com> On Wed, 27 Apr 2022 23:35:19 GMT, Valerie Peng wrote: >> With Signature class, there is a caveat for EdDSA, the supplied parameters are set but null is being returned when getParameters() is called. This is currently covered by the condition `if the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}` as the underlying signature does not support AlgorithmParameters for the supplied EdDSAParameterSpec object due to lack of ASN.1 definition. > > Besides this Signature-specific condition, there is the common condition where provider cannot (or do not) generate default parameter values. {@code null} is used as the catch-all result, but as you said, describe various conditions tersely and correctly is key. > > What does it refer to with 'it'? Is 'it' refer to the implementation generated parameter values? > > 'It' refers to the parameters containing all of the parameter values including the supplied ones and provider-generated ones if any. The full sentence is, "If the required parameters were not supplied and the underlying signature implementation can generate the parameter values, it will be returned." As there is no supplied value, I think 'it' refer to the provider-generated ones if any. As the previous noun is "the parameters values", I'm not sure if the use of 'it' here is properly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From xuelei at openjdk.java.net Thu Apr 28 04:47:41 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Apr 2022 04:47:41 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: <7qogGHJ9jGPj6K6qqYVFnDfSUcSqJNB0jLifgJshstY=.be9bb286-dbce-446c-9684-dfa77ec2d0a4@github.com> References: <7qogGHJ9jGPj6K6qqYVFnDfSUcSqJNB0jLifgJshstY=.be9bb286-dbce-446c-9684-dfa77ec2d0a4@github.com> Message-ID: <6YhRhen4o8Kg5pwhGxLF__535eB9ggQ57I6m6wu6oo4=.b4d0d99f-6d06-4ce7-8986-6470bae6a6f0@github.com> On Thu, 28 Apr 2022 04:41:20 GMT, Xue-Lei Andrew Fan wrote: >> Besides this Signature-specific condition, there is the common condition where provider cannot (or do not) generate default parameter values. {@code null} is used as the catch-all result, but as you said, describe various conditions tersely and correctly is key. > >> > What does it refer to with 'it'? Is 'it' refer to the implementation generated parameter values? >> >> 'It' refers to the parameters containing all of the parameter values including the supplied ones and provider-generated ones if any. > > The full sentence is, "If the required parameters were not supplied and the underlying signature implementation can generate the parameter values, it will be returned." As there is no supplied value, I think 'it' refer to the provider-generated ones if any. As the previous noun is "the parameters values", I'm not sure if the use of 'it' here is properly. > Can you clarify what is the A and B that you are referring to? The sentence is, ?If the required parameters were not supplied and the underlying signature implementation can generate the parameter values, it will be returned. Otherwise, {https://github.com/code null} is returned." I read "the required parameters were not supplied" as condition A; and "the underlying signature implementation can generate the parameter values" as condition B. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From xuelei at openjdk.java.net Thu Apr 28 05:01:00 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Apr 2022 05:01:00 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: <6YhRhen4o8Kg5pwhGxLF__535eB9ggQ57I6m6wu6oo4=.b4d0d99f-6d06-4ce7-8986-6470bae6a6f0@github.com> References: <7qogGHJ9jGPj6K6qqYVFnDfSUcSqJNB0jLifgJshstY=.be9bb286-dbce-446c-9684-dfa77ec2d0a4@github.com> <6YhRhen4o8Kg5pwhGxLF__535eB9ggQ57I6m6wu6oo4=.b4d0d99f-6d06-4ce7-8986-6470bae6a6f0@github.com> Message-ID: On Thu, 28 Apr 2022 04:44:43 GMT, Xue-Lei Andrew Fan wrote: >>> > What does it refer to with 'it'? Is 'it' refer to the implementation generated parameter values? >>> >>> 'It' refers to the parameters containing all of the parameter values including the supplied ones and provider-generated ones if any. >> >> The full sentence is, "If the required parameters were not supplied and the underlying signature implementation can generate the parameter values, it will be returned." As there is no supplied value, I think 'it' refer to the provider-generated ones if any. As the previous noun is "the parameters values", I'm not sure if the use of 'it' here is properly. > >> Can you clarify what is the A and B that you are referring to? > > The sentence is, ?If the required parameters were not supplied and the underlying signature implementation can generate the parameter values, it will be returned. Otherwise, {https://github.com/code null} is returned." > > I read "the required parameters were not supplied" as condition A; and "the underlying signature implementation can generate the parameter values" as condition B. > With Signature class, there is a caveat for EdDSA, the supplied parameters are set but null is being returned when getParameters() is called. This is currently covered by the condition `if the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}` as the underlying signature does not support AlgorithmParameters for the supplied EdDSAParameterSpec object due to lack of ASN.1 definition. I see now. My 1st read of the condition, I did not get the point and thought it is not necessary as the method is trying to return "AlgorithmParameters". Could it be more clear if describe this case in an additional sentence? ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From peter.firmstone at zeus.net.au Thu Apr 28 05:25:05 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 28 Apr 2022 15:25:05 +1000 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> Message-ID: <76dc6625-cf62-3c7a-6de9-8419c8e0d887@zeus.net.au> Hi Martin, Your arguments are the reasons why we use the principle of least privilege.?? It creates a headache for attackers, similar to the developer who's enabled SM for the first time and must manually add every required permission for their software to function (who thought that was a good idea lol?).?? The attacker requires an intimate knowledge of the permissions their attack vectors or gadgets require, including those a thread of execution has already been granted as well as the features that those permissions will grant the attacker access to.?? If the thread of execution doesn't have all required permissions, it will cause the jvm to exit with a SecurityException.?? How does the attacker obtain all the required information?? With great difficulty. As soon as the software does something a generated polp policy file hasn't captured, a security exception is almost inevitably thrown, even if it wasn't designed to protect an intended target, it almost inevitably gets in the way.? You will find that it's almost impossible to do anything unintended.? Although once you can impersonate a user or service, say with the recent ECC exploit, you can at least do what that user or service is allowed to do, but it still won't allow the attacker to achieve their intended end goal unless the user or has all the required permissions.? In our case if the attacker can impersonate a service, then they can load code, that's a problem, as our software assumes ECDSA provides strong confidentiality.? We recognise that once you get to the stage of loading code into the jvm, it's pretty much game over.?? A polp policy file won't defend against the recent ECC exploit. https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/ConfidentialityStrength.java What polp can protect against however, is an exploit in a feature that you don't use, it protected against the recent Log4J vulnerability. An example of a polp policy file: https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy One of the improvements we can make (when re-implementing access controls), is to reduce the size of the jdk's trusted computing base, instead of having many trusted protection domains with all permission (characterised with a null protection domain), we can give each module a separate protection domain identity, and limit each only to the permissions required for our software to function as intended.?? This means that jvm modules we don't use will have no permissions at all.? To get around the large trusted jdk code base, we provided two methods which append a ProtectionDomain, with only the user's required permissions, it also prevents injection of a user Subject's permission's into less privileged service domains.? It's use hasn't really caught on though, no doubt due to complexity. https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/net/jini/security/Security.java#L590 This is really a hack because the jdk's trusted computing base is too large, also user permissions should be granted only to protection domains that have the necessary user principals and code signers, to avoid injecting additional permissions into less privileged service protection domains. All data parsing the jvm performs, should also be moved into separate modules, so that data parsing access controls and privileges could have been managed (this is one of the missing checks you mention), and yes it did provide a false sense of security for many years that Java serialization was secure when it wasn't.? I had many difficulties explaining to developers in 2010 that Java serialization wasn't secure, they didn't believe me and it cause problems. Had the Java 2SE security infrastructure never been introduced, perhaps something else would have evolved, or at the very least, our software wouldn't depend on it.? Java's access controls have certainly suffered from a lack of investment. Unfortunately our software is dependent on it and designed around it at a fundamental level, even if SM is null (which incidentally I've haven't yet tested, I think we have code that checks that SM is enabled), our software is still using AccessControlContext's to establish TLS connections and authenticate users.?? Personally I would like to see parts of AccessController and AccessControlContext retained for retrieving the Subject for establishing secure connections in a way that's compatible across all Java versions. After removing access controls, it effectively means AllPermission is granted to every authenticated user (and in our case service).?? Any access controls that we create at a higher level, can be circumvented by the lack of lower level access controls.?? So the only access control is authentication. We have no desire or want to instrument the jvm, we have been advised that this is the new way to implement access controls by OpenJDK, it's simply that we want to continue to support future versions of Java and cannot do so without access controls.? Our software has been designed with and depends on access controls. Java has had access controls for 24 years, we couldn't foresee that it would be removed in a breaking manner in such a short time frame.? Remember how long Thread.stop and similar bad api's remained in deprecated form? https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8204243 This isn't something we wanted or planned to do, it's a task that has been created for us and we have few resources to address it. Regards, Peter. On 28/04/2022 3:37 am, Martin Balao wrote: > David, > > I understand the reasons behind seeing authorization checks at the > runtime layer as something that just adds, without any harm in the > worst case (all of this putting the maintenance cost and other > arguments aside.) > > My concern is more about the general security principles underpinning > the idea. We will probably agree that half-barriers are not barriers, > and might cause a false sense of security. If we have authorization > checks at the runtime level, they must be comprehensive, coherent?and > well-maintained. Their availability suggests that mixing high-level > checks with runtime-level ones can be part of a good security design > in modern application development. For the reasons that we've been > discussing, I'm not convinced of that. And even when subtle, I prefer > the runtime not to make the suggestion. If you still want it, you can > go ahead with instrumentation; but it's clear that for the runtime > developers that is a workaround and not a desirable security design. > > What I mean by splitting responsibility is that application > developers?can use a mix of high and low level checks, at different > layers, with more complexity. As Sean said, letting the unauthorized > user to move?towards the edge of the action is more risky. We can lose > sight of workarounds and holes with the additional attack surface and > complexity that comes at a lower layer. What I want to stress is the > value of clarity, simplicity and division of responsibilities as a > general security principle. > > Martin.- > From djelinski at openjdk.java.net Thu Apr 28 06:25:37 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 28 Apr 2022 06:25:37 GMT Subject: Integrated: 8285696: AlgorithmConstraints:permits not throwing IllegalArgumentException when 'alg' is null In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:03:15 GMT, Daniel Jeli?ski wrote: > Please review this follow up to #8349. > > As JCK pointed out, `permits` is supposed to throw IAE on null input. However, now that we're looking up the result in a `ConcurrentHashMap`, a `NullPointerException` is thrown. This patch restores the original behavior. > > Verified that the JCK test passes with this change. This pull request has now been integrated. Changeset: 47951655 Author: Daniel Jeli?ski URL: https://git.openjdk.java.net/jdk/commit/47951655acacba515c0d69f5192257664f887dba Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8285696: AlgorithmConstraints:permits not throwing IllegalArgumentException when 'alg' is null Reviewed-by: jpai, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/8427 From jpai at openjdk.java.net Thu Apr 28 06:34:54 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 28 Apr 2022 06:34:54 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v9] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 16:22:38 GMT, Xue-Lei Andrew Fan wrote: >> Please review this password cleanup enhancement in the PasswordCallback implementation. This is one of the effort to clean up the buffered passwords. >> >> The PasswordCallback.setPassword() clones the password, but is not registered for cleanup. An application could call clearPassword() for the purpose, but it would be nice to cleanup the buffer as well if clearPassword() was not called in an application. And, if the setPassword() get called multiple times, the clearPassword() should also be called the same times if not relying on finalization. It could be fragile in practice. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > no sleep for waiting cleanup More of a FYI - the CheckCleanerBound test failed on one of the test setups. So I've created https://bugs.openjdk.java.net/browse/JDK-8285785 to track that failure. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From peter.firmstone at zeus.net.au Thu Apr 28 06:39:35 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 28 Apr 2022 16:39:35 +1000 Subject: A possible JEP to replace SecurityManager after JEP 411 In-Reply-To: <76dc6625-cf62-3c7a-6de9-8419c8e0d887@zeus.net.au> References: <09ee1982-e22d-f144-c0a9-a5234c516920@oracle.com> <553f430d-8426-5f89-0664-c2ff2c37f555@oracle.com> <76dc6625-cf62-3c7a-6de9-8419c8e0d887@zeus.net.au> Message-ID: Brief comment on ECC attack below, the code download can be prevented by granting DownloadPermission only to code signers and not user principals.? In this case the imposter service would only be able to cause a signed code source to class-load.?? Since Java serialization is disabled, the attacker would probably be unable to penetrate the jvm, but still could potentially steal data. On 28/04/2022 3:25 pm, Peter Firmstone wrote: > Hi Martin, > > Your arguments are the reasons why we use the principle of least > privilege.?? It creates a headache for attackers, similar to the > developer who's enabled SM for the first time and must manually add > every required permission for their software to function (who thought > that was a good idea lol?).?? The attacker requires an intimate > knowledge of the permissions their attack vectors or gadgets require, > including those a thread of execution has already been granted as well > as the features that those permissions will grant the attacker access > to.?? If the thread of execution doesn't have all required > permissions, it will cause the jvm to exit with a SecurityException.?? > How does the attacker obtain all the required information?? With great > difficulty. > > As soon as the software does something a generated polp policy file > hasn't captured, a security exception is almost inevitably thrown, > even if it wasn't designed to protect an intended target, it almost > inevitably gets in the way.? You will find that it's almost impossible > to do anything unintended.? Although once you can impersonate a user > or service, say with the recent ECC exploit, you can at least do what > that user or service is allowed to do, but it still won't allow the > attacker to achieve their intended end goal unless the user or has all > the required permissions.? In our case if the attacker can impersonate > a service, then they can load code, that's a problem, as our software > assumes ECDSA provides strong confidentiality.? We recognise that once > you get to the stage of loading code into the jvm, it's pretty much > game over.?? A polp policy file won't defend against the recent ECC > exploit. > > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/ConfidentialityStrength.java > > > What polp can protect against however, is an exploit in a feature that > you don't use, it protected against the recent Log4J vulnerability. > > An example of a polp policy file: > https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy > > One of the improvements we can make (when re-implementing access > controls), is to reduce the size of the jdk's trusted computing base, > instead of having many trusted protection domains with all permission > (characterised with a null protection domain), we can give each module > a separate protection domain identity, and limit each only to the > permissions required for our software to function as intended.?? This > means that jvm modules we don't use will have no permissions at all.? > To get around the large trusted jdk code base, we provided two methods > which append a ProtectionDomain, with only the user's required > permissions, it also prevents injection of a user Subject's > permission's into less privileged service domains.? It's use hasn't > really caught on though, no doubt due to complexity. > > https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/net/jini/security/Security.java#L590 > > > This is really a hack because the jdk's trusted computing base is too > large, also user permissions should be granted only to protection > domains that have the necessary user principals and code signers, to > avoid injecting additional permissions into less privileged service > protection domains. > > All data parsing the jvm performs, should also be moved into separate > modules, so that data parsing access controls and privileges could > have been managed (this is one of the missing checks you mention), and > yes it did provide a false sense of security for many years that Java > serialization was secure when it wasn't.? I had many difficulties > explaining to developers in 2010 that Java serialization wasn't > secure, they didn't believe me and it cause problems. > > Had the Java 2SE security infrastructure never been introduced, > perhaps something else would have evolved, or at the very least, our > software wouldn't depend on it.? Java's access controls have certainly > suffered from a lack of investment. > > Unfortunately our software is dependent on it and designed around it > at a fundamental level, even if SM is null (which incidentally I've > haven't yet tested, I think we have code that checks that SM is > enabled), our software is still using AccessControlContext's to > establish TLS connections and authenticate users.?? Personally I would > like to see parts of AccessController and AccessControlContext > retained for retrieving the Subject for establishing secure > connections in a way that's compatible across all Java versions. > > After removing access controls, it effectively means AllPermission is > granted to every authenticated user (and in our case service).?? Any > access controls that we create at a higher level, can be circumvented > by the lack of lower level access controls. So the only access control > is authentication. > > We have no desire or want to instrument the jvm, we have been advised > that this is the new way to implement access controls by OpenJDK, it's > simply that we want to continue to support future versions of Java and > cannot do so without access controls.? Our software has been designed > with and depends on access controls. > > Java has had access controls for 24 years, we couldn't foresee that it > would be removed in a breaking manner in such a short time frame.? > Remember how long Thread.stop and similar bad api's remained in > deprecated form? > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8204243 > > This isn't something we wanted or planned to do, it's a task that has > been created for us and we have few resources to address it. > > Regards, > > Peter. > > On 28/04/2022 3:37 am, Martin Balao wrote: >> David, >> >> I understand the reasons behind seeing authorization checks at the >> runtime layer as something that just adds, without any harm in the >> worst case (all of this putting the maintenance cost and other >> arguments aside.) >> >> My concern is more about the general security principles underpinning >> the idea. We will probably agree that half-barriers are not barriers, >> and might cause a false sense of security. If we have authorization >> checks at the runtime level, they must be comprehensive, coherent?and >> well-maintained. Their availability suggests that mixing high-level >> checks with runtime-level ones can be part of a good security design >> in modern application development. For the reasons that we've been >> discussing, I'm not convinced of that. And even when subtle, I prefer >> the runtime not to make the suggestion. If you still want it, you can >> go ahead with instrumentation; but it's clear that for the runtime >> developers that is a workaround and not a desirable security design. >> >> What I mean by splitting responsibility is that application >> developers?can use a mix of high and low level checks, at different >> layers, with more complexity. As Sean said, letting the unauthorized >> user to move?towards the edge of the action is more risky. We can >> lose sight of workarounds and holes with the additional attack >> surface and complexity that comes at a lower layer. What I want to >> stress is the value of clarity, simplicity and division of >> responsibilities as a general security principle. >> >> Martin.- >> From hchao at openjdk.java.net Thu Apr 28 06:46:35 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 28 Apr 2022 06:46:35 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v2] 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: SecretKeyConstraintsParameters subclass created and property description updated ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8300/files - new: https://git.openjdk.java.net/jdk/pull/8300/files/5a821bcd..2079c60b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=00-01 Stats: 72 lines in 5 files changed: 41 ins; 20 del; 11 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 Thu Apr 28 06:46:36 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 28 Apr 2022 06:46:36 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v2] In-Reply-To: References: Message-ID: <0qjhTH3Kib9femje5RM1zWrLTdMjFlK6kgFkfmfFB9U=.5a33159e-7613-4239-a85f-6b03dcab7b55@github.com> On Wed, 27 Apr 2022 19:34:04 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> SecretKeyConstraintsParameters subclass created and property description updated > > src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1876: > >> 1874: >> 1875: CertPathConstraintsParameters cpcp = >> 1876: new CertPathConstraintsParameters(secKey, null, null, null); > > Using `CertPathConstraintsParameters` is a little odd here, even though it works. I suggest creating a local `SecretKeyConstraintsParameters` subclass with a ctor with just the parameters you need and overriding the methods as needed. And changing `checkWeakConstraint` to take a `ConstraintsParameters` instead of `CertPathConstraintsParameters`. Created `SecretKeyConstraintsParameter` subclass for keytool. > src/java.base/share/conf/security/java.security line 657: > >> 655: # implementations. >> 656: >> 657: jdk.security.legacyAlgorithms=SHA1, \ > > Since we are now warning about weak symmetric key algorithms, we should make the description of this property more general. I would change lines 641-2 to "Legacy cryptographic algorithms and key lengths". Updated the description. > test/jdk/sun/security/tools/keytool/ReadJar.java line 162: > >> 160: .shouldContain("Certificate #2:") >> 161: .shouldContain("Signer #2:") >> 162: .shouldNotMatch("The certificate #.* of signer #.*" + "uses the SHA1withRSA.*will be disabled") > > You probably don't need to check for a non-occurrence here since the message has been changed and can no longer occur. Removed the checking for a non-occurrence from the tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From xuelei at openjdk.java.net Thu Apr 28 06:58:44 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Apr 2022 06:58:44 GMT Subject: RFR: 8284910: Buffer clean in PasswordCallback [v9] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 06:31:30 GMT, Jaikiran Pai wrote: > More of a FYI - the CheckCleanerBound test failed on one of the test setups. So I've created https://bugs.openjdk.java.net/browse/JDK-8285785 to track that failure. Thank you! I will add the sleep back. ------------- PR: https://git.openjdk.java.net/jdk/pull/8272 From xuelei at openjdk.java.net Thu Apr 28 07:10:01 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Apr 2022 07:10:01 GMT Subject: RFR: 8285785: CheckCleanerBound test fails with PasswordCallback object is not released Message-ID: Hi, May I have this test update reviewed? The javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java test case failed on one of the test setups. The test runs gc in a loop and expects the GC to have garbage collected contents of a WeakHashMap. The loop runs for 10 iterations. Some delay needs to be added between each iteration to increase the chances of GC garbage collecting the instances. Thanks, Xuelei ------------- Commit messages: - 8285785: CheckCleanerBound test fails with PasswordCallback object is not released Changes: https://git.openjdk.java.net/jdk/pull/8443/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8443&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285785 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8443.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8443/head:pull/8443 PR: https://git.openjdk.java.net/jdk/pull/8443 From hchao at openjdk.java.net Thu Apr 28 07:36:40 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 28 Apr 2022 07:36:40 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v2] In-Reply-To: References: Message-ID: <8Eo8wHqjJOI4-rUxr8Ad0BgyABFn6Wv_YhrDXpDsJl0=.6ded4ad0-03bd-4bfe-b6e4-c612840d35c9@github.com> On Wed, 27 Apr 2022 21:04:59 GMT, Weijun Wang 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. @wangweij This is an interesting question that you raised. From keytool perspective, this security property `keystore.pkcs12.legacy` is implemented in underlying `PKCS12 KeyStore` as you pointed out. It?s not clear to me the need to add RC2 to the security property. Regarding PBEWithSHA1AndRC2_40 algorithm, the algorithm constraint checking will always flag ?SHA1? as a weak algorithm prior to RC2 after decomposing this algorithm. And RC2 is not supported by the PKCS12 KeyStore already. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From hchao at openjdk.java.net Thu Apr 28 07:36:41 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 28 Apr 2022 07:36:41 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v2] In-Reply-To: References: Message-ID: <4edXG4zWvJF_oLoKWs-y_DaVE6ClT1NwU6P2J0GAf1M=.d5c79480-b033-40b6-adfb-31e53f8969ab@github.com> On Wed, 27 Apr 2022 19:35:04 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> SecretKeyConstraintsParameters subclass created and property description updated > > Changes requested by mullan (Reviewer). @seanjmullan Also, fixed the problem that you brought up for `-genseckey -keyalg RC2` in a PKCS12 keystore. Fix is to throw NoSuchAlgorithmException when a key size is not specified. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From dfuchs at openjdk.java.net Thu Apr 28 08:03:43 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 28 Apr 2022 08:03:43 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 01:34:19 GMT, Joe Darcy wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to more review feedback. Thanks for the updates Joe. Your new wording looks good to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8410 From alanb at openjdk.java.net Thu Apr 28 08:14:25 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 28 Apr 2022 08:14:25 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 01:34:19 GMT, Joe Darcy wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to more review feedback. src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 55: > 53: * against the original path of the directory (irrespective of if the > 54: * directory is moved since it was opened). > 55: * @param the type of path It may not be a path. The type parameter is specified in the super interfaces, can you copy that down instead? src/java.base/share/classes/java/nio/file/WatchEvent.java line 51: > 49: /** > 50: * An event kind, for the purposes of identification. > 51: * @param the type of the context value This is okay but the it differs slightly to the type parameters specified further up. I think the issue here is that it was just wasn't copied down to WatchEvent.Kind. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From dfuchs at openjdk.java.net Thu Apr 28 08:35:41 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 28 Apr 2022 08:35:41 GMT Subject: RFR: 8285785: CheckCleanerBound test fails with PasswordCallback object is not released In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 07:01:25 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this test update reviewed? > > The javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java test case failed on one of the test setups. The test runs gc in a loop and expects the GC to have garbage collected contents of a WeakHashMap. The loop runs for 10 iterations. Some delay needs to be added between each iteration to increase the chances of GC garbage collecting the instances. > > Thanks, > Xuelei LGTM. It's a bit strange to use a weak hash map for that though. It could be simpler to use `WeakReference` and `ReferenceQueue`. Marked as reviewed by dfuchs (Reviewer). ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8443 From mullan at openjdk.java.net Thu Apr 28 12:22:33 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 28 Apr 2022 12:22:33 GMT Subject: RFR: 8285785: CheckCleanerBound test fails with PasswordCallback object is not released In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 07:01:25 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this test update reviewed? > > The javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java test case failed on one of the test setups. The test runs gc in a loop and expects the GC to have garbage collected contents of a WeakHashMap. The loop runs for 10 iterations. Some delay needs to be added between each iteration to increase the chances of GC garbage collecting the instances. > > Thanks, > Xuelei Marked as reviewed by mullan (Reviewer). test/jdk/javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java line 50: > 48: for (int i = 0; i < 10 && weakHashMap.size() != 0; i++) { > 49: System.gc(); > 50: Thread.sleep(100); Looks ok to me although @RogerRiggs commented in the previous PR that 10ms should be sufficient. ------------- PR: https://git.openjdk.java.net/jdk/pull/8443 From rriggs at openjdk.java.net Thu Apr 28 13:37:53 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 28 Apr 2022 13:37:53 GMT Subject: RFR: 8285785: CheckCleanerBound test fails with PasswordCallback object is not released In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 07:01:25 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this test update reviewed? > > The javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java test case failed on one of the test setups. The test runs gc in a loop and expects the GC to have garbage collected contents of a WeakHashMap. The loop runs for 10 iterations. Some delay needs to be added between each iteration to increase the chances of GC garbage collecting the instances. > > Thanks, > Xuelei Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8443 From rriggs at openjdk.java.net Thu Apr 28 13:38:06 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 28 Apr 2022 13:38:06 GMT Subject: RFR: 8285785: CheckCleanerBound test fails with PasswordCallback object is not released In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 12:19:35 GMT, Sean Mullan wrote: >> Hi, >> >> May I have this test update reviewed? >> >> The javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java test case failed on one of the test setups. The test runs gc in a loop and expects the GC to have garbage collected contents of a WeakHashMap. The loop runs for 10 iterations. Some delay needs to be added between each iteration to increase the chances of GC garbage collecting the instances. >> >> Thanks, >> Xuelei > > test/jdk/javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java line 50: > >> (failed to retrieve contents of file, check the PR for context) > Looks ok to me although @RogerRiggs commented in the previous PR that 10ms should be sufficient. Alternatively, the loop count could be raised by 10x. That would keep the typical running time low and still allow for a worst case. Your choice. ------------- PR: https://git.openjdk.java.net/jdk/pull/8443 From mullan at openjdk.java.net Thu Apr 28 13:51:45 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 28 Apr 2022 13:51:45 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v2] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 06:46:35 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: > > SecretKeyConstraintsParameters subclass created and property description updated A few more comments. src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1862: > 1860: keysize = 168; > 1861: } else if ("RC2".equalsIgnoreCase(keyAlgName)) { > 1862: keysize = 128; There are other algorithms that are also weak such as RC4, and maybe more in the future. Rather than special-casing each of them, I think instead you should call `keygen.init()` for DES and DESede only where you know that the keysize is always fixed. src/java.base/share/conf/security/java.security line 641: > 639: > 640: # > 641: # Legacy cryptographic algorithms and key lengths Nit: add period at end of sentence. test/jdk/sun/security/tools/keytool/ReadJar.java line 26: > 24: /** > 25: * @test > 26: * @bug 6890872 8168882 8257722 8255552 Here we are just updating the warning message, so I don't think the bugid needs to be added. test/jdk/sun/security/tools/keytool/ReadJar.java line 162: > 160: .shouldContain("Certificate #2:") > 161: .shouldContain("Signer #2:") > 162: .shouldNotMatch("The certificate #.* of signer #.*" + "uses the SHA1withRSA.*will be disabled") You probably don't need to check for a non-occurrence here since the message has been changed and can no longer occur. I also think it doesn't need to list the bugid because it is not testing the main fix which is warnings on symmetric key algs. ------------- Changes requested by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8300 From mullan at openjdk.java.net Thu Apr 28 13:51:45 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 28 Apr 2022 13:51:45 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v2] In-Reply-To: References: Message-ID: <--RreEtE_-XirwMoMwnFEDV1XXioQ2az1WnJvIlxNvg=.bb9fe8a4-1ff1-47d1-b131-550baa34842c@github.com> On Wed, 27 Apr 2022 19:35:04 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> SecretKeyConstraintsParameters subclass created and property description updated > > 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From weijun at openjdk.java.net Thu Apr 28 14:44:05 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Apr 2022 14:44:05 GMT Subject: RFR: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file Message-ID: 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`. ------------- Commit messages: - add description Changes: https://git.openjdk.java.net/jdk/pull/8452/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8452&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285827 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8452.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8452/head:pull/8452 PR: https://git.openjdk.java.net/jdk/pull/8452 From duke at openjdk.java.net Thu Apr 28 15:44:54 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 28 Apr 2022 15:44:54 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2] In-Reply-To: <_YwQOsVyKgKab9SSmOqN3nySXG7tQuyaA6x2LZrvjHs=.9737e68e-06f5-4e0d-9816-f15d683685dc@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <6DEFUs_-0PDbYcjWfy-bMr0b8h-o6w9IUY__JzVWugI=.457626e6-daf1-4305-844c-becb861ef777@github.com> <_xKqXJpVgw9hYRf9VG1n2KKu74Py5BGpatA20GM5xxc=.d63a97a7-aec1-4e22-92d3-18061ac4ab12@github.com> <_YwQOsVyKgKab9SSmOqN3nySXG7tQuyaA6x2LZrvjHs=.9737e68e-06f5-4e0d-9816-f15d683685dc@github.com> Message-ID: <2RJueLB1iCjOt9iJ81Jfd0nKNCk2YNFJBz-YQ_dcN7A=.c442b6ae-7a45-440e-911a-719254e5ba84@github.com> On Wed, 27 Apr 2022 20:22:42 GMT, Mark Powers wrote: >> JDK-6725221 is about obtaining boolean properties, so not an exact match. The suggested change is so easy, I'm going to do it. > > sun.security.action.GetPropertyAction::privilegedGetProperty doesn't trim the return value. Could this be a problem? Answer is no. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From weijun at openjdk.java.net Thu Apr 28 15:51:51 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Apr 2022 15:51:51 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v4] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: <8K_OkJBoJ6cnnWP7bh1fpfc3Nao66GGHI9mQlYKe5D8=.3ed23275-a79e-4f45-a12c-1442d3e123f8@github.com> On Thu, 28 Apr 2022 02:33:49 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8285504 >> >> 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/net > > Mark Powers 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 eight additional commits since the last revision: > > - Merge > - Max and Brad comments > - jaikiran comments > - Alan Bateman comments > - second iteration > - Merge > - Merge > - first iteration I made some wrong suggestions earlier. src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java line 70: > 68: String type; > 69: type = GetPropertyAction.privilegedGetProperty( > 70: "ssl.KeyManagerFactory.algorithm"); So sorry I got it wrong here, this is a security property. `GetPropertyAction.privilegedGetProperty` is for system properties. src/java.base/share/classes/javax/net/ssl/SSLSocketFactory.java line 92: > 90: static String getSecurityProperty(final String name) { > 91: return AccessController.doPrivileged((PrivilegedAction) () -> { > 92: return Security.getProperty(name); I assume we still need to do the if-empty-then-null conversion? src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java line 82: > 80: String type; > 81: type = GetPropertyAction.privilegedGetProperty( > 82: "ssl.TrustManagerFactory.algorithm"); Sorry I got it wrong here, this is a security property. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From xuelei at openjdk.java.net Thu Apr 28 16:14:36 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Apr 2022 16:14:36 GMT Subject: RFR: 8285785: CheckCleanerBound test fails with PasswordCallback object is not released In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 13:34:04 GMT, Roger Riggs wrote: >> Hi, >> >> May I have this test update reviewed? >> >> The javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java test case failed on one of the test setups. The test runs gc in a loop and expects the GC to have garbage collected contents of a WeakHashMap. The loop runs for 10 iterations. Some delay needs to be added between each iteration to increase the chances of GC garbage collecting the instances. >> >> Thanks, >> Xuelei > > Marked as reviewed by rriggs (Reviewer). I will check the proposal suggested by @RogerRiggs and @dfuch. As the test failure could be annoying, I would like to integrate this update first. ------------- PR: https://git.openjdk.java.net/jdk/pull/8443 From xuelei at openjdk.java.net Thu Apr 28 16:14:36 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Apr 2022 16:14:36 GMT Subject: Integrated: 8285785: CheckCleanerBound test fails with PasswordCallback object is not released In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 07:01:25 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this test update reviewed? > > The javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java test case failed on one of the test setups. The test runs gc in a loop and expects the GC to have garbage collected contents of a WeakHashMap. The loop runs for 10 iterations. Some delay needs to be added between each iteration to increase the chances of GC garbage collecting the instances. > > Thanks, > Xuelei This pull request has now been integrated. Changeset: b9d1e851 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/b9d1e85151d9d4016639e6298c90737db10f6072 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8285785: CheckCleanerBound test fails with PasswordCallback object is not released Reviewed-by: dfuchs, mullan, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/8443 From wetmore at openjdk.java.net Thu Apr 28 16:17:50 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 28 Apr 2022 16:17:50 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v4] In-Reply-To: <8K_OkJBoJ6cnnWP7bh1fpfc3Nao66GGHI9mQlYKe5D8=.3ed23275-a79e-4f45-a12c-1442d3e123f8@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <8K_OkJBoJ6cnnWP7bh1fpfc3Nao66GGHI9mQlYKe5D8=.3ed23275-a79e-4f45-a12c-1442d3e123f8@github.com> Message-ID: On Thu, 28 Apr 2022 15:47:44 GMT, Weijun Wang wrote: >> Mark Powers 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 eight additional commits since the last revision: >> >> - Merge >> - Max and Brad comments >> - jaikiran comments >> - Alan Bateman comments >> - second iteration >> - Merge >> - Merge >> - first iteration > > src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java line 70: > >> 68: String type; >> 69: type = GetPropertyAction.privilegedGetProperty( >> 70: "ssl.KeyManagerFactory.algorithm"); > > So sorry I got it wrong here, this is a security property. `GetPropertyAction.privilegedGetProperty` is for system properties. I just noticed the same. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From wetmore at openjdk.java.net Thu Apr 28 16:30:44 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 28 Apr 2022 16:30:44 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v4] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: On Thu, 28 Apr 2022 02:33:49 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8285504 >> >> 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/net > > Mark Powers 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 eight additional commits since the last revision: > > - Merge > - Max and Brad comments > - jaikiran comments > - Alan Bateman comments > - second iteration > - Merge > - Merge > - first iteration These need to be addressed before integration. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From duke at openjdk.java.net Thu Apr 28 16:30:45 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 28 Apr 2022 16:30:45 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v4] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <8K_OkJBoJ6cnnWP7bh1fpfc3Nao66GGHI9mQlYKe5D8=.3ed23275-a79e-4f45-a12c-1442d3e123f8@github.com> Message-ID: <4PIuvGjs54dJRxXCJUDpWH-T5qjTwtkP9YPIYZmlBAA=.fdb49060-1c0a-42aa-a9d4-8c794c78c4e3@github.com> On Thu, 28 Apr 2022 16:14:01 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java line 70: >> >>> 68: String type; >>> 69: type = GetPropertyAction.privilegedGetProperty( >>> 70: "ssl.KeyManagerFactory.algorithm"); >> >> So sorry I got it wrong here, this is a security property. `GetPropertyAction.privilegedGetProperty` is for system properties. > > I just noticed the same. Interesting that mach5 tier1 and tier2 tests passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From wetmore at openjdk.java.net Thu Apr 28 16:30:46 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 28 Apr 2022 16:30:46 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v4] In-Reply-To: <8K_OkJBoJ6cnnWP7bh1fpfc3Nao66GGHI9mQlYKe5D8=.3ed23275-a79e-4f45-a12c-1442d3e123f8@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <8K_OkJBoJ6cnnWP7bh1fpfc3Nao66GGHI9mQlYKe5D8=.3ed23275-a79e-4f45-a12c-1442d3e123f8@github.com> Message-ID: On Thu, 28 Apr 2022 15:45:58 GMT, Weijun Wang wrote: >> Mark Powers 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 eight additional commits since the last revision: >> >> - Merge >> - Max and Brad comments >> - jaikiran comments >> - Alan Bateman comments >> - second iteration >> - Merge >> - Merge >> - first iteration > > src/java.base/share/classes/javax/net/ssl/SSLSocketFactory.java line 92: > >> 90: static String getSecurityProperty(final String name) { >> 91: return AccessController.doPrivileged((PrivilegedAction) () -> { >> 92: return Security.getProperty(name); > > I assume we still need to do the if-empty-then-null conversion? Just found the same. This needs to be reverted. You can set a Security Property to an "empty" string which won't work here. Suggest you revert to previous code, possibly using a lambda if that was the original intent. > src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java line 82: > >> 80: String type; >> 81: type = GetPropertyAction.privilegedGetProperty( >> 82: "ssl.TrustManagerFactory.algorithm"); > > Sorry I got it wrong here, this is a security property. Similar comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From wetmore at openjdk.java.net Thu Apr 28 16:30:46 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 28 Apr 2022 16:30:46 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v4] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <8K_OkJBoJ6cnnWP7bh1fpfc3Nao66GGHI9mQlYKe5D8=.3ed23275-a79e-4f45-a12c-1442d3e123f8@github.com> Message-ID: On Thu, 28 Apr 2022 16:22:43 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/javax/net/ssl/SSLSocketFactory.java line 92: >> >>> 90: static String getSecurityProperty(final String name) { >>> 91: return AccessController.doPrivileged((PrivilegedAction) () -> { >>> 92: return Security.getProperty(name); >> >> I assume we still need to do the if-empty-then-null conversion? > > Just found the same. This needs to be reverted. You can set a Security Property to an "empty" string which won't work here. Suggest you revert to previous code, possibly using a lambda if that was the original intent. `Security.getProperty()` does not specify the value will be `trim()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From duke at openjdk.java.net Thu Apr 28 16:40:41 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 28 Apr 2022 16:40:41 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v4] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <8K_OkJBoJ6cnnWP7bh1fpfc3Nao66GGHI9mQlYKe5D8=.3ed23275-a79e-4f45-a12c-1442d3e123f8@github.com> Message-ID: <2dkyJ2-1ko8vM42x5LZxuBpho1Z41ApWXY-J6rjIjgs=.5c4a108a-9db1-4a4c-a1f0-fdbbffaca894@github.com> On Thu, 28 Apr 2022 16:27:08 GMT, Bradford Wetmore wrote: >> Just found the same. This needs to be reverted. You can set a Security Property to an "empty" string which won't work here. Suggest you revert to previous code, possibly using a lambda if that was the original intent. > > `Security.getProperty()` does not specify the value will be `trim()`. My mistake. It's only the trim that you wanted removed, line 94. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From darcy at openjdk.java.net Thu Apr 28 16:47:38 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Apr 2022 16:47:38 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 08:08:37 GMT, Alan Bateman wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to more review feedback. > > src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 55: > >> 53: * against the original path of the directory (irrespective of if the >> 54: * directory is moved since it was opened). >> 55: * @param the type of path > > It may not be a path. The type parameter is specified in the super interfaces, can you copy that down instead? Will change in the next push. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From weijun at openjdk.java.net Thu Apr 28 16:52:40 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Apr 2022 16:52:40 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v2] In-Reply-To: References: Message-ID: <-LbzZimL72lhhb19qgNfETyrVA9eavudM_zNRA54DWQ=.4f917704-7a92-4121-8830-f3ccca5250ef@github.com> On Thu, 28 Apr 2022 06:46:35 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: > > SecretKeyConstraintsParameters subclass created and property description updated There is no way to `-genseckey` an RC2 key in a PKCS12 keystore but the only reason is that we don't have a known RC2 OID registered. (In fact, I was preparing to add one in the attempted code change to add OIDs into the standard names doc). You can add an RC4 key to PKCS12. Also, you can add both RC2 and RC4 to a JCEKS keystore. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From darcy at openjdk.java.net Thu Apr 28 16:58:40 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Apr 2022 16:58:40 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v4] In-Reply-To: References: Message-ID: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to more review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8410/files - new: https://git.openjdk.java.net/jdk/pull/8410/files/db4919a9..aaa8f828 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410 PR: https://git.openjdk.java.net/jdk/pull/8410 From darcy at openjdk.java.net Thu Apr 28 16:58:40 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Apr 2022 16:58:40 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 08:10:38 GMT, Alan Bateman wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to more review feedback. > > src/java.base/share/classes/java/nio/file/WatchEvent.java line 51: > >> 49: /** >> 50: * An event kind, for the purposes of identification. >> 51: * @param the type of the context value > > This is okay but the it differs slightly to the type parameters specified further up. I think the issue here is that it was just wasn't copied down to WatchEvent.Kind. Okay -- I'll for the T type parameter of the Kind interface I'll reuse the wording of the T type parameter of the enclosing WatchEvent interface. (The type variable on Kind could be renamed to show that the two type parameters are distinct.) ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From mullan at openjdk.java.net Thu Apr 28 17:17:44 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 28 Apr 2022 17:17:44 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2] In-Reply-To: References: Message-ID: <45s4tviPnJ11NmlAndrgmv0Ruzi1R_sTqAKOQg3OoAQ=.674c6625-0ef1-4688-add8-d0d22760c53c@github.com> On Wed, 27 Apr 2022 20:01:26 GMT, Sean Mullan wrote: >> I don't see the ProviderException being mentioned? >> Per the description under JDK-8209038, the requests are: >> 1) describe the returned parameters following what's in Signature class, i.e. if this object has been initialized with parameters then ..., if this object has not been initialized with parameters, then ..... (<= Xuelei raises compatibility concern and trying to describe all this would make it very lengthy, so the proposed changes reverted back to the original syntax, e.g. describing the returned parameters but not including the scenarios) >> 2) allow null to be returned if providers cannot generate default parameters. (<= this is addressed in the proposed changes) >> 3) accommodate algorithm-specific/provider-specific implementation on how parameters is handled. (<= this is addressed in the proposed changes as well. However, this part in Signature class needs update since it states the the SAME parameters are returned but AlgorithmParameterSpec may not require all parameter values to be specified.) > > Sorry, I should have been more specific. JDK-8209038 references JDK-8206171 which I think was filed by the TCK team. In that bug description, it says: > >> This bug is filed for clarification of specification (see comment) >> Please clarify the specification to include a possible exception being thrown (ProviderException for RSASSA-PSS) or other possible exceptions for future Signature algorithms that require mandatory parameters by the user before any operations could be performed, and user did not set any parameters before using the Signature operations (sign, update, verify). >> Or >> null could be returned (as per specification) > > I assumed the `ProviderException` case could potentially apply to a `Cipher` algorithm as well. You can ignore my last comment. I had not realized that the fix for JDK-8209038 was to make `engineGetParameters` return `null` instead of throwing `ProviderException` when RSASSA-PSS params are not specified. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From alanb at openjdk.java.net Thu Apr 28 17:30:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 28 Apr 2022 17:30:50 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v4] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 16:58:40 GMT, Joe Darcy wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to more review feedback. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From wetmore at openjdk.java.net Thu Apr 28 17:31:59 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 28 Apr 2022 17:31:59 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v4] In-Reply-To: <2dkyJ2-1ko8vM42x5LZxuBpho1Z41ApWXY-J6rjIjgs=.5c4a108a-9db1-4a4c-a1f0-fdbbffaca894@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <8K_OkJBoJ6cnnWP7bh1fpfc3Nao66GGHI9mQlYKe5D8=.3ed23275-a79e-4f45-a12c-1442d3e123f8@github.com> <2dkyJ2-1ko8vM42x5LZxuBpho1Z41ApWXY-J6rjIjgs=.5c4a108a-9db1-4a4c-a1f0-fdbbffaca894@github.com> Message-ID: On Thu, 28 Apr 2022 16:37:35 GMT, Mark Powers wrote: >> `Security.getProperty()` does not specify the value will be `trim()`. > > My mistake. It's only the trim that you wanted removed, line 94. No, the API for Security.getProperty doesn't specify trimming, so suggest leaving the trim() part also. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From mchung at openjdk.java.net Thu Apr 28 17:49:48 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 28 Apr 2022 17:49:48 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v4] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 16:58:40 GMT, Joe Darcy wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to more review feedback. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From weijun at openjdk.java.net Thu Apr 28 17:51:49 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Apr 2022 17:51:49 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v12] In-Reply-To: References: Message-ID: <1hyRvch4PlHwX5QIqWsAzOLwxFkx_EsKJpKPZwd1QtM=.1f2b04d2-7ce5-45cf-bdee-35fc6a834436@github.com> On Thu, 28 Apr 2022 04:34:36 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: > > change to use othervm I see you removed the `Thread.sleep(100)` calls. Given the failure of another similar test, maybe it's safer to add them back? ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From duke at openjdk.java.net Thu Apr 28 17:51:50 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 28 Apr 2022 17:51:50 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v4] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <8K_OkJBoJ6cnnWP7bh1fpfc3Nao66GGHI9mQlYKe5D8=.3ed23275-a79e-4f45-a12c-1442d3e123f8@github.com> <2dkyJ2-1ko8vM42x5LZxuBpho1Z41ApWXY-J6rjIjgs=.5c4a108a-9db1-4a4c-a1f0-fdbbffaca894@github.com> Message-ID: <8_JGybQblg1GJLU89sZJaEPsZ7Tzb9cLkEargCMvMBE=.84abf1c4-d9dd-4e35-916e-1fce8c5721fc@github.com> On Thu, 28 Apr 2022 17:29:53 GMT, Bradford Wetmore wrote: >> My mistake. It's only the trim that you wanted removed, line 94. > > No, the API for Security.getProperty doesn't specify trimming, so suggest leaving the trim() part also. Okay. Line 94 is back. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From darcy at openjdk.java.net Thu Apr 28 18:05:39 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Apr 2022 18:05:39 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5] In-Reply-To: References: Message-ID: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com> > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Update copyright years. - Merge branch 'master' into JDK-8285676 - Respond to more review feedback. - Respond to more review feedback. - Respond to review feedback. - Merge branch 'master' into JDK-8285676 - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8410/files - new: https://git.openjdk.java.net/jdk/pull/8410/files/aaa8f828..cb1fe1c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=03-04 Stats: 687 lines in 59 files changed: 610 ins; 8 del; 69 mod Patch: https://git.openjdk.java.net/jdk/pull/8410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410 PR: https://git.openjdk.java.net/jdk/pull/8410 From darcy at openjdk.java.net Thu Apr 28 18:05:40 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Apr 2022 18:05:40 GMT Subject: Integrated: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. This pull request has now been integrated. Changeset: bba456a8 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/bba456a8dbf9027e4b015567c17a79fc7441aa08 Stats: 102 lines in 40 files changed: 76 ins; 0 del; 26 mod 8285676: Add missing @param tags for type parameters on classes and interfaces Reviewed-by: wetmore, smarks, dfuchs, prr, alanb, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From xuelei at openjdk.java.net Thu Apr 28 18:19:47 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Apr 2022 18:19:47 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v12] In-Reply-To: <1hyRvch4PlHwX5QIqWsAzOLwxFkx_EsKJpKPZwd1QtM=.1f2b04d2-7ce5-45cf-bdee-35fc6a834436@github.com> References: <1hyRvch4PlHwX5QIqWsAzOLwxFkx_EsKJpKPZwd1QtM=.1f2b04d2-7ce5-45cf-bdee-35fc6a834436@github.com> Message-ID: On Thu, 28 Apr 2022 17:48:20 GMT, Weijun Wang wrote: > I see you removed the `Thread.sleep(100)` calls. Given the failure of another similar test, maybe it's safer to add them back? Yes. I'm evaluating if other proposal works or not. Otherwise, I will add the sleep back. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From xuelei at openjdk.java.net Thu Apr 28 18:23:42 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Apr 2022 18:23:42 GMT Subject: RFR: 8285785: CheckCleanerBound test fails with PasswordCallback object is not released In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 07:01:25 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this test update reviewed? > > The javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java test case failed on one of the test setups. The test runs gc in a loop and expects the GC to have garbage collected contents of a WeakHashMap. The loop runs for 10 iterations. Some delay needs to be added between each iteration to increase the chances of GC garbage collecting the instances. > > Thanks, > Xuelei > Alternatively, the loop count could be raised by 10x. That would keep the typical running time low and still allow for a worst case. Update: I tried to run the test 1000 times. I still can see failure if using 10x loop count, without sleep. ------------- PR: https://git.openjdk.java.net/jdk/pull/8443 From weijun at openjdk.java.net Thu Apr 28 18:24:46 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Apr 2022 18:24:46 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v12] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 04:34:36 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: > > change to use othervm I'm sure you have well established testing environment as well, but if you need any help to test out your "other proposals", I'm glad to help. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From aturbanov at openjdk.java.net Thu Apr 28 18:27:59 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 28 Apr 2022 18:27:59 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5] In-Reply-To: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com> References: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com> Message-ID: On Thu, 28 Apr 2022 18:05:39 GMT, Joe Darcy wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Update copyright years. > - Merge branch 'master' into JDK-8285676 > - Respond to more review feedback. > - Respond to more review feedback. > - Respond to review feedback. > - Merge branch 'master' into JDK-8285676 > - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces src/java.base/share/classes/java/lang/ref/PhantomReference.java line 48: > 46: * The {@link #refersTo(Object) refersTo} method can be used to test > 47: * whether some object is the referent of a phantom reference. > 48: * @param the type of the referent Shouldn't there be a space after `@param` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From duke at openjdk.java.net Thu Apr 28 18:29:35 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 28 Apr 2022 18:29:35 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v5] In-Reply-To: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8285504 > > 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/net Mark Powers has updated the pull request incrementally with one additional commit since the last revision: Max and Brad comments round two ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8384/files - new: https://git.openjdk.java.net/jdk/pull/8384/files/6997837f..15a9f3b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8384&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8384&range=03-04 Stats: 14 lines in 3 files changed: 7 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8384/head:pull/8384 PR: https://git.openjdk.java.net/jdk/pull/8384 From xuelei at openjdk.java.net Thu Apr 28 18:32:31 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Apr 2022 18:32:31 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v13] 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 sleep back ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8136/files - new: https://git.openjdk.java.net/jdk/pull/8136/files/c0890841..d554c724 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8136&range=11-12 Stats: 2 lines in 2 files changed: 2 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 xuelei at openjdk.java.net Thu Apr 28 18:32:32 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 28 Apr 2022 18:32:32 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v12] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 04:34:36 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: > > change to use othervm The Thread.sleep() was added back. Without the sleep, the test may fail intermittent. ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From weijun at openjdk.java.net Thu Apr 28 18:32:32 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Apr 2022 18:32:32 GMT Subject: RFR: 8284490: Remove finalizer method in java.security.jgss [v12] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 04:34:36 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: > > change to use othervm My understanding is such kind of tests that rely on GC is fundementally unreliable. I would preemptively add an intermittent keyword to it. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/8136 From wetmore at openjdk.java.net Thu Apr 28 18:55:45 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 28 Apr 2022 18:55:45 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v5] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: On Thu, 28 Apr 2022 18:29:35 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8285504 >> >> 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/net > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > Max and Brad comments round two Final changes LGTM. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From mchung at openjdk.java.net Thu Apr 28 19:08:52 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 28 Apr 2022 19:08:52 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5] In-Reply-To: References: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com> Message-ID: <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com> On Thu, 28 Apr 2022 18:24:33 GMT, Andrey Turbanov wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Update copyright years. >> - Merge branch 'master' into JDK-8285676 >> - Respond to more review feedback. >> - Respond to more review feedback. >> - Respond to review feedback. >> - Merge branch 'master' into JDK-8285676 >> - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces > > src/java.base/share/classes/java/lang/ref/PhantomReference.java line 48: > >> 46: * The {@link #refersTo(Object) refersTo} method can be used to test >> 47: * whether some object is the referent of a phantom reference. >> 48: * @param the type of the referent > > Shouldn't there be a space after `@param` ? Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From valeriep at openjdk.java.net Thu Apr 28 19:11:23 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 28 Apr 2022 19:11:23 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v3] 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 for getParameters() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8117/files - new: https://git.openjdk.java.net/jdk/pull/8117/files/9b8b71a6..baae26fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8117&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8117&range=01-02 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 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 Thu Apr 28 19:27:45 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Apr 2022 19:27:45 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 19:11:23 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 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"? 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. 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From mullan at openjdk.java.net Thu Apr 28 19:51:43 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 28 Apr 2022 19:51:43 GMT Subject: RFR: 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`. src/java.base/share/conf/security/java.security line 1174: > 1172: # If the property is not set or empty, a default value will be used. > 1173: # > 1174: # For compatibility, the system property "keystore.pkcs12.legacy" can be set Was wondering if we should add why you might want to set this property, ex: "For compatibility with JDK or PKCS12 implementations that do not support the stronger algorithms ..." Compatibility with prior JDK versions should be less of an issue over time as these stronger settings and algs have been backported to prior JDKs. ------------- PR: https://git.openjdk.java.net/jdk/pull/8452 From weijun at openjdk.java.net Thu Apr 28 19:57:42 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Apr 2022 19:57:42 GMT Subject: RFR: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 19:48:38 GMT, Sean Mullan 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`. > > src/java.base/share/conf/security/java.security line 1174: > >> 1172: # If the property is not set or empty, a default value will be used. >> 1173: # >> 1174: # For compatibility, the system property "keystore.pkcs12.legacy" can be set > > Was wondering if we should add why you might want to set this property, ex: "For compatibility with JDK or PKCS12 implementations that do not support the stronger algorithms ..." > > Compatibility with prior JDK versions should be less of an issue over time as these stronger settings and algs have been backported to prior JDKs. OpenSSL's help page shows -legacy Use legacy encryption: 3DES_CBC for keys, RC2_CBC for certs Can we also say "To work with legacy PKCS #12 files"? ------------- PR: https://git.openjdk.java.net/jdk/pull/8452 From mullan at openjdk.java.net Thu Apr 28 20:02:38 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 28 Apr 2022 20:02:38 GMT Subject: RFR: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 19:54:36 GMT, Weijun Wang wrote: >> src/java.base/share/conf/security/java.security line 1174: >> >>> 1172: # If the property is not set or empty, a default value will be used. >>> 1173: # >>> 1174: # For compatibility, the system property "keystore.pkcs12.legacy" can be set >> >> Was wondering if we should add why you might want to set this property, ex: "For compatibility with JDK or PKCS12 implementations that do not support the stronger algorithms ..." >> >> Compatibility with prior JDK versions should be less of an issue over time as these stronger settings and algs have been backported to prior JDKs. > > OpenSSL's help page shows > > -legacy Use legacy encryption: 3DES_CBC for keys, RC2_CBC for certs > > Can we also say "To work with legacy PKCS #12 files"? But isn't it mostly an issue when creating new keystores and not reading existing ones? I would want to avoid users thinking that they had to set this in more cases than needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8452 From duke at openjdk.java.net Thu Apr 28 21:19:42 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 28 Apr 2022 21:19:42 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v4] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> <8K_OkJBoJ6cnnWP7bh1fpfc3Nao66GGHI9mQlYKe5D8=.3ed23275-a79e-4f45-a12c-1442d3e123f8@github.com> Message-ID: On Thu, 28 Apr 2022 16:23:25 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java line 82: >> >>> 80: String type; >>> 81: type = GetPropertyAction.privilegedGetProperty( >>> 82: "ssl.TrustManagerFactory.algorithm"); >> >> Sorry I got it wrong here, this is a security property. > > Similar comment. Back to the original lambda expression. ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From wetmore at openjdk.java.net Thu Apr 28 22:13:53 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 28 Apr 2022 22:13:53 GMT Subject: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v5] In-Reply-To: References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: On Thu, 28 Apr 2022 18:29:35 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8285504 >> >> 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/net > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > Max and Brad comments round two LGTM, Pt2... ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8384 From duke at openjdk.java.net Thu Apr 28 22:22:53 2022 From: duke at openjdk.java.net (Mark Powers) Date: Thu, 28 Apr 2022 22:22:53 GMT Subject: Integrated: JDK-8285504 Minor cleanup could be done in javax.net In-Reply-To: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> References: <0V7jHV3SzjeopHpPimtkZV04H3AvuOF19q0MkQKVAII=.48e99cf2-d43b-4bc7-8838-0bf6b7c4f1fc@github.com> Message-ID: <8b4LttooEv85cEWZCAKzWsTGP63R6ktWYwALWs7c5Fk=.5679cec6-3810-4a20-9a8d-8cfae54bd479@github.com> On Mon, 25 Apr 2022 17:40:13 GMT, Mark Powers wrote: > https://bugs.openjdk.java.net/browse/JDK-8285504 > > 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/net This pull request has now been integrated. Changeset: 573eacec Author: Mark Powers Committer: Bradford Wetmore URL: https://git.openjdk.java.net/jdk/commit/573eaceca559a8a0832b1e1a7181b2f21d3978c7 Stats: 129 lines in 20 files changed: 1 ins; 22 del; 106 mod 8285504: Minor cleanup could be done in javax.net Reviewed-by: wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/8384 From valeriep at openjdk.java.net Thu Apr 28 23:12:44 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 28 Apr 2022 23:12:44 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> Message-ID: <7tFALuKc9QcTFYSzxokreBbeA3X5BpWIxqdmHoXjzNM=.c1ab3294-2edc-481e-a0e1-cf2e2731881a@github.com> On Thu, 28 Apr 2022 04:56:47 GMT, Xue-Lei Andrew Fan wrote: >>> Can you clarify what is the A and B that you are referring to? >> >> The sentence is, ?If the required parameters were not supplied and the underlying signature implementation can generate the parameter values, it will be returned. Otherwise, {https://github.com/code null} is returned." >> >> I read "the required parameters were not supplied" as condition A; and "the underlying signature implementation can generate the parameter values" as condition B. > >> With Signature class, there is a caveat for EdDSA, the supplied parameters are set but null is being returned when getParameters() is called. This is currently covered by the condition `if the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}` as the underlying signature does not support AlgorithmParameters for the supplied EdDSAParameterSpec object due to lack of ASN.1 definition. > > I see now. My 1st read of the condition, I did not get the point and thought it is not necessary as the method is trying to return "AlgorithmParameters". Could it be more clear if describe this case in an additional sentence? What kind of additional sentence do you have in mind? ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From valeriep at openjdk.java.net Thu Apr 28 23:12:44 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 28 Apr 2022 23:12:44 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 Wed, 27 Apr 2022 23:02:28 GMT, Weijun Wang wrote: >> Right, the user-supplied values takes precedence and provider-specific default/random values should just be supplemental. >> >> As for EdDSA, looks like the prehash and context are only in RFC 8032 and NOT RFC 8410. caller has to pass these settings/values to the other entity through some other means since the getParameters() return null as there is no ASN.1 definition for the parameters. Looks like these values are packaged into a parameter spec and passed into the underlying EdDSA signature implementation in order to fit into existing API without adding new algorithm specific APIs. > > So, "the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}" is quite necessary. Xuelei's suggestion is quite good, just change the last "and" to "or". I assume you were suggesting this? `"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. {https://github.com/code null} is returned if the required parameters were not supplied and the underlying signature implementation cannot generate the parameter values."` But the "the underlying signature implementation supports returning the parameters as {https://github.com/code AlgorithmParameters}" is necessary. Strictly speaking, this is somewhat different than the "cannot generate parameter values" though. Perhaps we should go a bit broader for the last sentence regarding null return value? ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From weijun at openjdk.java.net Thu Apr 28 23:18:45 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Apr 2022 23:18:45 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:08:17 GMT, Valerie Peng wrote: >> So, "the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}" is quite necessary. Xuelei's suggestion is quite good, just change the last "and" to "or". > > I assume you were suggesting this? `"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. {https://github.com/code null} is returned if the required parameters were not supplied and the underlying signature implementation cannot generate the parameter values."` > But the "the underlying signature implementation supports returning the parameters as {https://github.com/code AlgorithmParameters}" is necessary. Strictly speaking, this is somewhat different than the "cannot generate parameter values" though. Perhaps we should go a bit broader for the last sentence regarding null return value? I suggest the last sentence to be "null is returned if the required parameters were not supplied **or** the underlying signature implementation cannot generate the parameter values." I used "or" because for EdDSA parameters are supplied but the impl cannot generate parameter values. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From weijun at openjdk.java.net Thu Apr 28 23:24:43 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Apr 2022 23:24:43 GMT Subject: RFR: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 19:59:07 GMT, Sean Mullan wrote: >> OpenSSL's help page shows >> >> -legacy Use legacy encryption: 3DES_CBC for keys, RC2_CBC for certs >> >> Can we also say "To work with legacy PKCS #12 files"? > > But isn't it mostly an issue when creating new keystores and not reading existing ones? I would want to avoid users thinking that they had to set this in more cases than needed. How about this? To work with legacy PKCS #12 tools that does not support the new algorithms, the system property "keystore.pkcs12.legacy" can be set which will override the properties defined here with old settings. This system property is equivalent to ------------- PR: https://git.openjdk.java.net/jdk/pull/8452 From valeriep at openjdk.java.net Thu Apr 28 23:26:43 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 28 Apr 2022 23:26: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:14:56 GMT, Weijun Wang wrote: >> I assume you were suggesting this? `"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. {https://github.com/code null} is returned if the required parameters were not supplied and the underlying signature implementation cannot generate the parameter values."` >> But the "the underlying signature implementation supports returning the parameters as {https://github.com/code AlgorithmParameters}" is necessary. Strictly speaking, this is somewhat different than the "cannot generate parameter values" though. Perhaps we should go a bit broader for the last sentence regarding null return value? > > I suggest the last sentence to be "null is returned if the required parameters were not supplied **or** the underlying signature implementation cannot generate the parameter values." I used "or" because for EdDSA parameters are supplied but the impl cannot generate parameter values. 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From weijun at openjdk.java.net Thu Apr 28 23:31:53 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Apr 2022 23:31:53 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:22:30 GMT, Valerie Peng wrote: >> I suggest the last sentence to be "null is returned if the required parameters were not supplied **or** the underlying signature implementation cannot generate the parameter values." I used "or" because for EdDSA parameters are supplied but the impl cannot generate parameter values. > > 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? ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From wetmore at openjdk.java.net Fri Apr 29 01:50:39 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 29 Apr 2022 01:50:39 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 Thu, 14 Apr 2022 15:37:05 GMT, Daniel Jeli?ski wrote: > IMO we should not send close_notify in the finalizer. It's the application's responsibility to send close_notify when it's done with the socket; we should not pretend that it was closed normally when it was not. @djelinski makes an excellent point which I hadn't really considered. This is an error situation. As the native Socket resources are cleaned/released as needed, a simple removal might actually be appropriate. @XueleiFan I'm going to send you some internal discussion we've had in a minute. Let's both parse it and see if there is anything further we should consider, and circle back tomorrow and finalize the plan & push. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From hchao at openjdk.java.net Fri Apr 29 03:14:58 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 29 Apr 2022 03:14:58 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v2] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 13:25:13 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> SecretKeyConstraintsParameters subclass created and property description updated > > src/java.base/share/conf/security/java.security line 641: > >> 639: >> 640: # >> 641: # Legacy cryptographic algorithms and key lengths > > Nit: add period at end of sentence. Ok. > test/jdk/sun/security/tools/keytool/ReadJar.java line 26: > >> 24: /** >> 25: * @test >> 26: * @bug 6890872 8168882 8257722 8255552 > > Here we are just updating the warning message, so I don't think the bugid needs to be added. Ok. > test/jdk/sun/security/tools/keytool/ReadJar.java line 162: > >> 160: .shouldContain("Certificate #2:") >> 161: .shouldContain("Signer #2:") >> 162: .shouldNotMatch("The certificate #.* of signer #.*" + "uses the SHA1withRSA.*will be disabled") > > You probably don't need to check for a non-occurrence here since the message has been changed and can no longer occur. I also think it doesn't need to list the bugid because it is not testing the main fix which is warnings on symmetric key algs. In webrev 01, I?ve made the change to remove the checking for a non-occurrence. I added the bugid as the test verifies the warning message for asymmetric keys and certificates, which is changed In this PR. I'll remove the bugid as it is not testing the main fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From hchao at openjdk.java.net Fri Apr 29 03:17:45 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 29 Apr 2022 03:17:45 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v2] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 06:46:35 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: > > SecretKeyConstraintsParameters subclass created and property description updated Please review CSR at https://bugs.openjdk.java.net/browse/JDK-8285873 Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From xuelei at openjdk.java.net Fri Apr 29 04:31:41 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 29 Apr 2022 04:31:41 GMT Subject: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2] In-Reply-To: <7tFALuKc9QcTFYSzxokreBbeA3X5BpWIxqdmHoXjzNM=.c1ab3294-2edc-481e-a0e1-cf2e2731881a@github.com> 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, 28 Apr 2022 23:09:00 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}.** ------------- PR: https://git.openjdk.java.net/jdk/pull/8396 From prappo at openjdk.java.net Fri Apr 29 08:48:52 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 29 Apr 2022 08:48:52 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5] In-Reply-To: <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com> References: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com> <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com> Message-ID: On Thu, 28 Apr 2022 19:06:04 GMT, Mandy Chung wrote: >> src/java.base/share/classes/java/lang/ref/PhantomReference.java line 48: >> >>> 46: * The {@link #refersTo(Object) refersTo} method can be used to test >>> 47: * whether some object is the referent of a phantom reference. >>> 48: * @param the type of the referent >> >> Shouldn't there be a space after `@param` ? > > Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files. > Shouldn't there be a space after `@param` ? > Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files. I built the API documentation after this PR has been integrated and the result was okay. I saw this output in every such case: Type Parameters: T - the type of the referent javadoc is quite robust. However, for some IDEs such missing whitespace seems significant. Not only do they highlight the `@param` tag, but the type parameter information is missing from the rendered output. Although it's not critical, we should fix it; I have filed JDK-8285890. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From prappo at openjdk.java.net Fri Apr 29 09:09:50 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 29 Apr 2022 09:09:50 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5] In-Reply-To: References: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com> <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com> Message-ID: On Fri, 29 Apr 2022 08:45:42 GMT, Pavel Rappo wrote: > Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files. I've created a PR; feel free to review it at your convenience. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From prappo at openjdk.java.net Fri Apr 29 09:12:24 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 29 Apr 2022 09:12:24 GMT Subject: RFR: 8285890: Fix some @param tags Message-ID: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com> * Syntactically improves a few cases from 8285676 (https://github.com/openjdk/jdk/pull/8410) * Fixes a few misspelled `@param` tags for elements that, although are not included in the API Documentation, are visible in and processed by IDEs ------------- Commit messages: - Fix misspelled `@param` - Clarify with whitespace tags from 8285676 Changes: https://git.openjdk.java.net/jdk/pull/8465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8465&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285890 Stats: 16 lines in 8 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/8465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8465/head:pull/8465 PR: https://git.openjdk.java.net/jdk/pull/8465 From dfuchs at openjdk.java.net Fri Apr 29 11:19:46 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 29 Apr 2022 11:19:46 GMT Subject: RFR: 8285890: Fix some @param tags In-Reply-To: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com> References: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com> Message-ID: On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo wrote: > * Syntactically improves a few cases from 8285676 (https://github.com/openjdk/jdk/pull/8410) > * Fixes a few misspelled `@param` tags for elements that, although are not included in the API Documentation, are visible in and processed by IDEs LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8465 From mullan at openjdk.java.net Fri Apr 29 12:32:46 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 29 Apr 2022 12:32:46 GMT Subject: Integrated: 8225433: Clarify behavior of PKIXParameters.setRevocationEnabled when PKIXRevocationChecker is used In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 13:35:25 GMT, Sean Mullan wrote: > This change improves the specification for the case when a `PKIXRevocationChecker` is supplied as one of the `CertPathChecker` parameters. Specifically, it makes it more clear that a `PKIXRevocationChecker` overrides the default revocation checking mechanism of a PKIX service provider, and will be used to check revocation irrespective of the setting of the RevocationEnabled parameter. > > Will also file a CSR. This pull request has now been integrated. Changeset: 694556e1 Author: Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/694556e1374eb45776e6105cc4f7a3445a43c3cc Stats: 17 lines in 2 files changed: 9 ins; 0 del; 8 mod 8225433: Clarify behavior of PKIXParameters.setRevocationEnabled when PKIXRevocationChecker is used Reviewed-by: xuelei, hchao ------------- PR: https://git.openjdk.java.net/jdk/pull/8287 From mullan at openjdk.java.net Fri Apr 29 12:48:45 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 29 Apr 2022 12:48:45 GMT Subject: RFR: 8285890: Fix some @param tags In-Reply-To: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com> References: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com> Message-ID: On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo wrote: > * Syntactically improves a few cases from 8285676 (https://github.com/openjdk/jdk/pull/8410) > * Fixes a few misspelled `@param` tags for elements that, although are not included in the API Documentation, are visible in and processed by IDEs GSSHeader looks fine. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8465 From mullan at openjdk.java.net Fri Apr 29 13:21:46 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 29 Apr 2022 13:21:46 GMT Subject: RFR: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 23:20:18 GMT, Weijun Wang wrote: >> But isn't it mostly an issue when creating new keystores and not reading existing ones? I would want to avoid users thinking that they had to set this in more cases than needed. > > How about this? > > To work with legacy PKCS #12 tools that does not support the new algorithms, > the system property "keystore.pkcs12.legacy" can be set > which will override the properties defined here with old settings. > This system property is equivalent to I think the text above might still make some users concerned that they should always set this property. Maybe we can be less specific, and just say: "If you encounter compatibility issues with software that doesn't support the stronger algorithms, the system property ..." ------------- PR: https://git.openjdk.java.net/jdk/pull/8452 From weijun at openjdk.java.net Fri Apr 29 13:31:46 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Apr 2022 13:31:46 GMT Subject: RFR: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file In-Reply-To: References: Message-ID: <_VfTVumSISoDsIG07K5rWhin2NW-tCOfoPxshsXysb0=.99913a5d-c51a-4820-9db1-88cb346171b5@github.com> On Fri, 29 Apr 2022 13:17:55 GMT, Sean Mullan wrote: >> How about this? >> >> To work with legacy PKCS #12 tools that does not support the new algorithms, >> the system property "keystore.pkcs12.legacy" can be set >> which will override the properties defined here with old settings. >> This system property is equivalent to > > I think the text above might still make some users concerned that they should always set this property. > Maybe we can be less specific, and just say: "If you encounter compatibility issues with software that doesn't support the stronger algorithms, the system property ..." Can we say both? All these properties are only used when creating the file (key-related ones when creating the key). If a compatibility issue already happens, users need to downgrade their keystore. So, the full text will be something like To work with legacy PKCS #12 tools that does not support the new algorithms, the system property "keystore.pkcs12.legacy" can be set which will override the properties defined here with old settings. If you encounter compatibility issues with software that doesn't support the stronger algorithms, you can downgrade the keystore with keytool -J-Dkeystore.pkcs12.legacy -importkeystore -keystore ks ... I'll double check if the command can indeed downgrade key algorithms as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/8452 From mullan at openjdk.java.net Fri Apr 29 15:27:48 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 29 Apr 2022 15:27:48 GMT Subject: RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 19:11:23 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 incrementally with one additional commit since the last revision: > > Update for getParameters() Changes requested by mullan (Reviewer). 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}_." 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". ------------- PR: https://git.openjdk.java.net/jdk/pull/8117 From darcy at openjdk.java.net Fri Apr 29 16:13:43 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 29 Apr 2022 16:13:43 GMT Subject: RFR: 8285890: Fix some @param tags In-Reply-To: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com> References: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com> Message-ID: On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo wrote: > * Syntactically improves a few cases from 8285676 (https://github.com/openjdk/jdk/pull/8410) > * Fixes a few misspelled `@param` tags for elements that, although are not included in the API Documentation, are visible in and processed by IDEs Thanks for fixing these Pavel. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8465 From mchung at openjdk.java.net Fri Apr 29 16:44:55 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 29 Apr 2022 16:44:55 GMT Subject: RFR: 8285890: Fix some @param tags In-Reply-To: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com> References: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com> Message-ID: <3lTTXDQCB7Eo73e__RGK6CYITxDq1O3YjBQ6wuDxU7E=.2abb2368-9869-4fe2-a372-3d6ba95a486b@github.com> On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo wrote: > * Syntactically improves a few cases from 8285676 (https://github.com/openjdk/jdk/pull/8410) > * Fixes a few misspelled `@param` tags for elements that, although are not included in the API Documentation, are visible in and processed by IDEs Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8465 From hchao at openjdk.java.net Fri Apr 29 16:45:55 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 29 Apr 2022 16:45:55 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v3] 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: Removed bugid and updated property spec ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8300/files - new: https://git.openjdk.java.net/jdk/pull/8300/files/2079c60b..45066a72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 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 Fri Apr 29 17:06:28 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 29 Apr 2022 17:06:28 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v4] In-Reply-To: References: Message-ID: <9AKGz08kQJpedKR0S0aNcN8A-f3n2z6E5N8FacmYWng=.1518a90d-343f-443b-a69d-a65ed4c909c8@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: Removed RC2 changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8300/files - new: https://git.openjdk.java.net/jdk/pull/8300/files/45066a72..e10ed759 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=02-03 Stats: 7 lines in 2 files changed: 0 ins; 7 del; 0 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 turbanoff at gmail.com Fri Apr 29 15:59:34 2022 From: turbanoff at gmail.com (Andrey Turbanov) Date: Fri, 29 Apr 2022 18:59:34 +0300 Subject: javax.crypto.CryptoPolicyParser#isConsistent always returns 'true' Message-ID: 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? Andrey Turbanov From wetmore at openjdk.java.net Fri Apr 29 17:20:42 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 29 Apr 2022 17:20:42 GMT Subject: RFR: 8285890: Fix some @param tags In-Reply-To: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com> References: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com> Message-ID: On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo wrote: > * Syntactically improves a few cases from 8285676 (https://github.com/openjdk/jdk/pull/8410) > * Fixes a few misspelled `@param` tags for elements that, although are not included in the API Documentation, are visible in and processed by IDEs LGTM also. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8465 From mullan at openjdk.java.net Fri Apr 29 19:21:44 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 29 Apr 2022 19:21:44 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v4] In-Reply-To: <9AKGz08kQJpedKR0S0aNcN8A-f3n2z6E5N8FacmYWng=.1518a90d-343f-443b-a69d-a65ed4c909c8@github.com> References: <9AKGz08kQJpedKR0S0aNcN8A-f3n2z6E5N8FacmYWng=.1518a90d-343f-443b-a69d-a65ed4c909c8@github.com> Message-ID: On Fri, 29 Apr 2022 17:06: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. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Removed RC2 changes src/java.base/share/conf/security/java.security line 644: > 642: # > 643: # In some environments, a certain algorithm or key length may be undesirable > 644: # but is not yet disabled. I would also remove the words "but is not yet disabled." An algorithm may be disabled at different times for different components, such as TLS or Kerberos, so it isn't always a yes or no answer. Also, if a disabled algorithm is re-enabled (by modifying the security properties), we still want `keytool` or `jarsigner` to show warnings. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From ascarpino at openjdk.java.net Fri Apr 29 19:23:25 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 29 Apr 2022 19:23:25 GMT Subject: RFR: 8283577: SSLEngine.unwrap on read-only input ByteBuffer Message-ID: <67qKnTPZ7sEgqCGlhLTc12mK9rAm5ucjcq-XgM7_RA4=.26497c74-3179-40d1-9e03-16401fd07424@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 ------------- Commit messages: - 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=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283577 Stats: 401 lines in 3 files changed: 301 ins; 20 del; 80 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 hchao at openjdk.java.net Fri Apr 29 19:42:27 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 29 Apr 2022 19:42:27 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v5] 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 spec in java.security ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8300/files - new: https://git.openjdk.java.net/jdk/pull/8300/files/e10ed759..ac92a5f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8300&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 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 Fri Apr 29 19:42:27 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 29 Apr 2022 19:42:27 GMT Subject: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms [v4] In-Reply-To: References: <9AKGz08kQJpedKR0S0aNcN8A-f3n2z6E5N8FacmYWng=.1518a90d-343f-443b-a69d-a65ed4c909c8@github.com> Message-ID: On Fri, 29 Apr 2022 19:18:06 GMT, Sean Mullan wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed RC2 changes > > src/java.base/share/conf/security/java.security line 644: > >> 642: # >> 643: # In some environments, a certain algorithm or key length may be undesirable >> 644: # but is not yet disabled. > > I would also remove the words "but is not yet disabled." An algorithm may be disabled at different times for different components, such as TLS or Kerberos, so it isn't always a yes or no answer. Also, if a disabled algorithm is re-enabled (by modifying the security properties), we still want `keytool` or `jarsigner` to show warnings. Good point. Updated the java.security file and the CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8300 From mullan at openjdk.java.net Fri Apr 29 20:38:53 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 29 Apr 2022 20:38:53 GMT Subject: RFR: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file In-Reply-To: <_VfTVumSISoDsIG07K5rWhin2NW-tCOfoPxshsXysb0=.99913a5d-c51a-4820-9db1-88cb346171b5@github.com> References: <_VfTVumSISoDsIG07K5rWhin2NW-tCOfoPxshsXysb0=.99913a5d-c51a-4820-9db1-88cb346171b5@github.com> Message-ID: On Fri, 29 Apr 2022 13:28:11 GMT, Weijun Wang wrote: >> I think the text above might still make some users concerned that they should always set this property. >> Maybe we can be less specific, and just say: "If you encounter compatibility issues with software that doesn't support the stronger algorithms, the system property ..." > > Can we say both? All these properties are only used when creating the file (key-related ones when creating the key). If a compatibility issue already happens, users need to downgrade their keystore. > > So, the full text will be something like > > Some legacy PKCS #12 tools or libraries do not support the new algorithms based on > PBES2 and AES. In order to create a PKCS #12 keystore for them, the system property > "keystore.pkcs12.legacy" can be set which overrides the properties defined here with > legacy algorithm. Setting this system property is equivalent to > > .... > > Also, you can downgrade an existing PKCS #12 keystore that already uses new algorithms > to use legacy algorithms with > > keytool -J-Dkeystore.pkcs12.legacy -importkeystore -srckeystore ks -destkeystore ks > > This system property should be used at your own risk. Please note there is > no value defined for this system property, i.e. "-Dkeystore.pkcs12.legacy" > has the same effect as "-Dkeystore.pkcs12.legacy=". > > I'll double check if the command can indeed downgrade key algorithms as well. *Update*: it works. All 3 algorithms (key, cert, mac) downgraded to legacy ones. It's a little long, but I can see why it is useful, so I think it's good. I would avoid the word "new" as this won't be new in a few years time. Here is an edit where I removed words which I thought were not essential: > Some PKCS #12 tools and libraries may not support algorithms based on PBES2 and AES. > To create a PKCS #12 keystore which they can load, set the system property > "keystore.pkcs12.legacy" which overrides the values of the properties defined below with > legacy algorithms. Setting this system property is equivalent to > > .... > > Also, you can downgrade an existing PKCS #12 keystore created with stronger algorithms > to legacy algorithms with > > keytool -J-Dkeystore.pkcs12.legacy -importkeystore -srckeystore ks -destkeystore ks > > This system property should be used at your own risk. Don't think you really need the sentence below, as you have already given several examples: > Please note there is > no value defined for this system property, i.e. "-Dkeystore.pkcs12.legacy" > has the same effect as "-Dkeystore.pkcs12.legacy=". ------------- PR: https://git.openjdk.java.net/jdk/pull/8452 From weijun at openjdk.java.net Fri Apr 29 20:43:42 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Apr 2022 20:43:42 GMT Subject: RFR: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file In-Reply-To: References: <_VfTVumSISoDsIG07K5rWhin2NW-tCOfoPxshsXysb0=.99913a5d-c51a-4820-9db1-88cb346171b5@github.com> Message-ID: On Fri, 29 Apr 2022 20:35:14 GMT, Sean Mullan wrote: >> Can we say both? All these properties are only used when creating the file (key-related ones when creating the key). If a compatibility issue already happens, users need to downgrade their keystore. >> >> So, the full text will be something like >> >> Some legacy PKCS #12 tools or libraries do not support the new algorithms based on >> PBES2 and AES. In order to create a PKCS #12 keystore for them, the system property >> "keystore.pkcs12.legacy" can be set which overrides the properties defined here with >> legacy algorithm. Setting this system property is equivalent to >> >> .... >> >> Also, you can downgrade an existing PKCS #12 keystore that already uses new algorithms >> to use legacy algorithms with >> >> keytool -J-Dkeystore.pkcs12.legacy -importkeystore -srckeystore ks -destkeystore ks >> >> This system property should be used at your own risk. Please note there is >> no value defined for this system property, i.e. "-Dkeystore.pkcs12.legacy" >> has the same effect as "-Dkeystore.pkcs12.legacy=". >> >> I'll double check if the command can indeed downgrade key algorithms as well. *Update*: it works. All 3 algorithms (key, cert, mac) downgraded to legacy ones. > > It's a little long, but I can see why it is useful, so I think it's good. I would avoid the word "new" as this won't be new in a few years time. Here is an edit where I removed words which I thought were not essential: > >> Some PKCS #12 tools and libraries may not support algorithms based on PBES2 and AES. >> To create a PKCS #12 keystore which they can load, set the system property >> "keystore.pkcs12.legacy" which overrides the values of the properties defined below with >> legacy algorithms. Setting this system property is equivalent to >> >> .... >> >> Also, you can downgrade an existing PKCS #12 keystore created with stronger algorithms >> to legacy algorithms with >> >> keytool -J-Dkeystore.pkcs12.legacy -importkeystore -srckeystore ks -destkeystore ks >> >> This system property should be used at your own risk. > > Don't think you really need the sentence below, as you have already given several examples: > >> Please note there is >> no value defined for this system property, i.e. "-Dkeystore.pkcs12.legacy" >> has the same effect as "-Dkeystore.pkcs12.legacy=". The reason I added the last sentence is because this property has no value. Someone might think they can set it to false to disable it, but that is equivalent to set it to true. ------------- PR: https://git.openjdk.java.net/jdk/pull/8452 From mullan at openjdk.java.net Fri Apr 29 20:50:39 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 29 Apr 2022 20:50:39 GMT Subject: RFR: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file In-Reply-To: References: <_VfTVumSISoDsIG07K5rWhin2NW-tCOfoPxshsXysb0=.99913a5d-c51a-4820-9db1-88cb346171b5@github.com> Message-ID: <63G4MsOJQItyp3v2oGQEDBKRIGD8yD-tW68chx6F_7g=.1457962a-99de-4d28-b7a2-bc0bdfb68213@github.com> On Fri, 29 Apr 2022 20:40:46 GMT, Weijun Wang wrote: >> It's a little long, but I can see why it is useful, so I think it's good. I would avoid the word "new" as this won't be new in a few years time. Here is an edit where I removed words which I thought were not essential: >> >>> Some PKCS #12 tools and libraries may not support algorithms based on PBES2 and AES. >>> To create a PKCS #12 keystore which they can load, set the system property >>> "keystore.pkcs12.legacy" which overrides the values of the properties defined below with >>> legacy algorithms. Setting this system property is equivalent to >>> >>> .... >>> >>> Also, you can downgrade an existing PKCS #12 keystore created with stronger algorithms >>> to legacy algorithms with >>> >>> keytool -J-Dkeystore.pkcs12.legacy -importkeystore -srckeystore ks -destkeystore ks >>> >>> This system property should be used at your own risk. >> >> Don't think you really need the sentence below, as you have already given several examples: >> >>> Please note there is >>> no value defined for this system property, i.e. "-Dkeystore.pkcs12.legacy" >>> has the same effect as "-Dkeystore.pkcs12.legacy=". > > The reason I added the last sentence is because this property has no value. Someone might think they can set it to false to disable it, but that is equivalent to set it to true. Ah I see. Maybe put in the previous sentence, ex: "When set, this system property (which can only be enabled and has no value) is equivalent to:" Just a suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/8452 From weijun at openjdk.java.net Fri Apr 29 21:49:32 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Apr 2022 21:49:32 GMT Subject: RFR: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file [v2] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8452/files - new: https://git.openjdk.java.net/jdk/pull/8452/files/08700389..8a24c745 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8452&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8452&range=00-01 Stats: 18 lines in 1 file changed: 7 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8452.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8452/head:pull/8452 PR: https://git.openjdk.java.net/jdk/pull/8452 From weijun at openjdk.java.net Fri Apr 29 21:49:32 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Apr 2022 21:49:32 GMT Subject: RFR: 8285827: Describe the keystore.pkcs12.legacy system property in the java.security file [v2] In-Reply-To: <63G4MsOJQItyp3v2oGQEDBKRIGD8yD-tW68chx6F_7g=.1457962a-99de-4d28-b7a2-bc0bdfb68213@github.com> References: <_VfTVumSISoDsIG07K5rWhin2NW-tCOfoPxshsXysb0=.99913a5d-c51a-4820-9db1-88cb346171b5@github.com> <63G4MsOJQItyp3v2oGQEDBKRIGD8yD-tW68chx6F_7g=.1457962a-99de-4d28-b7a2-bc0bdfb68213@github.com> Message-ID: On Fri, 29 Apr 2022 20:47:08 GMT, Sean Mullan wrote: >> The reason I added the last sentence is because this property has no value. Someone might think they can set it to false to disable it, but that is equivalent to set it to true. > > Ah I see. Maybe put in the previous sentence, ex: "When set, this system property (which can only be enabled and has no value) is equivalent to:" > > Just a suggestion. Suggested accepted. I just pushed a new commit. I modified "PKCS #12" to "PKCS12" because that's the word we used throughout the file. ------------- PR: https://git.openjdk.java.net/jdk/pull/8452 From weijun at openjdk.java.net Fri Apr 29 22:38:11 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Apr 2022 22:38:11 GMT Subject: RFR: 8285743: Ensure each IntegerPolynomial object is only created once Message-ID: 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. ------------- Commit messages: - the fix Changes: https://git.openjdk.java.net/jdk/pull/8476/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8476&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285743 Stats: 530 lines in 10 files changed: 28 ins; 465 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/8476.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8476/head:pull/8476 PR: https://git.openjdk.java.net/jdk/pull/8476 From weijun at openjdk.java.net Fri Apr 29 22:57:20 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 29 Apr 2022 22:57:20 GMT Subject: RFR: 8285743: Ensure each IntegerPolynomial object is only created once [v2] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8476/files - new: https://git.openjdk.java.net/jdk/pull/8476/files/b24ca783..331e9519 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8476&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8476&range=00-01 Stats: 54 lines in 8 files changed: 7 ins; 19 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/8476.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8476/head:pull/8476 PR: https://git.openjdk.java.net/jdk/pull/8476 From wetmore at openjdk.java.net Sat Apr 30 03:40:43 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Sat, 30 Apr 2022 03:40:43 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2] In-Reply-To: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> References: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> Message-ID: On Thu, 7 Apr 2022 20:17:28 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 two additional commits since the last revision: > > - typo blank linke correction > - revise the update Ok, after much back and forth, I'm convinced this is ok. @dfuch commented in another thread: > An application should really close its sockets and not let them get garbage collected without closing them: this is sloppy. > So brutally closing the underlying TCP connection in that case should be an acceptable behaviour, and that would be achieved by just removing the finalize. Thanks for allowing me to look more deeply into this. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8065 From wetmore at openjdk.java.net Sat Apr 30 03:49:33 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Sat, 30 Apr 2022 03:49:33 GMT Subject: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2] In-Reply-To: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> References: <6nx-XPcSWQjCe6KaFAUuEfPo-R5XnQhVVmnWJJw6EV8=.0da93dbb-9b6c-4744-b2d8-fdbb1218a341@github.com> Message-ID: On Thu, 7 Apr 2022 20:17:28 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 two additional commits since the last revision: > > - typo blank linke correction > - revise the update Marked as reviewed by wetmore (Reviewer). 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/8065 From prappo at openjdk.java.net Sat Apr 30 21:24:44 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Sat, 30 Apr 2022 21:24:44 GMT Subject: Integrated: 8285890: Fix some @param tags In-Reply-To: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com> References: <0H-WPWxCxrHNODxgpH-Ra-8UrNVXd42Oq5agm_TptAA=.266d3e78-3dac-4d39-a19a-aae6f0634258@github.com> Message-ID: On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo wrote: > * Syntactically improves a few cases from 8285676 (https://github.com/openjdk/jdk/pull/8410) > * Fixes a few misspelled `@param` tags for elements that, although are not included in the API Documentation, are visible in and processed by IDEs This pull request has now been integrated. Changeset: 3eb661bb Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/3eb661bbe7151f3a7e949b6518f57896c2bd4136 Stats: 16 lines in 8 files changed: 0 ins; 0 del; 16 mod 8285890: Fix some @param tags Reviewed-by: dfuchs, mullan, darcy, mchung, wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/8465