(This email doesn’t introduce any policy changes, it’s just a reminder email.)
The sec-approval process serves as protection for users to make it more difficult for attackers to take advantage of our upcoming security patches before they make it to release. This is also called patch-gapping, and for more fun terminology see the post-script =) sec-approval applies to unrated security bugs and all bugs rated sec-high or sec-critical, and you must request sec-approval using the flag on the patch before landing it. You can read more about the sec-approval process <https://firefox-source-docs.mozilla.org/bug-mgmt/processes/security-approval.html> (this link is also in the bugzilla "SECURITY ISSUE" banner). The sec-approval team is myself and Dan Veditz, and in our absence you can also ping Freddy Braun. We’re pretty happy with how this has been working, and everyone’s doing a good job of it. *What we’re really writing this email for* is to remind folks that with our shortened release cycles, the window where we _can_ sec-approve and land patches is smaller than you think. We generally cannot sec-approve after the last beta uplifts until merge day - you can use https://fx-trains.herokuapp.com/ to check our release calendar. Taking the 101 release as an example, we started approving May 30, we stopped approving June 15th, and we will resume approving June 27. So in a four-week window, we’re only approving 2/3rds of the time. (If you have a bug that you think qualifies for an exception, please coordinate with us and relman as early as possible.) If you find your patches sitting with the sec-approval flag for more than 2 days - check the release calendar. If it’s in the first part of the cycle, feel free to drop me (or Dan) a needinfo or a message. Otherwise - sit tight. More improvements to sec-approval are coming, including reminders for landing tests. If you have any other questions, please also consult our documentation on Fixing Security Bugs in Firefox. <https://firefox-source-docs.mozilla.org/bug-mgmt/processes/fixing-security-bugs.html> Thanks for helping keep Firefox safe! -tom Post-Script: Terminology for nerds to make this email a little more fun: An “n-day” is a vulnerability that is known but whose fix hasn’t shipped out to users yet. In Firefox’s context this is typically patches that have landed in -central or -beta, but not shipped on release. More generally it can also apply to publicly disclosed bugs with no patch. N-day contrasts with 0-day, which is a vulnerability that has “zero days” between being known publicly and the first attack. Colloquially things get a bit fuzzy: people sometimes refer to a publicly known _vulnerability_ as 0day, but in most contexts 0day is used to refer to actual _exploits_. Additionally n-day can be used to refer to vulnerabilities that _have_ a patch, but people haven’t applied it yet. Finally, there’s the term ‘patch-gapping’, related to n-day, which almost always refers to watching for security patches landing in an open source repository and then writing an exploit for the vulnerability before the patch ships in a release. (A big part of what sec-approval is designed to prevent.) See this blog post for an example: https://blog.exodusintel.com/2019/09/09/patch-gapping-chrome/ -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CADua4_vhUj9wAS61q8uRJ67a5ugpmyk9mUuvztxTVj9SPR5ERw%40mail.gmail.com.
