Adding SocketChannel toString to connection exception messages

[Seán Coffey]

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 <david.holmes at oracle.com> 
>>>> wrote:
>>>>
>>>> On 22/12/2017 10:29 AM, Steven Schlansker wrote:
>>>>>> On Dec 21, 2017, at 11:11 AM, Steven Schlansker 
>>>>>> <stevenschlansker at 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...
>
> 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.