RFR: 8341964: Add mechanism to disable different parts of TLS cipher suite [v5]

[Lothar Kimmeringer]

On Fri, 8 Nov 2024 14:54:45 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> * I think we shouldn't care if someone wants to use other regex syntax matching, maybe someone will find it useful. We just not going to document this to avoid any confusion, most people will just use `*`.

`*` isn't valid regex (which is why there is this conversion "under the hood") and as a user I don't expect that regex can be used if the documentation only mentions wildcards as they are used for globbing in e.g. bash. So as a user I might expect `?` for a single character to work but would realize quite fast that its use doesn't make much sense in the context of cipher-filtering.

> They should be able to use other regex (with `*` in place of `.*`) as long as at least one `*` is present and cipher suite starts with "TLS_".

I expect funny effects with `*` being used in a different context than `.*`, e.g. `\\d*` (any number of digits). This would be internally converted to `\\d.*` which represents something else completely (a single digit, followed by any number of characters).

> Filtering the pattern to disallow this will result in one extra regex matching operation while we try to keep things fast.

How often is this executed? My understanding is that this is happening during the startup of the VM, so one additional regex operation per cipher shouldn't have a big impact over an application's overall performance. 

>     * About just ignoring other regex characters with `Pattern.compile("^\\Q" + p.replace("*", "\\E.*\\Q") + "\\E$")`: I'm not sure if silently ignoring those characters is what we want, we should either disallow them (throw an exception) or allow those characters.

The support of regex isn't documented, so using special characters in the pattern shouldn't lead to an exception (be it because the pattern happen to be an invalid regex or because you throw one).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21841#discussion_r1834721975