Avoiding Future Security Bug Regressions

SnowyOwl vitaly.fedrushkov at gmail.com
Thu Feb 5 10:26:22 UTC 2009


On Feb 5, 03:23, Max Kanat-Alexander wrote:
>         2) All invasive security patches should be tested on
>            bugzilla.mozilla.org for at least 24 hours before a release.

On Feb 5, 04:50, David Miller wrote:
> This particular patch would have been on bmo about a month earlier if
> our management had their way.  It was purposefully withheld from being
> deployed on bmo until after the security release was ready to go out
> because the nature of the patch made it obvious that the fix had been
> applied and would immediately clue in anyone who hadn't already realized
> it what would need to be done to exploit other Bugzilla installations
> that didn't have it yet.

This is a question of b.m.o source version control being open OR
closed (at least at times) to avoid premature disclosure.

If we manage to keep a "private branch" in future DVCS, namely, commit
all patches except security sensitive into open branch and run b.m.o
from private branch -- this may satisfy both sides.

No, this does not eliminate chance of disclosure anyway, as http
traffic is still open to analysis.  But that's not the same as being
aware of, and seeing the patch itself.

  Regards,
  Vitaly.
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla



More information about the developers mailing list