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

Reply via email to