On Fri, 15 Nov 2024 01:12:55 GMT, Bradford Wetmore <wetm...@openjdk.org> wrote:
>> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 90:
>>
>>> 88: && property.length() == 10
>>> 89: &&
>>> !Character.isLetterOrDigit(property.charAt(3))
>>> 90: && property.endsWith("expand"));
>>
>> I believe this is not needed, and the code can be simplified using the same
>> style as I remember from the earlier stack. I'll look at this tomorrow.
>
> With the current definition in the JSSE docs, `sslexpandhandshakeverbose` is
> an acceptable value, as are the tokens in any order. e.g.
> `sslverbosehandshakeexpand` or
> `ssl|moohaha|handshake2354432verbose@#%^%SeanWasHere,keygen`. This code here
> is position dependent and won't allow it.
>
> This approach needs a rethink. Maybe an `EnumSet` initialized here that
> contains the active, known `ssl` options, that is then checked during the
> `isOn(checkPoints)`? Just a thought.
`sslexpandhandshakeverbose` works in the new implementation.
the `sslOn `boolean is a fast path helper. We fall back to matching per debug
option if required.
I'm going to suggest that we shouldn't have to accept
`ssl|moohaha|handshake2354432verbose@#%^%SeanWasHere,keygen` as a valid
property value. The lax parsing currently used is somewhat to blame for
javax.net.debug parsing being so badly broken since its introduction in the new
TLSv1.3 stack in 2018. i.e. passing the widely documented `ssl` is broken
today. I'm not as concerned as some code that might be trying to use the
`sslexpandhandshakeverbose` example!
can we document some reasonable separators ? We could go with an EnumSet design
approach but I do think it's time we specify a valid separator if so.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r1848286345
