cc'ing net-dev as that might be the more appropriate list.
On 22/12/2017 10:59 AM, Steven Schlansker wrote:
On Dec 21, 2017, at 4:35 PM, David Holmes <david.hol...@oracle.com> wrote:
On 22/12/2017 10:29 AM, Steven Schlansker wrote:
On Dec 21, 2017, at 11:11 AM, Steven Schlansker <stevenschlans...@gmail.com>
wrote:
What if ConnectException included the attempted hostname / IP / port
SocketAddress?
java.net.ConnectException: Connection to 'foo.mycorp.com[10.x.x.x]:12345'
refused
Much more useful! This could also be extended to various other socket
exceptions.
I believe there are concerns with too much information that can be considered
"sensitive" (like host names and IP addresses) appearing in error messages due
to them ending up in log files and bug reports.
Unfortunately that's exactly the information that is crucial to someone trying
to diagnose issues...
Could it be an opt-in policy? Perhaps by a system property?
The expectation is that such information should be added by layers
higher in the call chain, rather than the JDK libraries assuming it is
okay to do.
Currently the alternative I'm faced with is going through every piece of user
code and library that *might*
throw this exception and wrapping it to add this critical diagnostic
information. For an application that uses
java.net heavily, you can imagine how that is a tall task and possibly even not
realistically achievable...
(Is there a written policy regarding this somewhere, or is it up to the
personal feelings of the contributors?)
This is covered by the secure coding guidelines, under 'Confidential
information':
http://www.oracle.com/technetwork/java/seccodeguide-139067.html#2
"Guideline 2-1 / CONFIDENTIAL-1: Purge sensitive information from
exceptions"
I know for a fact that we'd have to scrub this information from test
failures when putting the info into a bug report.
If net-dev folk can't expand further on this then I suggest filing a CSR
request so that the CSR group can consider it. But I think this will be
a no-go (I'm a member of the CSR group).
Cheers,
David
