<div dir="ltr">Hi!<div><br></div><div>Thank you for the pull requests we are working on including them, probably with some own additions to 340. More info will come on the pull requests later.</div><div><br></div><div><br>
<div class="gmail_extra"><div class="gmail_quote">2014-04-20 1:52 GMT+02:00 Danil Zagoskin <span dir="ltr"><<a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Hello again!<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">function_clause in </span><span style="font-size:13px;font-family:arial,sans-serif">tls_connection:handle_tls_</span><span style="font-size:13px;font-family:arial,sans-serif">handshake</span> is fixed in this PR: <a href="https://github.com/erlang/otp/pull/339" target="_blank">https://github.com/erlang/otp/pull/339</a></div>


<div><br></div><div>One more crash (badarg in crypto:sign) is fixed in that PR: <a href="https://github.com/erlang/otp/pull/340" target="_blank">https://github.com/erlang/otp/pull/340</a></div><div><br></div><div>For other ssl users: these two patches with two Ingela's patches:</div>


<div> - <a href="https://github.com/IngelaAndin/otp/commit/7f0e683bc483b70f05fa806539bd5c540943dfd0" target="_blank">https://github.com/IngelaAndin/otp/commit/7f0e683bc483b70f05fa806539bd5c540943dfd0</a></div><div> - <a href="https://github.com/IngelaAndin/otp/commit/26082cdd64823ecf92c47188f5a161e5ff2f8660" target="_blank">https://github.com/IngelaAndin/otp/commit/26082cdd64823ecf92c47188f5a161e5ff2f8660</a></div>


<div>seem to fix most of ssl server crashes in OTP 17.0.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="gmail_extra"><br></div></blockquote></div></div></div></div></blockquote><div> </div><div>[...] </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div><br></div><div>Could that client work with other server implementation?</div>




<div>tls_handshake_buffer seems like a garbage (but I'm not sure), so maybe here's no valid client lost.</div><div><br></div><div>Should server tolerate such conditions? Should an alert be thrown when tls_handshake:get_tls_handshake returns {[], _}?</div>





<div><br></div></div></blockquote></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div><br></div><div>In general we do program for the correct case, but yes we want to make the server fault tolerant and we do use "try" and  sometimes "catch all clauses" to stop gracefully and send</div>
<div>alerts. </div><div><br></div><div> [...] </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div>Another question about crashes:</div><div>Maybe tls_connection is a good place for format_status/2? It may be a good idea to hide secrets when printing state (otherwise a person which has access to error logs seems to be able to restore the private key or decipher dumped traffic).</div>





<div><br></div></div></blockquote></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div><br></div><div>Point taken I will create a ticket for this. </div><div><div>[...] </div></div><div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div class="h5">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div style="color:rgb(34,34,34)">
<br></div></div><div><br></div><div><br></div><div>My interpretation:</div><div>  - Given pool size X, the first of each X requests fails.</div><div>  - First of failing requests catches timeout as expected, other ones just stall.</div>








<div>  - Failing requests have emulated options [{mode, list}, {active, true}] while working ones have the opposite [{mode, binary}, {active, false}].</div><div><br></div><div>After couple of further experiments I discovered that only every (X*N + 1)th acceptor inherits listening socket options, other ones always have [{mode, binary}, {active, false}].</div>








<div><br></div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></div></blockquote><div><br></div><div><br></div><div>Humm .... this has to do with inheritance of socket options from listen socket to accept socket and the fact that some socket options need to be emulated, and how its is implemented. The current implementation will not work for a pool of listen sockets.  I have not had time solve this problem yet but it is on the todo list.</div>
<div><br></div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB</div><div> </div></div></div></div></div>