Re: RFR: 8277307: Pre shared key sent under both session_ticket and pre_shared_key extensions [v2]
On Thu, 2 Jun 2022 21:02:16 GMT, Daniel Jeliński wrote: >> Session ticket extension should only contain pre-TLS1.3 stateless session >> tickets; it should not be used for sending TLS1.3 pre-shared keys. > > Daniel Jeliński has updated the pull request incrementally with one > additional commit since the last revision: > > different check for TLS13 Looks good to me - Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8922
Re: RFR: 8277307: Pre shared key sent under both session_ticket and pre_shared_key extensions
On Fri, 27 May 2022 13:20:24 GMT, Daniel Jeliński wrote:
> Session ticket extension should only contain pre-TLS1.3 stateless session
> tickets; it should not be used for sending TLS1.3 pre-shared keys.
src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line
410:
> 408: || chc.resumingSession.getPskIdentity() == null
> 409: || !Arrays.asList(ProtocolVersion.PROTOCOLS_10_12)
> 410:
> .contains(chc.resumingSession.getProtocolVersion())) {
would `chc.resumingSession.getProtocolVersion().useTLS13PlusSpec()` read
better for your last condition ? Might save on Array allocations also ?
-
PR: https://git.openjdk.java.net/jdk/pull/8922
Re: RFR: 8286433: Cache certificates decoded from TLS session tickets
On Mon, 9 May 2022 19:38:36 GMT, Daniel Jeliński wrote: > When a TLS server resumes a session from a stateless session ticket, it > populates the `SSLSessionImpl`'s `localCerts` and `peerCerts` fields with > certificates deserialized from the session ticket. These certificates are > often the same across a large number of tickets. > > This patch implements a certificate cache lookup for these certificates. This > enables us to avoid deserializing the same certificates repeatedly, and saves > memory by reusing the same certificate objects. Nice work. LGTM. - Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8608
Re: RFR: 8285398: Cache the results of constraint checks
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
Re: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice
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) 1637100 % boolean java.lang.String.regionMatches(boolean, int, String, int, int) 1637 100 % boolean java.lang.String.equalsIgnoreCase(String) 1637100 % boolean sun.security.util.AbstractAlgorithmConstraints.checkAlgorithm(List, String, AlgorithmDecomposer)163199.6 % boolean sun.security.util.DisabledAlgorithmConstraints.permits(Set, String, AlgorithmParameters)163199.6 % boolean sun.security.ssl.SSLAlgorithmConstraints.permits(Set, String, AlgorithmParameters) 163199.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
Re: RFR: 8284415: Collapse identical catch branches in security libs
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
Re: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368
On Sat, 12 Mar 2022 00:55:07 GMT, Bradford Wetmore wrote: > JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal > internal_error (80) and invalidate existing sessions (either completed or > under construction) as described in (RFC 4346/TLSv1.1+) if a connection was > closed without receiving a close_notify alert from the peer. > > This change introduces similar behavior to SSLEngine. > > The unit test checks that closing the read(input) sides of the > SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their > respective sessions. > > Tier1/2 mach5 tests have been successfully run. Marked as reviewed by coffeys (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7796
Re: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368
On Tue, 22 Mar 2022 00:24:41 GMT, Bradford Wetmore wrote: >> test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketSSLEngineCloseInbound.java >> line 130: >> >>> 128: * The following is to set up the keystores/trust material. >>> 129: */ >>> 130: private static final String pathToStores = >>> "../../../../javax/net/ssl/etc"; >> >> I think the advise is to move away from binary style keystores. i.e. to use >> test/jdk/javax/net/ssl/templates/SSLContextTemplate.java for a replacement. >> Is that possible here ? > > Sigh...this is a whole can of worms I wasn't expecting. Looks like one > person did the SSLContextTemplate and updated with SSLEngineTemplate, then > another person took a completely different takes with SSLSocketTemplate, and > then SSLSocketSSLEngineTemplate didn't get touched at all. > > This should really be harmonized. :( ouch - maybe this should be fixed up in a separate bug then. Don't think it should be a blocker for this fix - PR: https://git.openjdk.java.net/jdk/pull/7796
Re: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368
On Sat, 12 Mar 2022 00:55:07 GMT, Bradford Wetmore wrote: > JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal > internal_error (80) and invalidate existing sessions (either completed or > under construction) as described in (RFC 4346/TLSv1.1+) if a connection was > closed without receiving a close_notify alert from the peer. > > This change introduces similar behavior to SSLEngine. > > The unit test checks that closing the read(input) sides of the > SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their > respective sessions. > > Tier1/2 mach5 tests have been successfully run. test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketSSLEngineCloseInbound.java line 130: > 128: * The following is to set up the keystores/trust material. > 129: */ > 130: private static final String pathToStores = > "../../../../javax/net/ssl/etc"; I think the advise is to move away from binary style keystores. i.e. to use test/jdk/javax/net/ssl/templates/SSLContextTemplate.java for a replacement. Is that possible here ? - PR: https://git.openjdk.java.net/jdk/pull/7796
Re: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs
On Thu, 13 Jan 2022 13:56:14 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java >> line 212: >> >>> 210: >>> 211: CodeSigner[] entrySigners = sigFileSigners.get(name); >>> 212: Map permittedAlgs = >> >> maybe permittedAlgsChecker as variable name ? the Map contains both >> permitted and non-permitted algs. > > `Checker` sounds like it going to do something. But I agree the name could be > better. I was mostly being consistent with the `permittedAlgs` variable in > `SignatureFileVerifier`. Maybe `algsPermittedStatus`? yes, algsPermittedStatus sounds better. Thanks. >> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java >> line 239: >> >>> 237: >>> 238: // A non-disabled algorithm was used. >>> 239: disabledAlgs = false; >> >> this usage doesn't seem right. I think it's always set to false no matter >> what algs are detected. > > If all algs are disabled, it will never get here, because it will either > continue on line 231 or 234. Ah yes - I was reading the scope of for loop incorrectly. Thanks for clarifying! - PR: https://git.openjdk.java.net/jdk/pull/7056
Re: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs
On Wed, 12 Jan 2022 21:57:22 GMT, Sean Mullan wrote: > If a JAR is signed with multiple digest algorithms and one of the digest > algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly > returning null indicating that the jar entry has no signers. > > This fixes the issue such that an entry is considered signed if at least one > of the digest algorithms is not disabled and the digest match passes. This > makes the fix consistent with how multiple digest algorithms are handled in > the Signature File. This also fixes an issue in the > `ManifestEntryVerifier.getParams()` method in which it was incorrectly > checking the algorithm constraints against all signers of a JAR when it > should check them only against the signers of the entry that is being > verified. > > An additional cache has also been added to avoid checking if the digest > algorithm is disabled more than once for entries signed by the same set of > signers. Marked as reviewed by coffeys (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7056
Re: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs
On Wed, 12 Jan 2022 21:57:22 GMT, Sean Mullan wrote: > If a JAR is signed with multiple digest algorithms and one of the digest > algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly > returning null indicating that the jar entry has no signers. > > This fixes the issue such that an entry is considered signed if at least one > of the digest algorithms is not disabled and the digest match passes. This > makes the fix consistent with how multiple digest algorithms are handled in > the Signature File. This also fixes an issue in the > `ManifestEntryVerifier.getParams()` method in which it was incorrectly > checking the algorithm constraints against all signers of a JAR when it > should check them only against the signers of the entry that is being > verified. > > An additional cache has also been added to avoid checking if the digest > algorithm is disabled more than once for entries signed by the same set of > signers. src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 212: > 210: > 211: CodeSigner[] entrySigners = sigFileSigners.get(name); > 212: Map permittedAlgs = maybe permittedAlgsChecker as variable name ? the Map contains both permitted and non-permitted algs. src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line 239: > 237: > 238: // A non-disabled algorithm was used. > 239: disabledAlgs = false; this usage doesn't seem right. I think it's always set to false no matter what algs are detected. - PR: https://git.openjdk.java.net/jdk/pull/7056
Integrated: 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE
On Wed, 17 Nov 2021 16:00:04 GMT, Sean Coffey wrote: > Some elements of the PKCS9Attribute.PKCS9_OIDS array may have null value. The > PKCS9Attributes.toString() and PKCS9Attributes.getAttributes() methods need > to account for that. This pull request has now been integrated. Changeset: 6bb04626 Author:Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/6bb04626af6574ef1e8d4b7dad0389d4b59f5d08 Stats: 16 lines in 2 files changed: 11 ins; 2 del; 3 mod 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE Reviewed-by: weijun - PR: https://git.openjdk.java.net/jdk/pull/6433
Re: RFR: 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE [v2]
> Some elements of the PKCS9Attribute.PKCS9_OIDS array may have null value. The > PKCS9Attributes.toString() and PKCS9Attributes.getAttributes() methods need > to account for that. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: test update - Changes: - all: https://git.openjdk.java.net/jdk/pull/6433/files - new: https://git.openjdk.java.net/jdk/pull/6433/files/9755fa81..a134fab5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6433=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6433=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6433.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6433/head:pull/6433 PR: https://git.openjdk.java.net/jdk/pull/6433
Re: RFR: 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE
On Wed, 17 Nov 2021 16:52:46 GMT, Weijun Wang wrote: >> Some elements of the PKCS9Attribute.PKCS9_OIDS array may have null value. >> The PKCS9Attributes.toString() and PKCS9Attributes.getAttributes() methods >> need to account for that. > > test/jdk/sun/security/x509/AlgorithmId/NonStandardNames.java line 67: > >> 65: // test PKCS9Attributes.toString(), >> PKCS9Attributes.getAttributes() >> 66: System.out.println(authed); >> 67: authed.getAttributes(); > > Looks like the old `getAttributes()` would only throw NPE if one of the > attribute is of a type after `PKCS9_OIDS[10]`. Yes - its also bounded by the "attribs.length" check. I initially thought I'd have to build an PKCS9Attributes Object consisting of 10/11+ PKCS9Attribute Objects. That didn't seem feasible since many are not supported. but on re-read, yes, all I need to do is stick in an OID > PKCS9_OIDS[10] - I'll update the testcase. - PR: https://git.openjdk.java.net/jdk/pull/6433
RFR: 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE
Some elements of the PKCS9Attribute.PKCS9_OIDS array may have null value. The PKCS9Attributes.toString() and PKCS9Attributes.getAttributes() methods need to account for that. - Commit messages: - 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE Changes: https://git.openjdk.java.net/jdk/pull/6433/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6433=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277224 Stats: 15 lines in 2 files changed: 10 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6433.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6433/head:pull/6433 PR: https://git.openjdk.java.net/jdk/pull/6433
Integrated: 8273826: Correct Manifest file name and NPE checks
On Wed, 6 Oct 2021 16:58:51 GMT, Sean Coffey wrote: > Use correct manifest file name in the Manifest verifier checks. > Also - extra null check > > The test doesn't reproduce the exact issue reported but should prevent future > regressions in this area. This pull request has now been integrated. Changeset: 03a8d342 Author:Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/03a8d342b86e720d3cba08d540182b4ab161fba3 Stats: 139 lines in 5 files changed: 128 ins; 2 del; 9 mod 8273826: Correct Manifest file name and NPE checks Reviewed-by: weijun, hchao, mullan - PR: https://git.openjdk.java.net/jdk/pull/5841
Re: RFR: 8273826: Correct Manifest file name and NPE checks [v2]
On Thu, 7 Oct 2021 14:57:53 GMT, Sean Mullan wrote: >> Sean Coffey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Make variables final > > test/jdk/sun/security/tools/jarsigner/warnings/LowerCaseManifest.java line 38: > >> 36: * @library /test/lib ../ >> 37: * @build jdk.test.lib.util.JarUtils >> 38: * @run main LowerCaseManifest > > You don't need this line as this is the default @run setting. Looks like it's required if there's a @build directive - PR: https://git.openjdk.java.net/jdk/pull/5841
Re: RFR: 8273826: Correct Manifest file name and NPE checks [v2]
On Wed, 6 Oct 2021 17:54:15 GMT, Weijun Wang wrote: >> Sean Coffey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Make variables final > > src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java line > 66: > >> 64: >> 65: private String name = null; >> 66: private String manifestFileName; > > Make this final and add a comment that it will never be null. Thanks for the review - Made final and added comment. Also decided to make the "Manifest man" variable final here also while here. - PR: https://git.openjdk.java.net/jdk/pull/5841
Re: RFR: 8273826: Correct Manifest file name and NPE checks [v2]
> Use correct manifest file name in the Manifest verifier checks. > Also - extra null check > > The test doesn't reproduce the exact issue reported but should prevent future > regressions in this area. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Make variables final - Changes: - all: https://git.openjdk.java.net/jdk/pull/5841/files - new: https://git.openjdk.java.net/jdk/pull/5841/files/a63c81ad..3d72a6d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5841=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5841=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5841.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5841/head:pull/5841 PR: https://git.openjdk.java.net/jdk/pull/5841
RFR: 8273826: Correct Manifest file name and NPE checks
Use correct manifest file name in the Manifest verifier checks. Also - extra null check The test doesn't reproduce the exact issue reported but should prevent future regressions in this area. - Commit messages: - 8273826: Correct Manifest file name and NPE checks Changes: https://git.openjdk.java.net/jdk/pull/5841/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5841=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273826 Stats: 137 lines in 5 files changed: 127 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5841.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5841/head:pull/5841 PR: https://git.openjdk.java.net/jdk/pull/5841
Integrated: 8270344: Session resumption errors
On Fri, 13 Aug 2021 14:00:45 GMT, Sean Coffey wrote: > Corner case where a session resumption can fail if the TLS server changes > supported protocol versions in relation to a cached SSLSession. This is > primarily an issue where the legacy TLS version is used in place of the newer > "supported_versions" TLS extension. This pull request has now been integrated. Changeset: 04a806ec Author:Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/04a806ec86a388b8de31d42f904c4321beb69e14 Stats: 185 lines in 4 files changed: 162 ins; 21 del; 2 mod 8270344: Session resumption errors Reviewed-by: xuelei - PR: https://git.openjdk.java.net/jdk/pull/5110
Re: RFR: 8270344: Session resumption errors [v4]
On Thu, 19 Aug 2021 19:51:36 GMT, Xue-Lei Andrew Fan wrote:
>> Sean Coffey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> maxProtocolVersion refactoring
>
> test/jdk/sun/security/ssl/SSLSessionImpl/InvalidateSession.java line 60:
>
>> 58: System.setProperty("javax.net.ssl.keyStorePassword", passwd);
>> 59: System.setProperty("javax.net.ssl.trustStore", trustFilename);
>> 60: System.setProperty("javax.net.ssl.trustStorePassword", passwd);
>
> It is not recommended to use the binary key store files for JSSE test cases.
> Please refer to test/jdk/javax/net/ssl/templates/SSLContextTemplate.java for
> a replacement.
Good suggestion - done.
> test/jdk/sun/security/ssl/SSLSessionImpl/InvalidateSession.java line 173:
>
>> 171: }
>> 172: }
>> 173: }
>
> Is a new line required in the end of file? I see red symbol in the review
> board, I think the symbol may be generated by the GitHub.
not sure it matters, but added a new line
-
PR: https://git.openjdk.java.net/jdk/pull/5110
Re: RFR: 8270344: Session resumption errors [v5]
On Thu, 19 Aug 2021 19:48:15 GMT, Xue-Lei Andrew Fan wrote: >> Sean Coffey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove redundant method and testcase cleanup > > src/java.base/share/classes/sun/security/ssl/ClientHello.java line 547: > >> 545: // handshake output stream, so that the output >> records >> 546: // (at the record layer) have the correct version >> 547: chc.setVersion(sessionVersion); > > The removing of the call to "setVersion()" has an impact, I think. I think > the declaration of this method could be removed in HandshakeContext class, > and set the HandshakeContext.conContext.protocolVersion to > HandshakeContext.maximumActiveProtocol in the HandshakeContext.initialize() > method. I've removed the (now) redundant setVersion(..) method. With respect to initialize() method we already set HandshakeContext.conContext.protocolVersion to HandshakeContext.maximumActiveProtocol in the case of a new session. Is that what you were aiming at ? https://github.com/openjdk/jdk/blob/1ea437a4b87381b558cf8157ac52fc03e37ac507/src/java.base/share/classes/sun/security/ssl/HandshakeContext.java#L261 - PR: https://git.openjdk.java.net/jdk/pull/5110
Re: RFR: 8270344: Session resumption errors [v5]
> Corner case where a session resumption can fail if the TLS server changes > supported protocol versions in relation to a cached SSLSession. This is > primarily an issue where the legacy TLS version is used in place of the newer > "supported_versions" TLS extension. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Remove redundant method and testcase cleanup - Changes: - all: https://git.openjdk.java.net/jdk/pull/5110/files - new: https://git.openjdk.java.net/jdk/pull/5110/files/c12551ad..b32a69cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5110=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5110=03-04 Stats: 52 lines in 3 files changed: 10 ins; 31 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5110/head:pull/5110 PR: https://git.openjdk.java.net/jdk/pull/5110
Re: RFR: 8270344: Session resumption errors [v4]
> Corner case where a session resumption can fail if the TLS server changes > supported protocol versions in relation to a cached SSLSession. This is > primarily an issue where the legacy TLS version is used in place of the newer > "supported_versions" TLS extension. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: maxProtocolVersion refactoring - Changes: - all: https://git.openjdk.java.net/jdk/pull/5110/files - new: https://git.openjdk.java.net/jdk/pull/5110/files/86ae055f..c12551ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5110=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5110=02-03 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5110/head:pull/5110 PR: https://git.openjdk.java.net/jdk/pull/5110
Re: RFR: 8270344: Session resumption errors [v3]
> Corner case where a session resumption can fail if the TLS server changes > supported protocol versions in relation to a cached SSLSession. This is > primarily an issue where the legacy TLS version is used in place of the newer > "supported_versions" TLS extension. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Remove whitespace in test - Changes: - all: https://git.openjdk.java.net/jdk/pull/5110/files - new: https://git.openjdk.java.net/jdk/pull/5110/files/0a24d520..86ae055f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5110=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5110=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5110/head:pull/5110 PR: https://git.openjdk.java.net/jdk/pull/5110
Re: RFR: 8272674: Logging missing keytab file in Krb5LoginModule
On Wed, 18 Aug 2021 22:33:42 GMT, Weijun Wang wrote: > The "Key for the principal foo...@acme.com not available in > /home/foobar/foobar.keytab" debug output does not contain enough information. > The keytab file might be missing, or not readable, or does not contain the > required key(s). > > Please note that this debug info is only visible when > `-Dsun.security.krb5.debug=true` is added on the command line. > > Fix is trivial. No new regression test needed. Looks fine - Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5176
Re: RFR: 8270344: Session resumption errors
On Wed, 18 Aug 2021 19:03:10 GMT, djelinski wrote: >> Corner case where a session resumption can fail if the TLS server changes >> supported protocol versions in relation to a cached SSLSession. This is >> primarily an issue where the legacy TLS version is used in place of the >> newer "supported_versions" TLS extension. > > Also fixes resumption when server is a Java application run with > `-Djdk.tls.allowLegacyResumption=false`, client is a Java application with > `-Djdk.tls.useExtendedMasterSecret=false`, and TLSv1.2 is negotiated. > As a side note, it should be possible to merge > `HandshakeContext#handshakeSession` and `HandshakeContext#resumingSession` > into a single field now thanks for the comments @djelinski - per Dev advise, I've split this issue into 2 bugs. This issue will focus on altering the legacy maximum TLS protocol version field sent in the ClientHello. Patch just updated. A follow on fix will focus on the session invalidation issue (JDK-8272653) - PR: https://git.openjdk.java.net/jdk/pull/5110
Re: RFR: 8270344: Session resumption errors [v2]
> Corner case where a session resumption can fail if the TLS server changes > supported protocol versions in relation to a cached SSLSession. This is > primarily an issue where the legacy TLS version is used in place of the newer > "supported_versions" TLS extension. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Alter fix to focus on max version sent in CH - Changes: - all: https://git.openjdk.java.net/jdk/pull/5110/files - new: https://git.openjdk.java.net/jdk/pull/5110/files/50f50d50..0a24d520 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5110=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5110=00-01 Stats: 43 lines in 2 files changed: 4 ins; 31 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5110/head:pull/5110 PR: https://git.openjdk.java.net/jdk/pull/5110
RFR: 8270344: Session resumption errors
Corner case where a session resumption can fail if the TLS server changes supported protocol versions in relation to a cached SSLSession. This is primarily an issue where the legacy TLS version is used in place of the newer "supported_versions" TLS extension. - Commit messages: - 8270344: Session resumption errors Changes: https://git.openjdk.java.net/jdk/pull/5110/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5110=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270344 Stats: 192 lines in 2 files changed: 192 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5110/head:pull/5110 PR: https://git.openjdk.java.net/jdk/pull/5110
[jdk17] Integrated: 8269034: AccessControlException for SunPKCS11 daemon threads
On Tue, 22 Jun 2021 13:26:41 GMT, Sean Coffey wrote: > Sufficient permissions missing if this code was ever to run with > SecurityManager. > > Cleanest approach appears to be use of InnocuousThread to create the > cleaner/poller threads. > Test case coverage extended to cover the SecurityManager scenario. > > Reviewer request: @valeriepeng This pull request has now been integrated. Changeset: 0d745ae8 Author:Sean Coffey URL: https://git.openjdk.java.net/jdk17/commit/0d745ae8fde5cab290dc8c695d2906f9a98c491c Stats: 95 lines in 5 files changed: 53 ins; 17 del; 25 mod 8269034: AccessControlException for SunPKCS11 daemon threads Reviewed-by: valeriep - PR: https://git.openjdk.java.net/jdk17/pull/117
Re: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon threads [v3]
> Sufficient permissions missing if this code was ever to run with > SecurityManager. > > Cleanest approach appears to be use of InnocuousThread to create the > cleaner/poller threads. > Test case coverage extended to cover the SecurityManager scenario. > > Reviewer request: @valeriepeng Sean Coffey 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: - Edits from review - Merge remote-tracking branch 'origin/master' into pkcs11-perms - Move TokenPoller to Runnable - 8269034: AccessControlException for SunPKCS11 daemon threads - Changes: - all: https://git.openjdk.java.net/jdk17/pull/117/files - new: https://git.openjdk.java.net/jdk17/pull/117/files/03af6494..e961ff09 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17=117=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk17=117=01-02 Stats: 3102 lines in 121 files changed: 2073 ins; 670 del; 359 mod Patch: https://git.openjdk.java.net/jdk17/pull/117.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/117/head:pull/117 PR: https://git.openjdk.java.net/jdk17/pull/117
Re: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon threads [v2]
> Sufficient permissions missing if this code was ever to run with > SecurityManager. > > Cleanest approach appears to be use of InnocuousThread to create the > cleaner/poller threads. > Test case coverage extended to cover the SecurityManager scenario. > > Reviewer request: @valeriepeng Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Move TokenPoller to Runnable - Changes: - all: https://git.openjdk.java.net/jdk17/pull/117/files - new: https://git.openjdk.java.net/jdk17/pull/117/files/2a168946..03af6494 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17=117=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17=117=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/117.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/117/head:pull/117 PR: https://git.openjdk.java.net/jdk17/pull/117
[jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon threads
Sufficient permissions missing if this code was ever to run with SecurityManager. Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads. Test case coverage extended to cover the SecurityManager scenario. Reviewer request: @valeriepeng - Commit messages: - 8269034: AccessControlException for SunPKCS11 daemon threads Changes: https://git.openjdk.java.net/jdk17/pull/117/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=117=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269034 Stats: 112 lines in 5 files changed: 73 ins; 17 del; 22 mod Patch: https://git.openjdk.java.net/jdk17/pull/117.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/117/head:pull/117 PR: https://git.openjdk.java.net/jdk17/pull/117
Re: RFR: 8269034: AccessControlException for SunPKCS11 daemon threads
On Tue, 22 Jun 2021 12:01:07 GMT, Sean Coffey wrote: > Sufficient permissions missing if this code was ever to run with > SecurityManager. > > Cleanest approach appears to be use of InnocuousThread to create the > cleaner/poller threads. > Test case coverage extended to cover the SecurityManager scenario. > > Reviewer request: @valeriepeng Please ignore - I'm going to open a PR against jdk17 for this - PR: https://git.openjdk.java.net/jdk/pull/4555
Withdrawn: 8269034: AccessControlException for SunPKCS11 daemon threads
On Tue, 22 Jun 2021 12:01:07 GMT, Sean Coffey wrote: > Sufficient permissions missing if this code was ever to run with > SecurityManager. > > Cleanest approach appears to be use of InnocuousThread to create the > cleaner/poller threads. > Test case coverage extended to cover the SecurityManager scenario. > > Reviewer request: @valeriepeng This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/4555
RFR: 8269034: AccessControlException for SunPKCS11 daemon threads
Sufficient permissions missing if this code was ever to run with SecurityManager. Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads. Test case coverage extended to cover the SecurityManager scenario. Reviewer request: @valeriepeng - Commit messages: - 8269034: AccessControlException for SunPKCS11 daemon threads Changes: https://git.openjdk.java.net/jdk/pull/4555/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4555=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269034 Stats: 112 lines in 5 files changed: 73 ins; 17 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/4555.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4555/head:pull/4555 PR: https://git.openjdk.java.net/jdk/pull/4555
Re: RFR: 8255148: Confusing log output: SSLSocket duplex close failed
On Fri, 4 Jun 2021 14:08:58 GMT, Sean Mullan wrote:
>> Hi,
>>
>> Please review my fix for JDK-8255148 which clarifies when an exception
>> contains debug information only.
>>
>> Regards,
>> Evan
>
> src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 590:
>
>> 588: // ignore the exception
>> 589: if (SSLLogger.isOn && SSLLogger.isOn("ssl")) {
>> 590: SSLLogger.warning("SSLSocket duplex close failed. Debug
>> info only. Exception details:", ioe);
>
> If this is a debug message, shouldn't we just use `SSLLogger.fine()` instead
> of `SSLLogger.warning()`, with the same message "SSLSocket duplex close
> failed"? @coffeys what do you think?
@seanjmullan - It's the exception stacktrace printed after the message that's
causing issue for some. Some are reading it as a JDK functionality issue (when
it's not)
I've no strong preference whether this should be printed at warning() or fine()
level. That granularity is largely broken since JDK 11 - people need to use
-Djavax.net.debug=all to get any reasonable amount of data. It would be good to
see https://bugs.openjdk.java.net/browse/JDK-8044609 worked on.
I think the patch looks ok as ie. Evan has fixed up some issues with the test -
we should expect a new version shortly.
-
PR: https://git.openjdk.java.net/jdk/pull/4354
Integrated: 8268167: MultipleLogins.java failure on macosx-aarch64
On Thu, 3 Jun 2021 11:10:10 GMT, Sean Coffey wrote: > MultipleLogins.java should skip test where NSS support is not present This pull request has now been integrated. Changeset: eb385c0d Author: Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/eb385c0de2026d6b184ce0c98ff421a4da95e1b1 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8268167: MultipleLogins.java failure on macosx-aarch64 Reviewed-by: weijun - PR: https://git.openjdk.java.net/jdk/pull/4333
RFR: 8268167: MultipleLogins.java failure on macosx-aarch64
MultipleLogins.java should skip test where NSS support is not present - Commit messages: - 8268167: MultipleLogins.java failure on macosx-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/4333/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4333=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268167 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4333.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4333/head:pull/4333 PR: https://git.openjdk.java.net/jdk/pull/4333
Integrated: 8240256: Better resource cleaning for SunPKCS11 Provider
On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey wrote: > Added capability to allow the PKCS11 Token to be destroyed once a session is > logged out from. New configuration properties via pkcs11 config file. Cleaned > up the native resource poller also. > > New unit test case to test behaviour. Some PKCS11 tests refactored to allow > pkcs11 provider to be configured (and tested) with a config file of choice. > > Reviewer request @valeriepeng This pull request has now been integrated. Changeset: bdeaeb47 Author:Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/bdeaeb47d0155b9f233274cff90334e8dd761aae Stats: 573 lines in 11 files changed: 467 ins; 68 del; 38 mod 8240256: Better resource cleaning for SunPKCS11 Provider Reviewed-by: valeriep - PR: https://git.openjdk.java.net/jdk/pull/3544
Re: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider [v3]
> Added capability to allow the PKCS11 Token to be destroyed once a session is > logged out from. New configuration properties via pkcs11 config file. Cleaned > up the native resource poller also. > > New unit test case to test behaviour. Some PKCS11 tests refactored to allow > pkcs11 provider to be configured (and tested) with a config file of choice. > > Reviewer request @valeriepeng Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - whitespace - Further 8240256 test clean up - Merge branch 'master' into JDK-8240256-pkcs11 - Initial corrections from RFR - 8240256: Better resource cleaning for SunPKCS11 Provider - Changes: https://git.openjdk.java.net/jdk/pull/3544/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3544=02 Stats: 574 lines in 11 files changed: 467 ins; 68 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/3544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3544/head:pull/3544 PR: https://git.openjdk.java.net/jdk/pull/3544
Re: RFR: 8267683: rfc7301Grease8F value not displayed correctly in SSLParameters javadoc
On Tue, 25 May 2021 18:03:51 GMT, Bradford Wetmore wrote: > Simple typo fix. Somehow the trailing "u" got omitted, so the code won't > parse when fed into the compiler. > > Resulting javadoc output now compiles. Looks good! - Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4193
Re: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider
On Wed, 21 Apr 2021 01:26:18 GMT, Valerie Peng wrote: >> Added capability to allow the PKCS11 Token to be destroyed once a session is >> logged out from. New configuration properties via pkcs11 config file. >> Cleaned up the native resource poller also. >> >> New unit test case to test behaviour. Some PKCS11 tests refactored to allow >> pkcs11 provider to be configured (and tested) with a config file of choice. >> >> Reviewer request @valeriepeng > > I will take a look. Thanks! Thanks for the review @valeriepeng Apologies for delay, had to finish up other tasks -- I've made all suggested edits that you made for src/ code and pushed those changes to my branch. For the testing, then I recall the PKCS11Test framework not being able to return multiple PKCS11 Providers to me for testing (an array of providers) -- I thought editing the framework for such a use case would be useful but perhaps I'm better off just writing a customized test. I'm going to take a stab at that and will re-submit a test edit. Apologies for including the Login.java/ Login.sh edits - they were old left over edits from testing efforts before moving on to develop the new MultipleLogins.java test. - PR: https://git.openjdk.java.net/jdk/pull/3544
Re: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider [v2]
> Added capability to allow the PKCS11 Token to be destroyed once a session is > logged out from. New configuration properties via pkcs11 config file. Cleaned > up the native resource poller also. > > New unit test case to test behaviour. Some PKCS11 tests refactored to allow > pkcs11 provider to be configured (and tested) with a config file of choice. > > Reviewer request @valeriepeng Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Initial corrections from RFR - Changes: - all: https://git.openjdk.java.net/jdk/pull/3544/files - new: https://git.openjdk.java.net/jdk/pull/3544/files/dd185388..f053bc39 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3544=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3544=00-01 Stats: 94 lines in 8 files changed: 22 ins; 38 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/3544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3544/head:pull/3544 PR: https://git.openjdk.java.net/jdk/pull/3544
Integrated: 8236671: NullPointerException in JKS keystore
On Tue, 20 Apr 2021 11:54:39 GMT, Sean Coffey wrote: > Trivial enough change. Improved the exception thrown from JceKeyStore also. This pull request has now been integrated. Changeset: 276a1bf7 Author: Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/276a1bf7675e32784870f5559f6d3ac8bea07b6e Stats: 17 lines in 3 files changed: 14 ins; 0 del; 3 mod 8236671: NullPointerException in JKS keystore Reviewed-by: hchao, xuelei - PR: https://git.openjdk.java.net/jdk/pull/3588
Re: RFR: 8236671: NullPointerException in JKS keystore [v2]
On Wed, 28 Apr 2021 12:39:42 GMT, Sean Coffey wrote: >> Trivial enough change. Improved the exception thrown from JceKeyStore also. > > Sean Coffey 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: > > - Check for null before try block > - Merge branch 'master' of https://github.com/openjdk/jdk into > JDK-8236671-NPE > - Fix white space > - 8236671: NullPointerException in JKS keystore KeyStore specification will be tightened up via another bug record: https://bugs.openjdk.java.net/browse/JDK-8266351 - PR: https://git.openjdk.java.net/jdk/pull/3588
Re: RFR: 8266220: keytool still prompt for store password on a password-less pkcs12 file if -storetype pkcs12 is specified [v2]
On Thu, 29 Apr 2021 17:51:17 GMT, Weijun Wang wrote: >> It's awkward that for a password-less pkcs12 keystore, `keytool -list` does >> not prompt for a password but `keytool -list -storetype pkcs12` does. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > close stream carefully Marked as reviewed by coffeys (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3764
Re: RFR: 8236671: NullPointerException in JKS keystore [v2]
> Trivial enough change. Improved the exception thrown from JceKeyStore also. Sean Coffey 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: - Check for null before try block - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8236671-NPE - Fix white space - 8236671: NullPointerException in JKS keystore - Changes: - all: https://git.openjdk.java.net/jdk/pull/3588/files - new: https://git.openjdk.java.net/jdk/pull/3588/files/836ea7e7..54baaad7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3588=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3588=00-01 Stats: 42439 lines in 1504 files changed: 9588 ins; 28041 del; 4810 mod Patch: https://git.openjdk.java.net/jdk/pull/3588.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3588/head:pull/3588 PR: https://git.openjdk.java.net/jdk/pull/3588
Re: RFR: 8196415: Disable SHA-1 Signed JARs
On Mon, 26 Apr 2021 17:29:26 GMT, Sean Mullan wrote: > This change will restrict JARs signed with SHA-1 algorithms and treat them as > if they were unsigned. This applies to the algorithms used to digest, sign, > and optionally timestamp the JAR. It also applies to the signature and digest > algorithms of the certificates in the certificate chain of the code signer > and the Timestamp Authority, and any CRLs or OCSP responses that are used to > verify if those certificates have been revoked. > > In order to reduce the compatibility risk for applications that have been > previously timestamped or use private CAs, there are two exceptions to this > policy: > > - Any JAR signed with SHA-1 algorithms and timestamped prior to January 01, > 2019 will not be restricted. > - Any JAR signed with a SHA-1 certificate that does not chain back to a Root > CA included by default in the JDK `cacerts` keystore will not be restricted. > > These exceptions may be removed in a future JDK release. > > All tests are in the closed repo for now. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8264362 Marked as reviewed by coffeys (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3700
Re: RFR: 8236671: NullPointerException in JKS keystore
On Tue, 20 Apr 2021 17:00:40 GMT, Xue-Lei Andrew Fan wrote: > It looks like a public behavior change to me. Did you want to file a CSR and > update the specification (KeyStore) as well? I think it would be nice if we > could keep use the old exception, IllegalArgumentException, as described in > the bug. @XueleiFan - The spec in question has been broken for almost 3 years with the throwing of NPE. One issue here is that Sun provider with JKS keystore will throw IllegalArgumentException in older JDK versions but the SunJCE provider and JCEKS keystore throws KeyStoreException when null password is encountered . There's a mismatch. To me, it looks like KeyStoreException is the correct exception in such scenarios (and according to API spec) I can file a CSR to have the implementation adhere to spec if that's desired. - PR: https://git.openjdk.java.net/jdk/pull/3588
RFR: 8236671: NullPointerException in JKS keystore
Trivial enough change. Improved the exception thrown from JceKeyStore also. - Commit messages: - Fix white space - 8236671: NullPointerException in JKS keystore Changes: https://git.openjdk.java.net/jdk/pull/3588/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3588=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236671 Stats: 17 lines in 3 files changed: 14 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3588.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3588/head:pull/3588 PR: https://git.openjdk.java.net/jdk/pull/3588
RFR: 8240256: Better resource cleaning for SunPKCS11 Provider
Added capability to allow the PKCS11 Token to be destroyed once a session is logged out from. New configuration properties via pkcs11 config file. Cleaned up the native resource poller also. New unit test case to test behaviour. Some PKCS11 tests refactored to allow pkcs11 provider to be configured (and tested) with a config file of choice. Reviewer request @valeriepeng - Commit messages: - 8240256: Better resource cleaning for SunPKCS11 Provider Changes: https://git.openjdk.java.net/jdk/pull/3544/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3544=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240256 Stats: 604 lines in 13 files changed: 493 ins; 63 del; 48 mod Patch: https://git.openjdk.java.net/jdk/pull/3544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3544/head:pull/3544 PR: https://git.openjdk.java.net/jdk/pull/3544
Re: RFR: 8260923: Add more tests for SSLSocket input/output shutdown
On Tue, 2 Mar 2021 10:31:03 GMT, Abdul Kolarkunnu wrote: >> There is a lack of tests in the area of java.net.Socket.shutdownInput() and >> java.net.Socket.shutdownOutput() , so added more tests in this area of with >> different TLS versions. Please review. > > @coffeys Thanks for increasing code coverage here. Looks fine to me. - PR: https://git.openjdk.java.net/jdk/pull/2745
Re: RFR: 8260923: Add more tests for SSLSocket input/output shutdown [v2]
On Fri, 9 Apr 2021 11:15:40 GMT, Abdul Kolarkunnu wrote: >> There is a lack of tests in the area of java.net.Socket.shutdownInput() and >> java.net.Socket.shutdownOutput() , so added more tests in this area of with >> different TLS versions. Please review. > > Abdul Kolarkunnu has updated the pull request incrementally with one > additional commit since the last revision: > > 8260923: Add more tests for SSLSocket input/output shutdown Marked as reviewed by coffeys (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2745
Re: RFR: 8261160: Add a deserialization JFR event [v5]
On Fri, 12 Feb 2021 16:26:09 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java >> deserialization. The event captures the details of deserialization activity >> from ObjectInputStream. The event details are similar to that of the serial >> filter, but is agnostic of whether a filter is installed or not. The event >> also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional > commit since the last revision: > > Split exception into type and message Marked as reviewed by coffeys (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2479
Re: RFR: 8261160: Add a deserialization JFR event [v3]
On Thu, 11 Feb 2021 15:28:07 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java >> deserialization. The event captures the details of deserialization activity >> from ObjectInputStream. The event details are similar to that of the serial >> filter, but is agnostic of whether a filter is installed or not. The event >> also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional > commit since the last revision: > > Fix failing test Marked as reviewed by coffeys (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2479
Re: RFR: 8261160: Add a deserialization JFR event
On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java > deserialization. The event captures the details of deserialization activity > from ObjectInputStream. The event details are similar to that of the serial > filter, but is agnostic of whether a filter is installed or not. The event > also captures the filter status, if there is one. Marked as reviewed by coffeys (Reviewer). test/jdk/java/io/Serializable/serialFilter/GlobalFilterTest.java line 50: > 48: * -Dexpected-jdk.serialFilter=java.** GlobalFilterTest > 49: * @run testng/othervm/policy=security.policy GlobalFilterTest > 50: * @run testng/othervm/policy=security.policy You may want to add a "@requires vm.hasJFR" condition to this test - PR: https://git.openjdk.java.net/jdk/pull/2479
Re: RFR: 8257497: Key identifier compliance issue
On Mon, 1 Feb 2021 23:06:30 GMT, Hai-May Chao wrote: > This change is made for compliance with RFC 5280 section 4.2.1.1 for > Authority Key Identifier extension. Marked as reviewed by coffeys (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2343
Integrated: 8255348: NPE in PKIXCertPathValidator event logging code
On Tue, 19 Jan 2021 17:54:33 GMT, Sean Coffey wrote: > Correction of NPE and updating of test cases. Minor refactoring of test > library also. This pull request has now been integrated. Changeset: 18eb6d9e Author: Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/18eb6d9e Stats: 77 lines in 6 files changed: 53 ins; 2 del; 22 mod 8255348: NPE in PKIXCertPathValidator event logging code Reviewed-by: mullan - PR: https://git.openjdk.java.net/jdk/pull/2150
Re: RFR: 8255348: NPE in PKIXCertPathValidator event logging code [v2]
> Correction of NPE and updating of test cases. Minor refactoring of test > library also. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Sean Mullan review update - Changes: - all: https://git.openjdk.java.net/jdk/pull/2150/files - new: https://git.openjdk.java.net/jdk/pull/2150/files/a59dd592..8a344a85 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2150=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2150=00-01 Stats: 10 lines in 1 file changed: 0 ins; 7 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2150/head:pull/2150 PR: https://git.openjdk.java.net/jdk/pull/2150
RFR: 8255348: NPE in PKIXCertPathValidator event logging code
Correction of NPE and updating of test cases. Minor refactoring of test library also. - Commit messages: - 8255348: NPE in PKIXCertPathValidator event logging code Changes: https://git.openjdk.java.net/jdk/pull/2150/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2150=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255348 Stats: 83 lines in 6 files changed: 60 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/2150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2150/head:pull/2150 PR: https://git.openjdk.java.net/jdk/pull/2150
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
Integrated: 8253368: TLS connection always receives close_notify exception
On Fri, 13 Nov 2020 14:16:35 GMT, Sean Coffey wrote: > removing the "closing inbound before receiving peer's close_notify" exception > that can be seen with TLS stack if calling close on inbound. After reading > the relevant parts of the TLS v1.2/v1.3 RFCs, I believe the local end point > doesn't have to wait for close_notify alert from remote end. This pull request has now been integrated. Changeset: a4e082e9 Author:Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/a4e082e9 Stats: 37 lines in 2 files changed: 25 ins; 0 del; 12 mod 8253368: TLS connection always receives close_notify exception Reviewed-by: xuelei - PR: https://git.openjdk.java.net/jdk/pull/1205
Re: RFR: 8253368: TLS connection always receives close_notify exception [v2]
> removing the "closing inbound before receiving peer's close_notify" exception > that can be seen with TLS stack if calling close on inbound. After reading > the relevant parts of the TLS v1.2/v1.3 RFCs, I believe the local end point > doesn't have to wait for close_notify alert from remote end. Sean Coffey 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: - version 2 redesign - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8253368 - 8253368: TLS connection always receives close_notify exception - Changes: - all: https://git.openjdk.java.net/jdk/pull/1205/files - new: https://git.openjdk.java.net/jdk/pull/1205/files/85d41030..86d9dac5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1205=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1205=00-01 Stats: 284235 lines in 2912 files changed: 188350 ins; 66757 del; 29128 mod Patch: https://git.openjdk.java.net/jdk/pull/1205.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1205/head:pull/1205 PR: https://git.openjdk.java.net/jdk/pull/1205
Re: RFR: 8253368: TLS connection always receives close_notify exception
On Fri, 13 Nov 2020 14:16:35 GMT, Sean Coffey wrote: > removing the "closing inbound before receiving peer's close_notify" exception > that can be seen with TLS stack if calling close on inbound. After reading > the relevant parts of the TLS v1.2/v1.3 RFCs, I believe the local end point > doesn't have to wait for close_notify alert from remote end. @XueleiFan I went ahead with your advice and chose to keep the check in the code. Since JDK 11, this code path would have thrown an SSLException. I've chosen to keep that instead of introduce another Exception(UnsupportedOperationException) -- which would be new for some application stacks. I've looked at the apache core-http stack and know that it catches and ignores SSLException in these cases. The important change here is that the exception is not fatal and the session remains valid. Socket is closed out in a finally block. test case updated also. - PR: https://git.openjdk.java.net/jdk/pull/1205
Re: RFR: 8202343: Disable TLS 1.0 and 1.1 [v2]
On Tue, 17 Nov 2020 17:55:19 GMT, Sean Mullan wrote:
>> This change disables the TLSv1 and TLSv1.1 protocols by adding them to the
>> jdk.tls.disabledAlgorithms security property in the java.security file.
>> These protocols use weak algorithms and are being deprecated by the IETF.
>> They should be disabled by default to improve the default security
>> configuration of the JDK. See the CSR for more rationale:
>> https://bugs.openjdk.java.net/browse/JDK-8254713
>>
>> The fix mostly involves changes to existing tests that for one reason or
>> another depend on the TLSv1 and TLSv1.1 protocols being enabled. There is a
>> new test specifically for this issue:
>> test/jdk/sun/security/ssl/SSLContextImpl/SSLContextDefault.java
>
> Sean Mullan has updated the pull request incrementally with one additional
> commit since the last revision:
>
> More test changes.
Marked as reviewed by coffeys (Reviewer).
test/lib/jdk/test/lib/security/SecurityUtils.java line 64:
> 62: }
> 63:
> 64: private static void removeFromDisabledAlgs(String prop, List
> algs) {
Useful utility method. Maybe it can be made public/ opened up and renamed to
something like "removeFromSecurityProperty" perhaps ? could be done at a later
time perhaps.
-
PR: https://git.openjdk.java.net/jdk/pull/1235
Re: RFR: 8256363: Define toString() for MGF1ParameterSpec [v2]
On Mon, 16 Nov 2020 14:25:20 GMT, Weijun Wang wrote:
>> Without this method, `PSSParameterSpec::toString` shows something like:
>> MD: SHA-256
>> MGF: java.security.spec.MGF1ParameterSpec@77b52d12
>> SaltLength: 32
>> TrailerField: 1
>> This is ugly.
>>
>> Noreg-trivial.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> make PSSParameterSpec one line
>
> only in patch2:
> unchanged:
minor comment on spacing for MGF1 toString()
src/java.base/share/classes/java/security/spec/MGF1ParameterSpec.java line 168:
> 166: @Override
> 167: public String toString() {
> 168: return "MGF1:" + mdName;
do you want to insert a space after ':' ?
-
PR: https://git.openjdk.java.net/jdk/pull/1208
Re: RFR: 8256363: Define toString() for MGF1ParameterSpec
On Fri, 13 Nov 2020 21:18:30 GMT, Weijun Wang wrote: >> Without this method, `PSSParameterSpec::toString` shows something like: >> MD: SHA-256 >> MGF: java.security.spec.MGF1ParameterSpec@77b52d12 >> SaltLength: 32 >> TrailerField: 1 >> This is ugly. >> >> Noreg-trivial. > > Do you want me to consolidate `PSSParameterSpec::toString` into one line? > Multi-line toString is usually not very friendly to debug output (esp for > grep). tidying PSSParameterSpec::toString into 1 line would be useful. thanks! - PR: https://git.openjdk.java.net/jdk/pull/1208
Re: RFR: 8256202: Some tweaks for jarsigner tests PosixPermissionsTest and SymLinkTest
On Thu, 12 Nov 2020 06:44:27 GMT, Matthias Baesken wrote: >> Marked as reviewed by mbaesken (Reviewer). > > Looks good to me ! Meant to comment earlier. Thanks for cleaning this one up! - PR: https://git.openjdk.java.net/jdk/pull/1166
RFR: 8253368: TLS connection always receives close_notify exception
removing the "closing inbound before receiving peer's close_notify" exception that can be seen with TLS stack if calling close on inbound. After reading the relevant parts of the TLS v1.2/v1.3 RFCs, I believe the local end point doesn't have to wait for close_notify alert from remote end. - Commit messages: - 8253368: TLS connection always receives close_notify exception Changes: https://git.openjdk.java.net/jdk/pull/1205/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1205=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253368 Stats: 25 lines in 2 files changed: 12 ins; 10 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1205.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1205/head:pull/1205 PR: https://git.openjdk.java.net/jdk/pull/1205
Integrated: 8250968: Symlinks attributes not preserved when using jarsigner on zip files
On Mon, 7 Sep 2020 13:48:57 GMT, Sean Coffey wrote: > Continuation of RFR thread from > http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html > > CSR has been approved. This pull request has now been integrated. Changeset: 7686e871 Author: Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/7686e871 Stats: 200 lines in 10 files changed: 1 ins; 162 del; 37 mod 8250968: Symlinks attributes not preserved when using jarsigner on zip files Reviewed-by: lancea, weijun, hchao - PR: https://git.openjdk.java.net/jdk/pull/56
Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files [v2]
> Continuation of RFR thread from > http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html > > CSR has been approved. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Copyright and test clean up - Changes: - all: https://git.openjdk.java.net/jdk/pull/56/files - new: https://git.openjdk.java.net/jdk/pull/56/files/2f656ce0..27cb91f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=56=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=56=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/56.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/56/head:pull/56 PR: https://git.openjdk.java.net/jdk/pull/56
RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files
Continuation of RFR thread from http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html CSR has been approved. - Commit messages: - JDK-8250968 Changes: https://git.openjdk.java.net/jdk/pull/56/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=56=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250968 Stats: 198 lines in 10 files changed: 162 ins; 1 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/56.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/56/head:pull/56 PR: https://git.openjdk.java.net/jdk/pull/56
Re: RFR: 8061842: Package jurisdiction policy files as something other than JAR
Looks good Brad. One comment :
You might hit an NPE here but I guess the Exception handling in the
parent call would handle it :
JceSecurity.java :
254 if (Paths.get(cryptoPolicyProperty).getNameCount() != 1) {
Maybe add a null check to be cleaner ?
I missed the "crypto.policy=crypto.policydir-tbd" approach in 1st
revision. Isn't it going to confuse people studying the code ? This
value gets replaced at build time - right ? What about changing it to
something like :
"crypto.policy=$crypto.policydir-tbd //replaced at build time"
and having the make files search for that string instead ? I think it
makes the intent more obvious.
Regards,
Sean.
On 25/08/2016 01:21, Bradford Wetmore wrote:
Max/SeanC/SeanM,
The latest update:
http://cr.openjdk.java.net/~wetmore/8061842/webrev.02/
On 8/17/2016 9:26 PM, Wang Weijun wrote:
Before this change, you require default policy in neither export nor
import to be empty but do not care about the getMinimum() result. In
this change, you make sure the final result is not empty. I assume
this is a fix?
I made the change to allow for our traditional (default) export/import
mechanism, but other additional styles could be added/used. Since we
no longer sign, distros are free to edit, add and/or remove files.
But before doing any JCE operation, the environment needs to grant
something, otherwise there are no perms and no JCE available.
283 // Did we find a default perms?
What does this line mean?
I've moved to the right position in the file. I meant did we find a
default perms file, vs an exempt.
296 // This should never happen
But you can still print out the file name.
I'm concerned that the exception might print out the entire path
instead of just the filename, which would include java.home and
probably should not be made available.
Can you rename policydir-tbd to something else? I am afraid it will
be confused with policy.url.1 etc.
Changed to: crypto.policydir-tbd?
The original README.TXT in unlimited says "are exportable from the
United States." and you have "is exportable." now. Is this intended?
(IANAL)
Changed.
TestUnlimited.java:
45 "// Use the AES are the test Cipher", you mean "Use AES as the
test Cipher"?
51 "throw new Exception ("Unlimited policy is NOT active");". No
space before "(".
Fixed.
Sean Mullan wrote:
> What about setting the default value to "limited"? And then this
> would only be changed to "unlimited" if the build --enable-unlimited-
> crypto option is specified?
I could, but I'm concerned that a build with
--enabled-unlimited-crypto would expect that the compiled-in version
default would also be unlimited and would be surprised with limited.
Upon Max's suggestion above, I've changed the name of the marker to
"crypto.policy=crypto.policydir-tbd." Does that work for you?
> Instead of throwing an exception here, I wonder if it would make more
> sense to assume a default value of "limited" if the property is not
> set or is empty.
We could, but see above.
Sean Coffey wrote:
> Please include the exception 'e' in your last exception here.
Again, I'm concerned about outputting java.home, so I'm just going to
output the final directory name.
> 3. Test case.
>
> The TestUnlimited.java testcase seems to be lacking. Do you want to
> test other values for crypto.policy ? 'limited' would be one.
> Throwing in some dummy value would also be good so that the exception
> handling code gets exercised.
Done.
* @run main/othervm TestUnlimited limited fail
* @run main/othervm TestUnlimited unlimited pass
* @run main/othervm TestUnlimited NosuchDir exception
* @run main/othervm TestUnlimited . exception
* @run main/othervm TestUnlimited /tmp/unlimited exception
* @run main/othervm TestUnlimited ../policy/unlimited exception
* @run main/othervm TestUnlimited ./unlimited exception
> It needs to be run in ovm mode since you're setting a Security
> property.
Yes, good catch.
Brad
Re: [8u-dev] Request for Review and Approval to backport: 8160518: Semicolon is not recognized as comment starting character (Kerberos)
Looks fine. Approved for jdk8u-dev. regards, Sean. On 08/07/2016 18:04, Ivan Gerasimov wrote: Hello! I'd like to backport this fix into jdk8u-dev. The fix is essentially the same as in jdk9, but could not be used verbatim because of the code derivation. Bug: https://bugs.openjdk.java.net/browse/JDK-8160518 Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4d5c6e8bad2d Jdk9 review: http://mail.openjdk.java.net/pipermail/security-dev/2016-July/014377.html Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8160518/01/webrev/ Would you please help review it and approve the backport? With kind regards, Ivan
hg: jdk8/tl/corba: 8035618: Four api/org_omg/CORBA TCK tests fail under plugin only
Changeset: 0683ee308085 Author:coffeys Date: 2014-02-26 23:04 + URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0683ee308085 8035618: Four api/org_omg/CORBA TCK tests fail under plugin only Reviewed-by: mchung, chegar ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 46c727d6ecc2 Author:aefimov Date: 2013-12-30 16:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46c727d6ecc2 8025051: Update resource files for TimeZone display names Reviewed-by: okutsu, mfang ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/java/util/Calendar/GenericTimeZoneNamesTest.sh ! test/sun/util/resources/TimeZone/Bug6317929.java + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_de.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_de_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_es.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_es_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_fr.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_fr_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_it.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_it_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ja.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ja_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ko.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ko_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_pt_BR.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_pt_BR_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_sv.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_sv_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_CN.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_CN_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_TW.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_TW_short.properties Changeset: c0970860803e Author:coffeys Date: 2014-01-03 16:45 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0970860803e Merge
hg: jdk8/tl/corba: 8029231: Update copyright years for files in corba repository for 2013
Changeset: 5ca1b4c282b8 Author:ssides Date: 2013-12-23 18:42 + URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5ca1b4c282b8 8029231: Update copyright years for files in corba repository for 2013 Reviewed-by: mchung, coffeys ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/io/OutputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java ! src/share/classes/com/sun/corba/se/impl/ior/ObjectKeyImpl.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/StubDelegateImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator.java ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/InvocationHandlerFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/DefaultSocketFactoryImpl.java ! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp ! src/share/classes/javax/rmi/CORBA/Stub.java ! src/share/classes/javax/rmi/CORBA/Util.java ! src/share/classes/javax/rmi/PortableRemoteObject.java ! src/share/classes/sun/rmi/rmic/iiop/CompoundType.java
hg: jdk8/tl/jdk: 8029347: sun/rmi/runtime/Log/checkLogging/CheckLogging.java fails in nightly intermittently
Changeset: 0f1332dd805c Author:coffeys Date: 2013-12-04 17:03 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f1332dd805c 8029347: sun/rmi/runtime/Log/checkLogging/CheckLogging.java fails in nightly intermittently Reviewed-by: alanb ! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java
hg: jdk8/tl/jdk: 8028583: Add helper methods to test libraries
Changeset: d1bb85f0a45a Author:coffeys Date: 2013-11-19 14:47 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1bb85f0a45a 8028583: Add helper methods to test libraries Reviewed-by: chegar ! test/java/rmi/testlibrary/TestLibrary.java ! test/lib/testlibrary/jdk/testlibrary/FileUtils.java
hg: jdk8/tl/jdk: 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing
Changeset: d34c5e860d5f Author:aefimov Date: 2013-10-24 17:23 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d34c5e860d5f 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing Reviewed-by: okutsu, mfang, alanb ! test/ProblemList.txt ! test/sun/util/resources/TimeZone/Bug6317929.java
hg: jdk8/tl/jdk: 5036554: unmarshal error on CORBA alias type in CORBA any
Changeset: 2af3f5a61322 Author:coffeys Date: 2013-10-23 16:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2af3f5a61322 5036554: unmarshal error on CORBA alias type in CORBA any Reviewed-by: chegar, smarks + test/com/sun/corba/5036554/JavaBug.java + test/com/sun/corba/5036554/README + test/com/sun/corba/5036554/TestCorbaBug.sh + test/com/sun/corba/5036554/bug.idl
hg: jdk8/tl/corba: 5036554: unmarshal error on CORBA alias type in CORBA any
Changeset: a90e9efa4264 Author:coffeys Date: 2013-10-23 16:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a90e9efa4264 5036554: unmarshal error on CORBA alias type in CORBA any Reviewed-by: chegar, smarks ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java
hg: jdk8/tl/jdk: 8026405: javax/xml/ws/clientjar/TestWsImport.java failing on JDK 8 nightly aurora test runs
Changeset: ee7f1c78bec7 Author:coffeys Date: 2013-10-23 20:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ee7f1c78bec7 8026405: javax/xml/ws/clientjar/TestWsImport.java failing on JDK 8 nightly aurora test runs Reviewed-by: chegar ! test/javax/xml/ws/clientjar/TestWsImport.java
hg: jdk8/tl/jdk: 8025255: (tz) Support tzdata2013g
Changeset: 60e3cdbe8cdf Author:aefimov Date: 2013-10-13 14:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60e3cdbe8cdf 8025255: (tz) Support tzdata2013g Reviewed-by: okutsu, mfang ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/backward ! test/sun/util/calendar/zi/tzdata/etcetera ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/iso3166.tab ! test/sun/util/calendar/zi/tzdata/leapseconds ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/zone.tab
hg: jdk8/tl/jdk: 8024952: ClassCastException in PlainSocketImpl.accept() when using custom socketImpl
Changeset: 368172cb6dc5 Author:coffeys Date: 2013-10-02 09:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/368172cb6dc5 8024952: ClassCastException in PlainSocketImpl.accept() when using custom socketImpl Reviewed-by: chegar ! src/windows/classes/java/net/PlainSocketImpl.java + test/java/net/PlainSocketImpl/CustomSocketImplFactory.java
hg: jdk8/tl/jdk: 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions
Changeset: 92a66af7f834 Author:igerasim Date: 2013-08-26 18:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92a66af7f834 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions Reviewed-by: alanb, chegar ! src/share/classes/java/lang/AbstractStringBuilder.java
hg: jdk8/tl/jdk: 8019979: Replace CheckPackageAccess test with better one from closed repo
Changeset: 83c2976ef8ee Author:coffeys Date: 2013-07-09 16:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/83c2976ef8ee 8019979: Replace CheckPackageAccess test with better one from closed repo Reviewed-by: mullan ! test/java/lang/SecurityManager/CheckPackageAccess.java
hg: jdk8/tl/jdk: 8000450: Restrict access to com/sun/corba/se/impl package
Changeset: c4480e0d9f53 Author:coffeys Date: 2013-06-06 14:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4480e0d9f53 8000450: Restrict access to com/sun/corba/se/impl package Reviewed-by: alanb, chegar, lancea ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 885bb24f6018 Author:coffeys Date: 2013-02-19 14:07 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/885bb24f6018 7197187: Currency.isPastCutoverDate should be made more robust Reviewed-by: alanb ! src/share/classes/java/util/Currency.java Changeset: 01b6b0dd2006 Author:coffeys Date: 2013-02-19 14:12 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b6b0dd2006 8007315: HttpURLConnection.filterHeaderField method returns null where empty string is expected Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! test/sun/net/www/protocol/http/HttpOnly.java
hg: jdk8/tl/jdk: 7196533: TimeZone.getDefault() slow due to synchronization bottleneck
Changeset: fecba6a8b78e Author:coffeys Date: 2012-10-09 12:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fecba6a8b78e 7196533: TimeZone.getDefault() slow due to synchronization bottleneck Reviewed-by: okutsu ! src/share/classes/java/util/TimeZone.java
hg: jdk8/tl/jdk: 7180362: RFE: Implement date cutover functionality for currency.properties file
Changeset: fffbb33df102 Author:coffeys Date: 2012-09-07 21:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fffbb33df102 7180362: RFE: Implement date cutover functionality for currency.properties file Reviewed-by: naoto ! src/share/classes/java/util/Currency.java ! test/java/util/Currency/PropertiesTest.java ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Currency/currency.properties
hg: jdk8/tl/jdk: 7195063: [TEST] jtreg flags com/sun/corba/cachedSocket/7056731.sh with Error failure.
Changeset: da1436b21bc2 Author:coffeys Date: 2012-08-31 12:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da1436b21bc2 7195063: [TEST] jtreg flags com/sun/corba/cachedSocket/7056731.sh with Error failure. Reviewed-by: chegar ! test/com/sun/corba/cachedSocket/7056731.sh
hg: jdk8/tl/jdk: 7056731: Race condition in CORBA code causes re-use of ABORTed connections
Changeset: 39b01268b845 Author:coffeys Date: 2012-08-16 10:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b01268b845 7056731: Race condition in CORBA code causes re-use of ABORTed connections Reviewed-by: lancea Contributed-by: d.macdon...@auckland.ac.nz ! test/Makefile + test/com/sun/corba/cachedSocket/7056731.sh + test/com/sun/corba/cachedSocket/Hello.idl + test/com/sun/corba/cachedSocket/HelloClient.java + test/com/sun/corba/cachedSocket/HelloServer.java
hg: jdk8/tl/corba: 7056731: Race condition in CORBA code causes re-use of ABORTed connections
Changeset: 18a02ad8dc73 Author:coffeys Date: 2012-08-16 10:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/18a02ad8dc73 7056731: Race condition in CORBA code causes re-use of ABORTed connections Reviewed-by: lancea Contributed-by: d.macdon...@auckland.ac.nz ! src/share/classes/com/sun/corba/se/impl/transport/CorbaResponseWaitingRoomImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java
hg: jdk8/tl/jdk: 7185965: Build error in javadoc make stage for bundles not containing crypto package
Changeset: 56d8756749bd Author:coffeys Date: 2012-08-16 10:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56d8756749bd 7185965: Build error in javadoc make stage for bundles not containing crypto package Reviewed-by: chegar ! make/common/shared/Defs-java.gmk
hg: jdk8/tl/jdk: 7179879: SSLSocket connect times out instead of throwing socket closed exception
Changeset: 35fec642fd32 Author:coffeys Date: 2012-07-26 22:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35fec642fd32 7179879: SSLSocket connect times out instead of throwing socket closed exception Reviewed-by: xuelei, chegar ! src/share/classes/sun/security/ssl/SSLSocketImpl.java
hg: jdk8/tl/jdk: 6893617: JDK 6 CNCtx always uses the default ORB
Changeset: 612e56cf284c Author:coffeys Date: 2012-06-27 21:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/612e56cf284c 6893617: JDK 6 CNCtx always uses the default ORB Reviewed-by: lancea ! src/share/classes/com/sun/jndi/cosnaming/CNCtx.java
