Security/Bug Approval Process: Difference between revisions

* When sec-approval+ is given, commits should occur without specific mention of security, security bugs, or sec-approvers if possible. As above, if you can check-in with a cover bug in the same area to obfuscate that there is a security fix, that is ideal.

* Avoid linking it to non-security bugs with Blocks, Depends, or See Also, especially if those bugs may give a hint to the sort of security issue involved.  Mention the bug in a comment on the security bug instead. We can always fill in the links later after the fix has shipped.

* Do not commit tests when checking in to mozilla-central or, later, branches, when the security bug fix is initially checked-in. Remember we don’t want to 0-day ourselves! Tests should only be checked in later, after an official Firefox release that contains the fix has gone live and not for at least four weeks following that release. For example, if Firefox 53 contains a fix for a security issue that affects the world and is then fixed in 54, tests for this fix should not be checked in until four weeks after 54 goes live. The exception to this is if there is a security issue that hasn’t shipped in a release build and it is being fixed on multiple development branches (such as mozilla-central and aurora). Since the security problem was never released to the world, once the bug is fixed in all affected places, tests can be checked in to the various branches.