Avoiding Future Security Bug Regressions

[Frédéric Buclin]

Le 07. 02. 09 06:57, Max Kanat-Alexander a écrit :
> risk. In this case, we put users far more at risk by releasing multiple
> invasive patches on a stable branch without any time for live testing.

I agree that invasive patches are more likely to trigger regressions 
than one-liners (though it's not impossible that a one-liner also breaks 
something). But I would like to note that it's probably the last time 
that we will land such invasive patches on branches, because...

1) We are for a few years pretty prompt to fix security issues and 
crashes when we find them and so to prevent to have 4 branches being 
affected before starting worrying about them.

2) We are much more focused on security issues and stability problems 
than in the past, IMO. One reason is the rearchitecture which has been 
done for a few years which much more easily let us catch possible 
regressions. Another reason is the creation of the QA team which is able 
to catch most common problems thanks to their QA tests. As a 
consequence, patches are rather well tested before landing in CVS.

3) There are no more old security bugs which are here for years and 
which nobody wanted to fix because they were hard to fix (I probably 
fixed 80% of the security bugs in these last 4 years myself). I think 
any new security bug will be related to new features only and so will 
affect only a small number of branches, which should limit the risk to 
regress something.


LpSolit