RFR  8207846: Generalize the jdk.net.includeInExceptions security property
roger.riggs at oracle.com
Fri Jul 20 15:15:20 UTC 2018
The updated text is fine.
Thanks for your consideration.
The overlapping of configure options between java.security,
and command line options is something to keep an eye on.
On 7/20/18 11:08 AM, Chris Hegarty wrote:
>> 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.
More information about the core-libs-dev