On Fri, 8 Nov 2024 00:25:12 GMT, David Schlosnagle <d...@openjdk.org> wrote:
>> Artur Barashev 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 25 additional >> commits since the last revision: >> >> - Use atomic computeIfAbsent. Add more cipher suites to test. >> - Merge branch 'master' into JDK-8341964_regex >> - - Cache the patterns >> - Make matching case-sensitive >> - Update java.security documentation >> - Refactor the tests >> - "Cipher suites must start with TLS_" doc update >> - Update doc >> - Update the doc >> - DisabledAlgorithmConstraints already caches the results of checkAlgorithm >> call >> - Add cache of the wildcard matching results >> - Make matching case-insensitive. Compact the code. >> - 8341964: Add mechanism to disable different parts of TLS cipher suite >> - ... and 15 more: https://git.openjdk.org/jdk/compare/2e069576...98753b23 > > src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java > line 127: > >> 125: return patternCache.computeIfAbsent( >> 126: pattern, >> 127: p -> Pattern.compile(p.replace("*", ".*"))) > > Do we care if one uses other regex matching characters as part of the pattern > input, e.g. should `TLS_[a-zA-Z0-9_]+` be a valid input that disables some > algorithms? > > Should the matching be case insensitive? I've asked myself the same thing and I think that - if that's not supposed to be allowed - the following should solve that: p -> Pattern.compile("^\\Q" + p.replace("*", "\\E.*\\Q") + "\\E$") ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21841#discussion_r1833842384