<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 13, 2014 at 2:07 AM, Timo Teras <span dir="ltr"><<a href="mailto:timo.teras@iki.fi" target="_blank">timo.teras@iki.fi</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, 13 Jun 2014 01:57:25 -0500<br>
Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>> wrote:<br>
<br>
> On Fri, Jun 13, 2014 at 1:50 AM, Timo Teras <<a href="mailto:timo.teras@iki.fi">timo.teras@iki.fi</a>> wrote:<br>
><br>
> > On 13 Jun 2014 01:39 -0500<br>
> > Asterisk Development Team <<a href="mailto:asteriskteam@digium.com">asteriskteam@digium.com</a>> wrote:<br>
> ><br>
> > > The Asterisk Development Team has announced security releases for<br>
> > > Certified Asterisk 1.8.15, 11.6, and Asterisk 1.8, 11, and 12. The<br>
> > > available security releases are released as versions 1.8.15-cert7,<br>
> > > 11.6-cert4, 1.8.28.2, 11.10.2, and 12.3.2.<br>
> > ><br>
> > > These releases are available for immediate download at<br>
> > > <a href="http://downloads.asterisk.org/pub/telephony/asterisk/releases" target="_blank">http://downloads.asterisk.org/pub/telephony/asterisk/releases</a><br>
> > ><br>
> > > For a full list of changes in the current releases, please see the<br>
> > > ChangeLogs:<br>
> > ><br>
> > ><br>
> > <a href="http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-1.8.15-cert7" target="_blank">http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-1.8.15-cert7</a><br>

> > ><br>
> > <a href="http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-1.8.28.2" target="_blank">http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-1.8.28.2</a><br>
> > ><br>
> > <a href="http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-11.6-cert4" target="_blank">http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-11.6-cert4</a><br>

> > ><br>
> > <a href="http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-11.10.2" target="_blank">http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-11.10.2</a><br>
> > ><br>
> > <a href="http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-12.3.2" target="_blank">http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-12.3.2</a><br>
> ><br>
> > Seems that the patch at:<br>
> ><br>
> > <a href="http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-12.3.2-patch.gz" target="_blank">http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-12.3.2-patch.gz</a><br>
> ><br>
> > Is cumulative as in, it applies to 12.3.0. And not incremental<br>
> > applying to 12.3.1. I think they used to be incremental. Is this a<br>
> > change in how the security patches will be shipped in future, or an<br>
> > accident?<br>
><br>
> In this case, that is not an accident.<br>
><br>
> The regression was so serious that applying the patch for 12.3.1 by<br>
> itself is "bad". My concern when making this (and we just finished<br>
> this up after scrambling for the entire day, once we realized what<br>
> happened) was two scenarios:<br>
> (1) Someone would apply only the patch for 12.3.1, and end up with a<br>
> crippling regression<br>
> (2) Someone would casually read the security release announcement,<br>
> only apply the patch for 12.3.2, and end up with a vulnerable system.<br>
><br>
> With this case - where 12.3.2 contains the full delta between itself<br>
> and 12.3.0, the worst that happens is you get the 'previously applied<br>
> patch warning', and only if you applied the patch for 12.3.1 in the<br>
> very short time that it was alive. That stinks, but feels like the<br>
> best path forward through a bad situation.<br>
><br>
> Thus: consider 12.3.2 as a complete replacement for 12.3.1. If I could<br>
> remove all traces of 12.3.1 (and its companions), I would. Alas,<br>
> that's ... really hard ... so it is what it is.<br>
><br>
> Sorry for the confusion -<br>
<br>
</div></div>This is bad for distro maintainers. We have automated systems that<br>
either pick all or one of the patches. And having one-off exceptions<br>
like this is really causing more problems than solving.<br>
<br>
Please could you regenerate it to be consistent.<br></blockquote><div><br></div><div>While I sympathize with distro maintainers, I'm not sure creating a situation where someone may manually patch Asterisk themselves and leave themselves vulnerable is superior. That feels like putting ourselves before users, which is not something I typically agree with.<br>
</div><div><br></div><div>Regardless, I've been at this now for 20 hours. I'm not sure what I would generate would be correct at this point, and I don't think introducing more risk into this process at this point in time is a good idea.<br>
<br></div><div>I'll address this again after I've slept.<br></div></div><br>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div>
<div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div>
</div></div>