<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 29, 2016 at 4:34 AM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Nov 27, 2016, at 11:29 PM, Corey Farrell wrote:<br>
> A review [1] has been posted to fix an issue where TLS servers would<br>
> not be restarted unless the bind address was changed.  This would<br>
> prevent use of new certificates if available.  Unfortunately this<br>
> change does cause an ABI change.  Fields are added to public<br>
> structures 'struct ast_tls_config' and 'struct<br>
> ast_tcptls_session_args'.  Within Asterisk itself these structures are<br>
> used by app_externalivr, chan_sip, res_http_websocket, http.c and<br>
> manager.c.<br>
><br>
> tcptls.h does not provide an allocation method for it's structures.<br>
> These means it is impossible to add fields to these structures without<br>
> breaking the ABI.  How does everyone feel about moving forward with<br>
> the fix as is?<br>
<br>
</span>When it comes to ABI compatibility I take what exactly is being changed<br>
into account. In the case of the TCP/TLS code it's not something I'd see<br>
outside code or developers using (the commercial modules certainly don't<br>
use it) which is why I'm personally not opposed to accepting it.<br>
<br>
Any other thoughts? Do we want to be strict and only allow on master?<br></blockquote><div><br></div><div>I'd say it's OK for 13.  I can't think of a scenario where an external module would be using these APIs.</div><div><br></div><div> </div></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div></div></div>
</div></div>