<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 13, 2014 at 4:41 AM, Steven Howes <span dir="ltr"><<a href="mailto:steve-lists@geekinter.net" target="_blank">steve-lists@geekinter.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 13 Jun 2014, at 08:12, Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>> wrote:<br>

> 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>
> 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>I’ve not been directly involved with the whole commit/testing procedure, so excuse me if I’m misreading anything..<br>
<br>
If it fails the tests, how was it released? I understand the whole reduced transparency/communications thing, it’s an unfortunate necessity of dealing with security issues. I can’t see how that excludes the testing carried out by the Test Suite though?<br>

<br>
Kind regards,<br>
<br></blockquote><div><br></div><div style>Disregarding local test suite runs, a few things happened here:</div><div style><br></div><div style>(1) Four security patches were made at roughly the same time. Unfortunately, the patch with the issue was the last one to get committed - and by the time that occurred, there were a large number of jobs scheduled in front of it.</div>
<div style><br></div><div style>(2) The order of execution of jobs in Bamboo is the following:</div><div style>     (a) Basic build (simple compile test) on first available build agent =></div><div style>     (b) Full build (multiple compile options, e.g., parallel builds) on all different flavors of build agent =></div>
<div style>     (c) Unit test run =></div><div style>     (d) Channel driver tests in the Test Suite =></div><div style>     (e) ARI tests in the Test Suite</div><div style>    Nightly, a full run of the test suite takes place.</div>
<div style><br></div><div style>    This issue would have been caught by step (d) - but each of the previous steps takes awhile to complete (Asterisk doesn't compile quickly). A test suite run takes a long time - even with the reduced sets of tests in steps (d) and (e). Each merge in a branch causes this process to kick off - and there were at least 7 iterations of this in front of it. Which leads to point #3:</div>
<div style><br></div><div style>(3) The merge process on the offending patch was slowed down due to merge conflicts between branches. The merging of the patch into all branches wasn't complete until nearly 3 PM, which meant we had very little time to get the releases out - generally, we strive hard to get the security releases out the door as early as possible, so system administrators have time that day to upgrade their systems if they are affected.</div>
<div style><br></div><div style>All of that aside, there's a few things (again, beyond running the test suite locally) that could be done to improve the situation:</div><div style><br></div><div style>(a) Add a 'smoke test' to the Test Suite that gets run either in the Basic Build or Full Build steps. This would do some very simple things: originate a call over AMI with a Local channel, use a SIP channel to connect to another instance of Asterisk, pass media/DTMF, bounce back to the test using AGI, and maybe a few other things. Such a test could hit a lot of our normal 'hot spots' and - if run early enough in the cycle - would flag developers quicker than the current process.</div>
<div style><br></div><div style>(b) Throw some more hardware at the problem. Right now, we have a single 32-bit/64-bit CentOS 6 machine - we could easily double that up, which would get results faster.</div></div><div><br>
</div>-- <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>