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 Marked as reviewed by ascarpino (Reviewer). please make sure all jdk_security tests and tier1 tests pass before integrating - 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 [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 The bug and the PR could have used a lot more description that the issue here is that 1.2 and 1.3 are enabled at the same time. such as via `setEnabledProtocols()`. At first I thought this bug was incorrect because 1.3 does not display a session_ticket extension as it is only supported in the code by 1.0-1.2. But with both enabled, it causes all the extensions to be enabled. After thinking about it, this maybe the better way to fix this as the it a heterogeneous server environment, only sending 1.3 extension from the resumed TLS protocol may cause errors when talking to 1.2 server. So both extensions need to be enabled globally, but since we are resuming 1.3 state, the same state does not to be passed in a 1.2 connection. It should do a full handshake. One could ask the reverse, if the resumption is from 1.2 should we be sending a 1.3 pre_shared_key extension.. But that can be for another bug I suppose. - PR: https://git.openjdk.java.net/jdk/pull/8922
Re: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always returns 'true' [v2]
On Tue, 7 Jun 2022 20:52:33 GMT, Hai-May Chao wrote: >> Please review a small fix in CryptoPolicyParser class that it should not >> pass “processedPermissions” parameter by value. >> Ran MACH5 tier1 and tier2 without failures. > > Hai-May Chao has updated the pull request incrementally with two additional > commits since the last revision: > > - Inconsistent entries test > - Inconsistent entries test Added a manual test for this. Fixed made to address the issue with inconsistent entries. - PR: https://git.openjdk.java.net/jdk/pull/8985
Re: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always returns 'true' [v2]
> Please review a small fix in CryptoPolicyParser class that it should not pass > “processedPermissions” parameter by value. > Ran MACH5 tier1 and tier2 without failures. Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision: - Inconsistent entries test - Inconsistent entries test - Changes: - all: https://git.openjdk.java.net/jdk/pull/8985/files - new: https://git.openjdk.java.net/jdk/pull/8985/files/a1af16e8..d8950465 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8985=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8985=00-01 Stats: 100 lines in 2 files changed: 96 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8985/head:pull/8985 PR: https://git.openjdk.java.net/jdk/pull/8985
Re: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v7]
> This is a follow up update per comments in [JDK-8287384 > PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in > open part looks good to me. Please help to run Mach5 just case the closed > test cases are impacted. Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge - Merge master - Merge - add timeout parameter - rollback is not in this branch - rollback JDK-8287384 - back to wait 1 second - Remove trailing white space - 8287596: Reorg jdk.test.lib.util.ForceGC - Changes: https://git.openjdk.java.net/jdk/pull/8979/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8979=06 Stats: 86 lines in 10 files changed: 12 ins; 29 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/8979.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8979/head:pull/8979 PR: https://git.openjdk.java.net/jdk/pull/8979
Re: RFR: JDK-8285263 Minor cleanup could be done in java.security [v5]
> https://bugs.openjdk.java.net/browse/JDK-8285263 Minor cleanup could be done > in java.security > > JDK-8273046 is the umbrella bug for this bug. The changes were too large for > a single code review, so it was decided to split into smaller chunks. This is > one such chunk: > > open/src/java.base/share/classes/java/security Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge - fourth iteration - Merge - Merge - third iteration - Merge - Merge - second iteration - Merge - Merge - ... and 1 more: https://git.openjdk.java.net/jdk/compare/4d6fb515...44140a01 - Changes: https://git.openjdk.java.net/jdk/pull/8319/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8319=04 Stats: 628 lines in 95 files changed: 25 ins; 140 del; 463 mod Patch: https://git.openjdk.java.net/jdk/pull/8319.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8319/head:pull/8319 PR: https://git.openjdk.java.net/jdk/pull/8319
Re: RFR: 8287809: Revisit implementation of memory session [v2]
> This is a cleanup of the memory session implementation. The main new concept > is that `MemorySessionImpl` is split into two parts: there is an > implementation of memory session and then there is a state abstraction > (`MemorySessionImpl.State`). This allows to share the state across multiple > session views, in a more clean way. The big consequence of this change is > that the routines on `ScopedMemoryAccess` now have to be defined in terms of > the state abstraction (but the changes are mostly mechanical). > > I have consolidated the implementation quite a bit, by removing all the > duplicated logic for issuing similar-looking exceptions. I have also > addressed an issue with `checkValidState` throwing a _new_ > `WrongThreadException` instead of using a singleton (which is what the logic > for closing down shared session requires, to avoid stack walks that are too > deep). > > `MemorySession.State::checkValidState` is now fully monomorphic; when looking > at benchmarks, this seems to be the best solution in order to make things > fast. Specializing implmentations to remove few plain checks does not buy > enough, and always has the risk of adding profile pollution. Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' into cleanup_memory_session_impl_state - Add null check on Buffer::checkState - Add docs Simplify liveness check in Buffer Drop redundant import in DirectBuffer - Simplify checkValidState - Add fastpath for implicit session state - Merge branch 'master' into cleanup_memory_session_impl_keep_list - Fix asNonCloseable to return self Improve direct buffer code with isImplicit predicate - Drop MemorySession interface type from AbstractMemorySessionImpl - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods - Simplify readOnly check - ... and 4 more: https://git.openjdk.java.net/jdk/compare/8d28734e...5b8f7246 - Changes: https://git.openjdk.java.net/jdk/pull/9017/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9017=01 Stats: 1752 lines in 39 files changed: 407 ins; 525 del; 820 mod Patch: https://git.openjdk.java.net/jdk/pull/9017.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9017/head:pull/9017 PR: https://git.openjdk.java.net/jdk/pull/9017
