RFR: 8044609: javax.net.debug options not working and documented as expected [v8]

[Sean Coffey]

On Fri, 15 Nov 2024 01:12:55 GMT, Bradford Wetmore <wetmore at 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