[asterisk-dev] What happened with the latest round of releases: or, "whoops"

Corey Farrell git at cfware.com
Fri Jun 13 02:44:19 CDT 2014


I was looking at reviews.reviewboard.org to see if anything was in the
works to allow restricted reviews, I found
https://reviews.reviewboard.org/groups/security/ - "This group is
invite-only. You must be a member of this group in order to see any review
requests assigned to it. You can ask the administrator or group owner for
access."

Could we get something similar working?  This would allow all security
related bugs to follow the same process as normal bugs, just limited to
those with commit access.

Some form of email to an invitation only mailing list would be very useful,
even if it is an uninformative notice: "Restricted review XXXX has been
updated and can be viewed at https://..."  The same applies to JIRA,
security bugs are not sent to asterisk-dev mailing list (this is good), but
the tickets are not known unless we search for them.  An email with minimum
information "JIRA ticket ASTERISK-XXXXX has been created or updated and can
be viewed at https://...".



On Fri, Jun 13, 2014 at 3:12 AM, Matthew Jordan <mjordan at digium.com> wrote:

> Apologies if this e-mail gets a bit rambling; by the time I send this it
> will be past 2 AM here in the US and we've been scrambling to fix the
> regression caused by r415972 without reintroducing the vulnerability it
> fixed for the past 9 hours or so.
>
> Clearly, there are things we should have done better to catch this before
> the security releases went out yesterday. The regression was serious enough
> that plenty of tests in the Test Suite caught the error - in fact,
> development of a test on a local dev machine was how we discovered that the
> regression had occurred.
>
> At the same time, this problem exposes a hole in our security issue +
> release process: namely, that in order to maintain security, transparency
> of the issues and patches is sacrificed. The first instance where a
> security issue is made public is when the commit for the issue occurs, and
> at that point, a clock starts ticking: we have to get releases made as fast
> as possible, as the vulnerabilities are now known. Typically, this means
> the following:
> (1) Security issues are visible only to bug marshals (those with commit
> access) and the issue reporter
> (2) Security issues are tagged typically with a "Security" label +
> (hopefully) a good summary to aid in filters and searches
> (3) Peer review of patches typically occurs on the issue with the
> reporter. Often, only the reporter verifies the fixes
> (4) Here at Digium, we do peer review all security fixes - but
> disregarding communication that occurs on the issue, much of that occurs
> internally as public e-mails would result in a disclosure of the
> vulnerability
>
> So my question to you, fellow developers in the community: how can we
> improve this? Can we do something different that would maintain security
> for users of Asterisk, while encouraging more participation from the
> community in the development, review, and testing of security patches?
>
> Matt
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140613/61b4049f/attachment-0001.html>


More information about the asterisk-dev mailing list