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 <[email protected]> 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 >
-- _____________________________________________________________________ -- 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
