RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in si…
The jarsigner tool currently provides warning associated with the signer’s cert when it uses weak algorithms, but not for the CA certs. This change is to process the signer’s cert chain to warn if CA certs use weak algorithms. - Commit messages: - 8259401: Add checking to jarsigner to warn weak algorithms used in signer’s cert chain Changes: https://git.openjdk.java.net/jdk/pull/2042/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2042=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259401 Stats: 125 lines in 2 files changed: 124 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2042.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2042/head:pull/2042 PR: https://git.openjdk.java.net/jdk/pull/2042
RFR: 8256895: Add support for RFC 8954: Online Certificate Status Protocol…
This enhancement adds support for the nonce extension in OCSP request extensions by system property jdk.security.certpath.ocspNonce. Please review the CSR at: https://bugs.openjdk.java.net/browse/JDK-8257766 - Commit messages: - 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension Changes: https://git.openjdk.java.net/jdk/pull/2039/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2039=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256895 Stats: 108 lines in 6 files changed: 89 ins; 1 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/2039.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2039/head:pull/2039 PR: https://git.openjdk.java.net/jdk/pull/2039
Integrated: 8259582: Backout JDK-8237578 until all affected tests have been fixed
On Mon, 11 Jan 2021 19:25:28 GMT, Volker Simonis wrote: > [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) caused a few > internal and external tests to fail (see > [JDK-8259572](https://bugs.openjdk.java.net/browse/JDK-8259572)). > > Backout [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) and > redo it properly such that it doesn't cause any test failures. This pull request has now been integrated. Changeset: e9929e2b Author:Volker Simonis URL: https://git.openjdk.java.net/jdk/commit/e9929e2b Stats: 182 lines in 5 files changed: 0 ins; 175 del; 7 mod 8259582: Backout JDK-8237578 until all affected tests have been fixed Reviewed-by: xuelei - PR: https://git.openjdk.java.net/jdk/pull/2035
Re: RFR: 8259582: Backout JDK-8237578 until all affected tests have been fixed
On Mon, 11 Jan 2021 19:25:28 GMT, Volker Simonis wrote: > [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) caused a few > internal and external tests to fail (see > [JDK-8259572](https://bugs.openjdk.java.net/browse/JDK-8259572)). > > Backout [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) and > redo it properly such that it doesn't cause any test failures. @simonis - are you planning to integrate this soon? - PR: https://git.openjdk.java.net/jdk/pull/2035
Re: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes [v2]
On Fri, 8 Jan 2021 21:30:14 GMT, Martin Balao wrote: >> As described in JDK-8259319 [1], this fix proposal is to set proper access >> permissions so the SunPKCS11 provider can create instances of SunJCE classes >> when a Security Manager is installed and the fallback scheme is used. >> >> No regressions found in jdk/sun/security/pkcs11 tests category. >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 > > Martin Balao has updated the pull request incrementally with two additional > commits since the last revision: > > - Limit P11Util::getProvider privileged access to the required > 'accessClassInPackage' RuntimePermission only. > - New line character inserted at the end of IllegalPackageAccess.java test > file Marked as reviewed by mullan (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1961
Re: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures
On Fri, 8 Jan 2021 19:28:55 GMT, Martin Balao wrote: > The P11Cipher case is different because the size of the output buffer (the > one that may lead to a CKR_BUFFER_TOO_SMALL error) is a user input and the > error visible to OpenJDK Java code [4] [5] [6] [7]. In addition, and contrary > to the PKCS#11 v2.20 standard -which states "A call to C_EncryptUpdate which > results in an error other than CKR_BUFFER_TOO_SMALL terminates the current > encryption operation."-, the NSS Software Token may not terminate the > operation on other error types [8] [9]. This is why we need to always cancel > from P11Cipher. For cipher impls, there are more than just P11Cipher, there are also P11AEADCipher and P11RSACipher. It looks like they should be updated with this defensive cancellation change unless the non-compliant NSS impl is algorithm-specific and does not apply to AES/GCM and RSA. - PR: https://git.openjdk.java.net/jdk/pull/1901
Re: RFR: 8259582: Backout JDK-8237578 until all affected tests have been fixed
On Mon, 11 Jan 2021 19:25:28 GMT, Volker Simonis wrote: > [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) caused a few > internal and external tests to fail (see > [JDK-8259572](https://bugs.openjdk.java.net/browse/JDK-8259572)). > > Backout [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) and > redo it properly such that it doesn't cause any test failures. Looks good to me. Thank you very much! - Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2035
Re: RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures
On Fri, 8 Jan 2021 19:28:55 GMT, Martin Balao wrote: >>> In summary, I believe we need changes in the OpenJDK side to properly >>> handle CKR_BUFFER_TOO_SMALL errors when C_SignFinal or C_Sign PKCS#11 >>> functions are called from P11Signature. Even if other error types or >>> functions such as C_VerifyFinal, C_Verify, NSC_SignUpdate and >>> NSC_VerifyUpdate should not need an explicit cancel; we might want to do it >>> anyways to be more defensive and do not depend on a specific NSS >>> implementation. >>> >> >> I'm not entirely sure that we can trigger the CKR_BUFFER_TOO_SMALL potential >> bug from OpenJDK because the output buffer is allocated in the OpenJDK >> native code [1] for C_Sign and the length is equal to 4K [2]. In the case of >> C_SignFinal, the CKR_BUFFER_TOO_SMALL error is handled in native code [3]. >> >> My understanding is that we still want to be defensive here, and do not >> depend on a specific NSS version that may leak active operations on some >> types of errors. The difference is that this change in P11Signature won't >> have a regression test. >> >> @valeriepeng are you okay with this reasoning? >> >> -- >> [1] - >> https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_sign.c#L142 >> [2] - >> https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h#L166 >> [3] - >> https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_sign.c#L252 > >> >> @valeriepeng are you okay with this reasoning? >> > > I changed my mind around this decision and I'm inclined not to make any code > changes to P11Signature. Only a documentation note that reflects this > analysis should be needed. > > First of all, what I described here [1], about the NSS Software Token > behavior, matches the PKCS#11 v2.20 standard [2]: > > 1) "A call to C_SignFinal always terminates the active signing operation > unless it returns CKR_BUFFER_TOO_SMALL or is a successful call"; and, > > 2) "A call to C_Sign always terminates the active signing operation unless > it returns CKR_BUFFER_TOO_SMALL". > > In addition, as described here [3], CKR_BUFFER_TOO_SMALL is not expected to > reach P11Signature Java code because it's handled by the libj2pkcs11 OpenJDK > native library. Thus, cancelling a potentially active operation is not > required by the standard nor needed. If we find a non-compliant > implementation of the PKCS#11 standard in the future, we might want to > revisit this decision. > > Even if the performance cost of cancelling an operation 'just in case' should > be affordable, we might unnecessarily get into errors such as > CKR_OPERATION_NOT_INITIALIZED. > > The P11Cipher case is different because the size of the output buffer (the > one that may lead to a CKR_BUFFER_TOO_SMALL error) is a user input and the > error visible to OpenJDK Java code [4] [5] [6] [7]. In addition, and contrary > to the PKCS#11 v2.20 standard -which states "A call to C_EncryptUpdate which > results in an error other than CKR_BUFFER_TOO_SMALL terminates the current > encryption operation."-, the NSS Software Token may not terminate the > operation on other error types [8] [9]. This is why we need to always cancel > from P11Cipher. > > -- > [1] - https://git.openjdk.java.net/jdk/pull/1901#issuecomment-756312031 > [2] - > https://www.cryptsoft.com/pkcs11doc/v220/group__SEC__11__11__SIGNING__AND__MACING__FUNCTIONS.html > [3] - https://git.openjdk.java.net/jdk/pull/1901#issuecomment-756376546 > [4] - > https://github.com/openjdk/jdk/blob/cd94606c0c2dbf0a7f6d08dcc27f787ed080ac15/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c#L280 > [5] - > https://github.com/openjdk/jdk/blob/cd94606c0c2dbf0a7f6d08dcc27f787ed080ac15/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c#L228 > [6] - > https://github.com/openjdk/jdk/blob/cd94606c0c2dbf0a7f6d08dcc27f787ed080ac15/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c#L463 > [7] - > https://github.com/openjdk/jdk/blob/cd94606c0c2dbf0a7f6d08dcc27f787ed080ac15/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c#L514 > [8] - > https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L1356 > [9] - > https://github.com/nss-dev/nss/blob/561b982921f15902088a3f05b1cdf561f5f64cb7/lib/softoken/pkcs11c.c#L1380 Sure, the reason that I brought up about other classes besides P11Cipher is to confirm/check whether NSS impl conforms to the PKCS#11 spec for all these calls where the same cancellation pattern is used. If NSS impl follows the PKCS#11 spec, that's fine and it's safer to not change the existing code. - PR: https://git.openjdk.java.net/jdk/pull/1901
RFR: 8259582: Backout JDK-8237578 until all affected tests have been fixed
[JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) caused a few internal and external tests to fail (see [JDK-8259572](https://bugs.openjdk.java.net/browse/JDK-8259572)). Backout [JDK-8237578](https://bugs.openjdk.java.net/browse/JDK-8237578) and redo it properly such that it doesn't cause any test failures. - Commit messages: - 8259582: Backout JDK-8237578 until all affected tests have been fixed Changes: https://git.openjdk.java.net/jdk/pull/2035/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2035=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259582 Stats: 182 lines in 5 files changed: 0 ins; 175 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2035.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2035/head:pull/2035 PR: https://git.openjdk.java.net/jdk/pull/2035
Withdrawn: 8259572: [test] Fix SSL tests after JDK-8237578 to properly handle SocketExceptions
On Mon, 11 Jan 2021 17:24:23 GMT, Volker Simonis wrote:
> JDK-8237578 exposes some SocketExceptions directly which were previously
> wrapped inside an SSLException. The change updated one test to take this new
> behaviour into account (i.e. TrustTrustedCert.java) but apparently missed
> other tests.
>
> The fix for the other tests is similar like the fix for TrustTrustedCert.java
> in JDK-8237578:
> - } catch (SSLException ssle) {
> + } catch (SSLException | SocketException se) {
> if (!expectFail) {
> -throw ssle;
> +throw se;
> } // Otherwise, ignore.
> }
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jdk/pull/2029
Re: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes [v2]
On Fri, 8 Jan 2021 21:30:14 GMT, Martin Balao wrote: >> As described in JDK-8259319 [1], this fix proposal is to set proper access >> permissions so the SunPKCS11 provider can create instances of SunJCE classes >> when a Security Manager is installed and the fallback scheme is used. >> >> No regressions found in jdk/sun/security/pkcs11 tests category. >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 > > Martin Balao has updated the pull request incrementally with two additional > commits since the last revision: > > - Limit P11Util::getProvider privileged access to the required > 'accessClassInPackage' RuntimePermission only. > - New line character inserted at the end of IllegalPackageAccess.java test > file Changes look good. - Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1961
Re: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 [v3]
On Mon, 11 Jan 2021 17:31:38 GMT, Weijun Wang wrote: >> Marked as reviewed by xuelei (Reviewer). > > I've force pushed a new series of commits from scratch. The difference: > > 1. The `s/Portions copyright/Copyright/` change is inside auto import. > 2. Some `s/Sun Microsystems/Oracle/` change in auto import > 3. No more deprecated `newInstance()` calls, a new (the last one) commit is > created for this A CSR at https://bugs.openjdk.java.net/browse/JDK-8259575 is created. I'll remember to update the `@since 16` in source to 17 some time. - PR: https://git.openjdk.java.net/jdk/pull/1206
Re: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 [v3]
On Sun, 10 Jan 2021 05:17:23 GMT, Xue-Lei Andrew Fan wrote: >> Weijun Wang has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 13 commits: >> >> - No more newInstance calls >> - Support RSA-PSS with parameters >> - Reapply 829: Leak File Descriptors Because of >> ResolverLocalFilesystem#engineResolveURI() >> - Fix test failures >> - Supporting named RSASSA-PSS without parameters >> - Reapply 8008744: Rework part of fix for JDK-6741606 >> - Reapply 8151893: Add security property to configure XML Signature secure >> validation mode >> >>Reapply 8140353: Improve signature checking >> - Reapply Reapply 8042967: Add variant of DSA Signature algorithms that do >> not ASN.1 encode the signature bytes >> - Reapply 8038913: Bolster XML support (Init.java part) >> - Various warnings, the version, and abnormal copyright lines >> - ... and 3 more: >> https://git.openjdk.java.net/jdk/compare/19bade02...f7ee7648 > > Marked as reviewed by xuelei (Reviewer). I've force pushed a new series of commits from scratch. The difference: 1. The `s/Portions copyright/Copyright/` change is inside auto import. 2. Some `s/Sun Microsystems/Oracle/` change in auto import 3. No more deprecated `newInstance()` calls, a new (the last one) commit is created for this - PR: https://git.openjdk.java.net/jdk/pull/1206
Re: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 [v3]
> This is a multi-commits PR that upgrades xmldsig to be equivalent to > Santuario 2.2.0. > > The first step is an auto-import. The JDK implementation is removed first and > Santuario code are imported. Some unrelated files (Ex: encryption) are > removed, and package names are renamed to be internal. There are also some > bulk changes on company name, comment style, and white spaces. > > Next steps are patches applied by JDK. Some are old patches before the last > import. Some are new. > > Several tests need to be updated because of internal method signature changes. > > The "Support RSA-PSS with parameters" commit introduces a new public API and > would need a CSR. > > The last patch is one we just fixed several days ago. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - No more newInstance calls - Support RSA-PSS with parameters - Reapply 829: Leak File Descriptors Because of ResolverLocalFilesystem#engineResolveURI() - Fix test failures - Supporting named RSASSA-PSS without parameters - Reapply 8008744: Rework part of fix for JDK-6741606 - Reapply 8151893: Add security property to configure XML Signature secure validation mode Reapply 8140353: Improve signature checking - Reapply Reapply 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes - Reapply 8038913: Bolster XML support (Init.java part) - Various warnings, the version, and abnormal copyright lines - ... and 3 more: https://git.openjdk.java.net/jdk/compare/3ab6657f...f7ee7648 - Changes: - all: https://git.openjdk.java.net/jdk/pull/1206/files - new: https://git.openjdk.java.net/jdk/pull/1206/files/73c73381..f7ee7648 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1206=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1206=01-02 Stats: 124959 lines in 1924 files changed: 67184 ins; 45132 del; 12643 mod Patch: https://git.openjdk.java.net/jdk/pull/1206.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1206/head:pull/1206 PR: https://git.openjdk.java.net/jdk/pull/1206
RFR: 8259572: [test] Fix SSL tests after JDK-8237578 to properly handle SocketExceptions
JDK-8237578 exposes some SocketExceptions directly which were previously
wrapped inside an SSLException. The change updated one test to take this new
behaviour into account (i.e. TrustTrustedCert.java) but apparently missed other
tests.
The fix for the other tests is similar like the fix for TrustTrustedCert.java
in JDK-8237578:
- } catch (SSLException ssle) {
+ } catch (SSLException | SocketException se) {
if (!expectFail) {
-throw ssle;
+throw se;
} // Otherwise, ignore.
}
-
Commit messages:
- 8259572: [test] Fix SSL tests after JDK-8237578 to properly handle
SocketExceptions
Changes: https://git.openjdk.java.net/jdk/pull/2029/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2029=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8259572
Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
Patch: https://git.openjdk.java.net/jdk/pull/2029.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/2029/head:pull/2029
PR: https://git.openjdk.java.net/jdk/pull/2029
Re: RFR: 8253635: Implement toString() for SSLEngineImpl
On Mon, 11 Jan 2021 04:57:19 GMT, Xue-Lei Andrew Fan wrote: > The SSLSocketImpl and SSLEngineImpl implementation does not override the > toString() method. The old code did. BTW, I also made a few code clean up > in the SSLSocketImpl.java. > > Code clean up, trivial update, no new regression test. Looks good - Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2019
Re: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v6]
On Mon, 11 Jan 2021 12:00:09 GMT, Volker Simonis wrote: >> Clive Verghese has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. > > Looks good to me. This change caused some new test failures (e.g. in `java/net/httpclient/InvalidSSLContextTest.java` or `javax/net/ssl/SSLSession/TestEnabledProtocols.java`). I'm currently working on a PR which will fix these tests... - PR: https://git.openjdk.java.net/jdk/pull/1968
Integrated: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed
On Wed, 6 Jan 2021 23:28:34 GMT, Clive Verghese wrote: > This PR aims to revert some more cases where SocketExceptions are improperly > being wrapped as SSLException. Some work for this was done in > [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that > change did not cover all the cases. > > As it was mentioned in JDK-8235263, some applications rely on receiving > SocketException to decide if the connection should be retried. An example of > this would be Apache HTTP client. This PR should ideally fix > https://issues.apache.org/jira/browse/HTTPCLIENT-2032 This pull request has now been integrated. Changeset: 01b2804e Author:Clive Verghese Committer: Volker Simonis URL: https://git.openjdk.java.net/jdk/commit/01b2804e Stats: 182 lines in 5 files changed: 175 ins; 0 del; 7 mod 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed Reviewed-by: xuelei, simonis - PR: https://git.openjdk.java.net/jdk/pull/1968
Re: RFR: 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed [v6]
On Sun, 10 Jan 2021 06:56:17 GMT, Clive Verghese wrote: >> This PR aims to revert some more cases where SocketExceptions are improperly >> being wrapped as SSLException. Some work for this was done in >> [JDK-8235263](https://bugs.openjdk.java.net/browse/JDK-8235263), but that >> change did not cover all the cases. >> >> As it was mentioned in JDK-8235263, some applications rely on receiving >> SocketException to decide if the connection should be retried. An example of >> this would be Apache HTTP client. This PR should ideally fix >> https://issues.apache.org/jira/browse/HTTPCLIENT-2032 > > Clive Verghese has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared to the previous content of the PR. Looks good to me. - Marked as reviewed by simonis (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1968
Re: RFR: 8257733: Move module-specific data from make to respective module [v4]
On Mon, 4 Jan 2021 21:20:53 GMT, Phil Race wrote: >> Magnus Ihse Bursie 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: >> >> - Update comment refering to "make" dir >> - Move new symbols to jdk.compiler >> - Merge branch 'master' into shuffle-data >> - Move macosxicons from share to macosx >> - Move to share/data, and move jdwp.spec to java.se >> - Update references in test >> - Step 2: Update references >> - First stage, move actual data files > > Marked as reviewed by prr (Reviewer). This PR is not stale; it's just still waiting for input from @AlanBateman. - PR: https://git.openjdk.java.net/jdk/pull/1611
