RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

[Roger Riggs]

Hi Chris,

The updated text is fine.
Thanks for your consideration.

The overlapping of configure options between java.security, 
net.properties, etc.
and command line options is something to keep an eye on.

Roger


On 7/20/18 11:08 AM, Chris Hegarty wrote:
> Roger,
>
>> On 20 Jul 2018, at 15:36, Roger Riggs <roger.riggs at oracle.com> wrote:
>>
>> Hi Chris,
>>
>> It is important to be clear about how whitespace is treated and within the java.security file
>> there are other uses that explicitly define how whitespace is used.
> Right, and the usages are already inconsistent. Nothing we can
> do about that now.
>
>> I am more concerned about how command line properties are understood and used how we have to document them.
>> Allowing whitespace quickly gets bogged down in how shells handle quotes, telling people they have to
>> quote them and when/whether you have to quote the quotes.
> You cannot disallow whitespace, simple ignore them or consider
> them part of the value.
>
>> Having a consistent treatment of command line and security properties keeps the
>> story simple and easier to support.
> This file is already inconsistent, trimming happens in some cases.
> Whitespaces are either trimmed, ignored, or considered as like
> any other character.
>
>> The jdk.serialFilter property had the same issue and is explicit in the java.security file
>> that spaces are just another character and are not treated specially.
> This is a reasonable position.
>
>> Its a slippery slope, if we start compensating/ignoring whitespace in some properties
>> then we will have to keep explaining how some are treated differently.
>> I would keep the original non-whitespace description.
> Original: "This property may be set to one or more values,
> separated by commas, and with no white-space”
>
> This is ambiguous, and needs to be clarified. Surely, it is
> better to use the same wording as the serial filter:
>
>   "Whitespace is significant and is considered part of the value."
>
>> Case-insensistive compares are another slippery slope but make a bit more sense for usability.
> The complete updated text:
>
> #
> # Enhanced exception message information
> #
> # By default, several exception messages do not include potentially sensitive
> # information such as file names, host names, or port numbers. This property may
> # be used to enable categories of enhanced information in exception messages.
> # The property accepts one or more comma separated values, each of which
> # represents a category of enhanced exception message information to enable.
> # Values are case-insensitive. Whitespace is significant and is considered part
> # of the value. Unknown values are ignored.
> #
> # The categories, to enable enhanced exception message information, are:
> #
> #  hostInfo - IOExceptions thrown by java.net.Socket and also the socket types
> #             in the java.nio.channels package will contain enhanced exception
> #             message information
> #
> # The property setting in this file can be overridden by a system property of
> # the same name, with the same syntax and possible values.
> #
> #jdk.includeInExceptions=hostInfo
>
> -Chris.
>