Security Team Work Flow

Assisting with Vulnerability Patching

This is the work flow for helping fix security bugs in Fedora and EPEL.

1. Select an open security bug from -> Open issues.
2. Own the bug.
3. Examine the bug details and validate if it is really a security issue.
4. Determine if a fix is available and if the vulnerability is already fixed in Fedora by examining the current version and/or talking with the package maintainer.
5. If a fix is not available, work with the upstream developers via bug tracking/mailing list/IRC channels to obtain a patch or new version which fixes the issue.
6. Work with the package maintainer to get patch or fixed version packaged and pushed as a security update.
7. GOTO 1;

If you run into a nonresponsive package maintainer we follow Release Engineering policy to overcome these issues.

Bug Ownership

Each tracking bug should have an owner for several reasons. It would certainly be inefficient if the work was done twice. Collisions and misunderstandings might occur if two people tried to coordinate a fix with an upstream developer independently. For these reasons, we should indicate the fact that we are working on the tracking bug by filling the Whiteboard of the bug with Bugzilla user name of the owner:

   Whiteboard: fst_owner=<owner>,[<owner2>,<owner3>]

As <owner> FAS ID should be used; It simplifies further management. For the list of Bugzilla user names of the Fedora Security Team see the Security Team Roster.

Note: For multiple FST owners FAS IDs should be comma-separated and NOT contain spaces.

Bugzilla Links

• Open issues
  • Critical Vulnerabilities Unowned
  • Important Vulnerabilities Unowned
  • Moderate Vulnerabilities Unowned
  • Low Vulnerabilities Unowned
  • Unknown Vulnerabilities Unowned
  • Bugs in MODIFIED, ON_DEV, ON_QA states Unowned

Working with newly reported vulnerabilities

TBD

Code Review

TBD