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

2018-07-23 Thread Chris Hegarty
Thanks for the review Sean, > On 23 Jul 2018, at 16:58, Sean Mullan wrote: > ... >> http://cr.openjdk.java.net/~chegar/8207846/webrev.00/ > > A few nits and wording suggestions in the java.security file: > > "By default, several exception messages do not include potentially sensitive >

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

2018-07-23 Thread Sean Mullan
On 7/23/18 6:09 AM, Chris Hegarty wrote: After given this some more thought, I now think that I gave in to the comment to change whitespace handing too easy. While maybe not consistent, with the already inconsistent, whitespace handling in java.security, I think ( for this particular case ) the

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

2018-07-23 Thread Chris Hegarty
Sean, > On 20 Jul 2018, at 18:07, Sean Mullan wrote: > > On 7/20/18 11:08 AM, Chris Hegarty wrote: >> 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." > >

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

2018-07-20 Thread Sean Mullan
On 7/20/18 11:08 AM, Chris Hegarty wrote: 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." Kind of on the fence on that one. If this were a general property/value

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

2018-07-20 Thread Chris Hegarty
> On 20 Jul 2018, at 16:15, Roger Riggs wrote: > > Hi Chris, > > The updated text is fine. > Thanks for your consideration. Updated webrev as discussed. http://cr.openjdk.java.net/~chegar/8207846/webrev.01/ -Chris.

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

2018-07-20 Thread Chris Hegarty
Roger, > On 20 Jul 2018, at 15:36, Roger Riggs 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.

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

2018-07-20 Thread Roger Riggs
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. I am more concerned about how command line properties are understood and used how we have to document them. Allowing

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

2018-07-20 Thread Chris Hegarty
Roger, > On 20 Jul 2018, at 14:52, Roger Riggs wrote: > > Hi Chris, > > It is very unusual for the processing of system properties to do *any* > parsing except for delimiters > including removing spaces, etc. It complicates the handling and sets a bad > precedent > that makes it more

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

2018-07-20 Thread Roger Riggs
Hi Chris, It is very unusual for the processing of system properties to do *any* parsing except for delimiters including removing spaces, etc.  It complicates the handling and sets a bad precedent that makes it more complex for users and developers to know how to set property values. The

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

2018-07-20 Thread Alan Bateman
On 20/07/2018 12:38, Chris Hegarty wrote: JDK-8204233 added a new security property, `jdk.net.includeInExceptions`, to include additional, potentially security sensitive, information in exception detail messages in the networking area. The property accepts a comma separated list of values that

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

2018-07-20 Thread Lindenmaier, Goetz
Hi, I scanned all the changes we did to exception messages in our internal VM, see below. We print paths and sockets in a row of places, but also other information. It's wide spread, while most is in java.base. We plan to contribute these messages in the near future. Thus it'll be useful if