<div dir="ltr"><div>I was looking at <a href="http://reviews.reviewboard.org">reviews.reviewboard.org</a> to see if anything was in the works to allow restricted reviews, I found <a href="https://reviews.reviewboard.org/groups/security/">https://reviews.reviewboard.org/groups/security/</a> - "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."<br><br></div><div>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.<br><br>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://...".</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 13, 2014 at 3:12 AM, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>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.<br>

<br></div>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.<br>

<br></div>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:<br>

</div><div>(1) Security issues are visible only to bug marshals (those with commit access) and the issue reporter<br></div><div>(2) Security issues are tagged typically with a "Security" label + (hopefully) a good summary to aid in filters and searches<br>

</div><div>(3) Peer review of patches typically occurs on the issue with the reporter. Often, only the reporter verifies the fixes<br></div><div>(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<br>

</div><div><br></div>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?<br>

<br>Matt<span class="HOEnZb"><font color="#888888"><br clear="all"><div><div><div><div><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></div></div></div></div></font></span></div>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></div>