Avoiding Future Security Bug Regressions

[Vlad Dascalu]

There are two factors here pushing in opposite ways:

(A) -> the speed of getting security bugs fixed / reviewed / commited.
(B) -> the speed that BZ installation admins can tolerate in trying out and
installing new versions.

Firefox has a very fast (B), because:

-> it has an auto-updater.
-> it's client sofware.

Bugzilla has a much slower (B), because:

-> it doesn't have an auto-updater.
-> it's server software.
-> an upgrade impacts the entire organization, not just one user.

So while the code HEAD in our version-control system is a great way to
iterate, our end-users have a much slower (B) compared to the (B)'s of other
MoFo products (Firefox included).

You want to avoid regressions by having only one security fix per release.
While this would work great in environments where you have a fast (B), I'm
afraid it would suck for Bugzilla (for the reasons above).

The way to avoid regressions with a slow (B) is to have better QA, not to
increase release cycles to a rate which users can't keep up with, especially
since we can't vouch for our releases' regressions.


On Sat, Feb 7, 2009 at 6:57 AM, Max Kanat-Alexander <mkanat at bugzilla.org>wrote:

> On Wed, 4 Feb 2009 16:43:31 -0600 Reed Loden <reed at reedloden.com> wrote:
> > If there are critical security
> > bugs that need to get fixed, they should get fixed ASAP and not depend
> > on waiting until some future release.
>
>         I agree, that's why we should release as soon as we have a
> security patch. We didn't have to fix both issues in one release.
>
> > You shouldn't be risking users
> > just because you don't want Bugzilla to look bad that it has to
> > release twice within 24 hours.
>
>         I assume you meant that we shouldn't be putting users at risk,
> and I understand that, and I agree. We shouldn't be putting users at
> 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.
>
>        There are other risks than just security risks--risks far more
> common. The risk of lost productivity, the risk of data loss, the risk
> of critical bugs that make a product unusable. We shouldn't be placing
> users at risk of those things, and as we include more invasive patches
> in one stable release without live testing, those risks dramatically
> multiply.
>
> > If this same policy was applied to Firefox [snip]
>
>        Although I think that what I said above is enough, and that I
> do understand what you're saying here, since this has been coming up
> more and more, I'd like to take this opportunity to point this out:
>
>        Firefox and Bugzilla are not comparable products. The only
> thing they have in common is that they are both software, and they are
> both open-source. Firefox has numerous paid developers, an entire
> funded organization, and numerous highly involved QA tests and
> procedures. Firefox has an auto-updater.
>
>        Bugzilla has zero full-time developers, none of whom are paid
> in any way. It has exactly two people who spend a significant amount of
> their time on it (myself and LpSolit), and a small community of
> additional contributors and active reviewers (who, by the way, are
> extremely appreciated, and I wish that we had more and more people who
> contributed and reviewed!). Our IT team essentially consists of me and
> some time from Mozilla IT that Community Giving is gracious enough to
> pay for. Our release team currently consists of just me.
>
>        Although I'd love to have a real funded organization behind
> Bugzilla, and maybe some day we will, in the present moment we have to
> adopt policies that work for our environment, and that is an
> environment of *limited resources*. Having limited resources means that
> we must accept and understand our limited capabilities, and adapt
> ourselves in ways that we can still produce a quality product within
> those constraints.
>
>        I proposed these policies because they work within those
> limited constraints, not because I believe they are the best policies
> any project can adopt. They will work to prevent similar situations as
> our recent one, in the future, and that is what I am most concerned
> about.
>
>        What happened was extremely dangerous, both to our users and
> to us as a project, and we have to not just handle the dangerous
> situation (as we did), but also make sure that we adopt firm solutions
> that will prevent the same situation from recurring in the future.
>
>        -Max
> --
> http://www.everythingsolved.com/
> Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd@bugzilla.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20090208/9ced23ab/attachment.html>