[erlang-bugs] inet_ssl_dist bugs in R11B-5

[Bruce Fitzsimons]

Right, I've found the right lists now.

I don't know why the standard debugging flag (ERL_SSL_DEBUG) stops erts 
from starting up when in ssl_dist mode, but I worked around that.

There was a variety of bugs caused by the reworking of ssl to break 
accept into two (transport_accept and ssl_accept). I've got it working 
now, but I am not convinced that it is a nice as it could be.
1. There was a fault where ssl_prim was passing an FD into a function 
that expected a socket, but the call was wrapped in a catch and a 
transform to a normal error. So the 'EXIT' was masked. I'd recommend 
against this approach having been forced to debug through it...at least 
let 'EXIT' fall through?
2. The state was being stomped on in ssl_prim - it was initialised in 
transport_accept, then the result was initialised again (effectively) in 
ssl_accept.
3. badarg caused by weird options being passed to connect_proxy. A 
common thread though ssl_* seems to be the carriage of state around that 
includes options for opening a socket which are frequently touched, so 
the original list is lost. ssl_broker also has a bunch of 
"transformation" functions to remove the not applicable ones, but it 
seems like an odd approach. I've tried to go back to the original 
(R11B-0) intent of passing the original ListenPort arguments in rather 
than the ones modified by transport_accept. I'm not sure that this was 
really required, however what was required was the change (back) of one 
of the connection options to exclude the ssl options. Including the ssl 
options was an odd change to make given the name of the function was 
"is_tcp_accept_opt" but there may have been a reason.
4. undefined was misspelt.

I think that's about it. I will post the patch to the patches list 
presently. I would appreciate it if a unit test for inet_dist_ssl was 
added to avoid this kind of thing in the future; it was quite badly 
busted and this is good functionality.

The changes I have made may have broken normal ssl operations, so a 
thorough review is in order.

Regards,
Bruce