Introduction
The SecurityTeam processes bugs based on its workflows, and in general, most of the standard HowToTriage processes apply to triaging security bugs. Below are various items related to processing security bugs.
Reporting
Please see How to File.
Triaging
Status
The status of a security bug is based on the following:
New: a new bug in need of triage.
Incomplete: more information is needed from the reporter.
Confirmed: the bug is a security vulnerability. Bugs in the confirmed state should usually have a CVE link in the bug.
Triaged: the vulnerability is understood, and a patch is needed. Bugs in the triaged state will most often have an upstream bug reference.
In Progress: a pending patch is attached to the bug report. A patch that requires more work will be downgraded to Triaged and should be marked back to In Progress after the contributor has resubmitted the patch. See SecurityTeam/UpdateProcedures for more information on submitting patches.
Fix Committed: the fix is in the Ubuntu Security PPA or in a proposed repository, pending publication.
Fix Released: the fix has been published to the security repository. Packages in main will also have a corresponding USN. Including the Launchpad bug reference (eg LP: #123456) in the source changelog file will automatically mark a bug as Fix Released for all Ubuntu 6.10 (Edgy) and later when the package is uploaded. Ubuntu 6.06 LTS (Dapper) and earlier will need to have the status changed manually. For the development release, mark the bug as 'Fix Released' when someone from the Ubuntu community has actively fixed the vulnerability via patching or requesting a sync.
Invalid: the vulnerability does not affect this release.
Priority
Please see the ubuntu-cve-tracker README file (Ubuntu Priorities section) for details on what priority to set a bug. If unsure, leave as Undecided.
Releases
Usually, a security vulnerability affects multiple Ubuntu releases. When triaging, each affected release should be tracked individually by using the 'Nominate for release' link from within the bug. Please only nominate those releases that are affected.
If the security vulnerability only applies to the development release, you do not need to use 'Nominate for release'.
Stock Replies
For a number of situations, we have stock reply scripts that can used from the lp:ubuntu-qa-tools git tree, in the responses/security/ subdirectory.
Not Security
Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find. |
Existing Bugs
- Confirmed security bugs
Private Bugs
Generally, new security vulnerabilities should be filed with the upstream authors of the software first, and a bug reported to Ubuntu with an upstream bug reference or comments. When private security bugs are filed with Ubuntu first, the SecurityTeam will follow established responsible disclosure processes and may alert the upstream authors and other vendors via the distros@vs.openwall.org mailing list to decide upon a coordinated release date (CRD). The bug will be marked public after the specified CRD. If the upstream authors and vendors do not request a CRD, then the bug will be made public after 7 days.