Skip to content

Security Advisories

Jump to bottom
Matt Lichtenstein edited this page Nov 25, 2024 · 24 revisions

Overview

This page documents the process to create security advisories for Firefox and Focus for iOS. If you're looking for what the advisories actually are; please go to this webpage.

The general process, omitting getting access and first time setup is to:

  • Check for advisories (resolved bugs) for current release versions
    • This is where we make sure the Bugzilla ticket has the required information and tagged properly.
  • Generate the YAML file for the advisory
  • Create a PR on the private repo

Publishing Schedule

Security advisories should be published (submitted to the private repro, as discussed below) by the end of the week for each release candidate. Release candidate dates (along with other important milestones for each release) can be found on the iOS calendar.

Firefox vs. Focus

The process for Firefox and Focus tickets is largely identical, however some of our scripts are not setup properly to check Bugzilla Focus tickets due to differences in the fields on the tickets. Until this is resolved, you will want to double-check for Focus tickets and you may need to create the YAML file manually.

First-time Setup

Access and roles

To be able to do a security advisories, you'll need specific accesses and roles.

Github Repo

Python virtual environment

Running security advisories script requires a python script. This is done easily by installing requirements in a virtual environment. There's more than one way to do this, but here's one:

  • Install virtual environment with pip3 install virtualenv. If you have issues in your path and virtualenv is not found, you can try to uninstall and reinstall again with sudo.
  • Navigate to the root of the secadv project
  • Create virtual environment with virtualenv -p python3 secadv-env
  • Activate the virtual environment with source secadv-env/bin/activate
  • Install project requirements with pip install requests
  • Each time you wanna run the security advisories you'll have to activate the virtual environment first

Creating & Publishing Advisories

Checking for Bugzilla tickets

  • Make sure that the security bugs have an updated tracking flag with the correct version number. If the flag doesn't exists for the particular version, you can check in with the #release-coordination people. If you have admin access you can do the change on the admin page.
  • Navigate to the root of the secadv project
  • Activate your virtual environment with source secadv-env/bin/activate
  • Run the python script ./ios_advisories.py [version]
    • Example for v99.0 ./ios_advisories.py 99
    • Example for v99.1 ./ios_advisories.py 99.1

Resolving missing advisory.txt

  • Create this file following the documentation
  • Attach it to the bug

Resolving missing CVEs

  • If needed, ask in #release-coordination for a CVE (Common Vulnerabilities and Exposures) number @dveditz @tritter I need a CVE for https://bugzilla.mozilla.org/show_bug.cgi?id=xxx

Generate Advisory

  • Navigate to the root of the foundation-security-advisories-private project
  • Be sure to pull the latest changes from remote
  • Create virtual environment for this repository as it was done for secadv project
  • Install project requirements with pip install -r requirements.txt
  • Install local dependencies with pip install ./

Create the YML file

  • Find the latest .yml file present in the announcement folder ls announce/YEAR
    • Important note: this process for identifying which MFSA file number to use is currently in flux. Right now we have other teams which will create branches (though not necessarily PRs) which "reserve" MFSA file numbers. Those files will not always be reflected immediately in the private repo's latest master branch.
    • The current advice from Tom for dealing with this potential conflict is:
      • "If it's less than a week before release reach out to me or whoever is on advisory duty to figure out what number to use so you don't step on each other. The day before release there will probably be a branch adv-NNN in the private repo with that release's advisories."
  • Navigate to the root of the secadv project and activate the virtual environment
  • Run the security advisories script with the following command: ./ios_advisories.py [version] > ../foundation-security-advisories-private/announce/2024/mfsa2024-<xx>.yml. This will output the python results inside the yml file.

Hopefully there are no errors. If it has errors and you need help, contact the [sec-team].

Double check the file

  • less ../foundation-security-advisories-private/announce/2024/mfsa2024-<xx>.yml
  • Update the date in the file (labeled with 'FIXME'), or else check_advisories.py will fail. This date needs to be the date of the release. If you don't have the date you can put a placeholder until you have it. When you have the final date you can commit it.
  • Update the MFSA number in the comment at the top of the file to match the number in the file name
  • Confirm it makes sense and adheres to the norms (https://wiki.mozilla.org/Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories#Review_it_yourself)
  • cd ../foundation-security-advisories-private/foundation_security_advisories
  • ./check_advisories.py --all
    • Be sure to avoid special characters in the advisory markup text. The above script should check for any inaccuracies and warn you if the advisory text contains invalid characters.

Add and commit the file

  • Create a new branch for your changes (e.g. <your_initials>/firefox-130)
  • Add the newly-added YAML file, and commit it (e.g. Advisories for Firefox iOS v130)
  • Create a PR with the new file, tagging @tritter and/or @dveditz for review (e.g. Security advisories for Firefox iOS v130)
    • Be sure to target the advXXX branch for the given release version (for example, adv130 for v130).

Publication

Generally for iOS no further action should be needed. Once the private repo PR with the iOS advisories is merged, the release management team will handle the process of publishing the public announcement. If for some reason the advisory was created outside the normal release cycle schedule, you can ping #release-coordination to ask for the advisory to be made public (tag @tritter @dveditz for visibility).

Clone this wiki locally