[asterisk-dev] Asterisk 1.8.15-cert7, 1.8.28.2, 11.6-cert4, 11.10.2, 12.3.2 Now Available (Security/Regression Release)

[Matthew Jordan]

On Fri, Jun 13, 2014 at 2:07 AM, Timo Teras <timo.teras at iki.fi> wrote:

> On Fri, 13 Jun 2014 01:57:25 -0500
> Matthew Jordan <mjordan at digium.com> wrote:
>
> > On Fri, Jun 13, 2014 at 1:50 AM, Timo Teras <timo.teras at iki.fi> wrote:
> >
> > > On 13 Jun 2014 01:39 -0500
> > > Asterisk Development Team <asteriskteam at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140613/0f5b9609/attachment.html>