Re: Adding SocketChannel toString to connection exception messages
On 22/12/17 01:27, David Holmes wrote: 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 wrote: On 22/12/2017 10:29 AM, Steven Schlansker wrote: On Dec 21, 2017, at 11:11 AM, Steven Schlansker 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... And to someone trying to discern private information about a network. Could it be an opt-in policy? Perhaps by a system property? Well, you don't know where a log file or exception will end up. Most likely on stackoverflow. 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. Agreed. It may be some work, but if the issue is significant enough to the user then it may be worth their effort, as well as affording the opportunity to opt-out at any particular point in the code. 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" Exactly. 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). I have to agree with David here. I don't think that such a request could be supported. -Chris.
Re: Adding SocketChannel toString to connection exception messages
As someone who works with alot of log files, I'd like to chime in and support Steven's end goal. Looking at a "Connection refused" error in the middle of a log file that possibly extends to millions of lines is near useless. In the era of cloud compute, diagnosing network issues is sure to become a more common task. While we may not be able to put the sensitive information in an exception message, I think we could put it behind a (new?) system property which might be able to log this information. Logs contain all sorts of sensitive data. Take javax.net.debug=ssl output for example. Regards, Sean. On 22/12/17 09:57, Chris Hegarty wrote: On 22/12/17 01:27, David Holmes wrote: 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 wrote: On 22/12/2017 10:29 AM, Steven Schlansker wrote: On Dec 21, 2017, at 11:11 AM, Steven Schlansker 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... And to someone trying to discern private information about a network. Could it be an opt-in policy? Perhaps by a system property? Well, you don't know where a log file or exception will end up. Most likely on stackoverflow. 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. Agreed. It may be some work, but if the issue is significant enough to the user then it may be worth their effort, as well as affording the opportunity to opt-out at any particular point in the code. 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" Exactly. 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). I have to agree with David here. I don't think that such a request could be supported. -Chris.
Re: Adding SocketChannel toString to connection exception messages
On 22/12/17 14:59, Seán Coffey wrote: As someone who works with alot of log files, I'd like to chime in and support Steven's end goal. Looking at a "Connection refused" error in the middle of a log file that possibly extends to millions of lines is near useless. In the era of cloud compute, diagnosing network issues is sure to become a more common task. While we may not be able to put the sensitive information in an exception message, I think we could put it behind a (new?) system property which might be able to log this information. Logs contain all sorts of sensitive data. Take javax.net.debug=ssl output for example. I have some sympathy for (capital-L)ogging such detail messages ( given the reasonable restriction on access to log files ), but a system property that effectively amends exception detail messages, or prints to stdout/stderr is not a runner in my opinion. Maybe we should be looking at instrumentation with JFR events, or similar. My point being, if someone has time and energy enough to spend on this, then we can do better than javax.net.debug=ssl. Also, someone should check that divulging such sensitive information, even in log files, is acceptable from a security perspective. I'm personally still dubious. -Chris.
Re: Adding SocketChannel toString to connection exception messages
Hello, I also dearly miss Socket addresses in connection exceptions, however it looks like it is not going to make it. However if we add a getter for the Peer address (not included in toString) then logging frameworks could detect instances of ConnectException and process them accordingly. Gruss Bernd -- http://bernd.eckenfels.net From: net-dev on behalf of Chris Hegarty Sent: Friday, December 22, 2017 4:17:31 PM To: Seán Coffey; David Holmes; Steven Schlansker Cc: core-libs-dev; net-dev@openjdk.java.net Subject: Re: Adding SocketChannel toString to connection exception messages On 22/12/17 14:59, Seán Coffey wrote: > As someone who works with alot of log files, I'd like to chime in and > support Steven's end goal. Looking at a "Connection refused" error in > the middle of a log file that possibly extends to millions of lines is > near useless. In the era of cloud compute, diagnosing network issues is > sure to become a more common task. > > While we may not be able to put the sensitive information in an > exception message, I think we could put it behind a (new?) system > property which might be able to log this information. Logs contain all > sorts of sensitive data. Take javax.net.debug=ssl output for example. I have some sympathy for (capital-L)ogging such detail messages ( given the reasonable restriction on access to log files ), but a system property that effectively amends exception detail messages, or prints to stdout/stderr is not a runner in my opinion. Maybe we should be looking at instrumentation with JFR events, or similar. My point being, if someone has time and energy enough to spend on this, then we can do better than javax.net.debug=ssl. Also, someone should check that divulging such sensitive information, even in log files, is acceptable from a security perspective. I'm personally still dubious. -Chris.
