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