Avoiding Future Security Bug Regressions

Max Kanat-Alexander mkanat at bugzilla.org
Thu Feb 5 23:55:49 UTC 2009


On Thu, 5 Feb 2009 16:18:23 -0600 Bradley Baetz <bbaetz at acm.org> wrote:
> True, but it'd be less confusing and difficult than releasing another
> security fix the next day, then another one shortly for any other
> regression fixes.

	That's not what I'm proposing. I'm proposing that bmo run the
code that will be released before a release is made.

> This particular issue was different to most, both because it was
> obvious what was changing and because it was very invasive. In general
> I'm agreeing with your original mail, but where the fix and issue is
> obvious even without the code, what do we do for the other sites?

	I think 24 hours is a safe period for us to not release
the details of the advisory, even if there are operational clues that
indicate that there is a security issue. 

	It needs live testing, and this is just the only feasible way.
The regressions we've noticed so far weren't found in closed testing,
only in live tests.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.



More information about the developers mailing list