On Mon, 26 May 2025 19:22:39 GMT, Alan Bateman <al...@openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:
>> 
>>> 251:             return;
>>> 252:         enhancedSocketExceptionText = 
>>> SecurityProperties.includedInExceptions("hostInfo");
>>> 253:         enhancedNonSocketExceptionText = 
>>> SecurityProperties.includedInExceptions("hostInfoExclSocket")
>> 
>> This looks like the inverse of the previous use of a socket category, except 
>> this time it anything that is not in Socket.
>> 
>> Consider the following: 
>> includeInException specifies the type of information that maybe included in 
>> an enhanced exception 
>> e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), 
>> JarDetails, All
>> This defines an information policy 
>> 
>> developer are familiar with packages, so a second property specified the 
>> "domain" of application of an information policy:  
>> enhancedException.packages specifies a list of packages where the 
>> includeInException information policy will apply
>> 
>> an empty list or the enhancedException.packages means freedom of information 
>> and the defined includedInException applies to all packages
>
>> This looks like the inverse of the previous use of a socket category, except 
>> this time it anything that not in Socket.
> 
> I think the PR has it right. No change to existing behavior. To opt-in and 
> reveal more host information in exceptions then you can run it with 
> configured to "hostInfo".  It does mean repurposing the name but it's a good 
> name going forward.

The point I was raising, is that the socket etc category was dropped under the 
premise that it requires knowledge of the APIs used. 
But equally the setting hostInfoExclSocket suggests some knowledge of APIs is 
available, so there is a contradiction in the rationale presented above
Also the setting enhancedNonSocketExceptionText is inclusive of the setting 
enhancedSocketExceptionText, which adds further subtleties to the 
configuration, which was previously suggested should be avoided.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107873149

Reply via email to