On Fri, Jun 13, 2014 at 2:07 AM, Timo Teras <timo.te...@iki.fi> wrote:
> On Fri, 13 Jun 2014 01:57:25 -0500 > Matthew Jordan <mjor...@digium.com> wrote: > > > On Fri, Jun 13, 2014 at 1:50 AM, Timo Teras <timo.te...@iki.fi> wrote: > > > > > On 13 Jun 2014 01:39 -0500 > > > Asterisk Development Team <asteriskt...@digium.com> wrote: > > > > > > > The Asterisk Development Team has announced security releases for > > > > Certified Asterisk 1.8.15, 11.6, and Asterisk 1.8, 11, and 12. The > > > > available security releases are released as versions 1.8.15-cert7, > > > > 11.6-cert4, 1.8.28.2, 11.10.2, and 12.3.2. > > > > > > > > These releases are available for immediate download at > > > > http://downloads.asterisk.org/pub/telephony/asterisk/releases > > > > > > > > For a full list of changes in the current releases, please see the > > > > ChangeLogs: > > > > > > > > > > > > http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-1.8.15-cert7 > > > > > > > > http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-1.8.28.2 > > > > > > > > http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-11.6-cert4 > > > > > > > > http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-11.10.2 > > > > > > > > http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-12.3.2 > > > > > > Seems that the patch at: > > > > > > > http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-12.3.2-patch.gz > > > > > > Is cumulative as in, it applies to 12.3.0. And not incremental > > > applying to 12.3.1. I think they used to be incremental. Is this a > > > change in how the security patches will be shipped in future, or an > > > accident? > > > > In this case, that is not an accident. > > > > The regression was so serious that applying the patch for 12.3.1 by > > itself is "bad". My concern when making this (and we just finished > > this up after scrambling for the entire day, once we realized what > > happened) was two scenarios: > > (1) Someone would apply only the patch for 12.3.1, and end up with a > > crippling regression > > (2) Someone would casually read the security release announcement, > > only apply the patch for 12.3.2, and end up with a vulnerable system. > > > > With this case - where 12.3.2 contains the full delta between itself > > and 12.3.0, the worst that happens is you get the 'previously applied > > patch warning', and only if you applied the patch for 12.3.1 in the > > very short time that it was alive. That stinks, but feels like the > > best path forward through a bad situation. > > > > Thus: consider 12.3.2 as a complete replacement for 12.3.1. If I could > > remove all traces of 12.3.1 (and its companions), I would. Alas, > > that's ... really hard ... so it is what it is. > > > > Sorry for the confusion - > > This is bad for distro maintainers. We have automated systems that > either pick all or one of the patches. And having one-off exceptions > like this is really causing more problems than solving. > > Please could you regenerate it to be consistent. > 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. 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. I'll address this again after I've slept. -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev