CA/Bug Triage
Bug Triage in Mozilla's CA Certificate Program
Mozilla’s CA Certificate Program governs inclusion of root certificates in Network Security Services (NSS), a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of products.
The Bugzilla product/component for the CA Certificates Program is mozilla.org :: CA Certificates.
The CA Certificate Program deviates from Mozilla's standardized Bugzilla Bug Triage process by not using bug priorities (P1, P2, P3, or P5), because CA Certificate bugs do not directly include code changes to Mozilla's release trains or iterations.
CA Certificate bugs are used to:
- Track root inclusion/change requests. When approved, the actual code changes are requested via a new Bugzilla Bug for NSS.
- Track EV treatment enablement requests. When approved, the actual code changes are requested via a new Bugzilla Bug for PSM.
- Concerns that are raised about certificates being issued by CAs, and the resulting action items for the CAs.
- CA Program related concerns or action items. If it is determined that a code changes is needed, then a separate Bugzilla Bug will be created to request the code change.
In short, every new bug should either be prioritized as moved to a different component, or needinfo should be requested from someone. P1 means the bug should be fixed before the current Nightly branches to Aurora (and even uplifted as appropriate). P2 means the bug will be worked on "next" (basically, after P1s are taken care of). P3 means the bug is in the "should be fixed" backlog. Tracking or meta bugs are also P3. P5 is for bugs where patches would be reviewed and taken from contributors if appropriate, but otherwise won't be worked on. If a bug has had an unanswered needinfo flag for more than 2 weeks, it should be reevaluated (closing as incomplete, needinfo-ing another person, etc.).
After branching, bug priorities should be revisited. If a P1 is still open, it either needs to be deprioritized (maybe it isn't really a P1) or whatever is blocking its completion needs to be identified and dealt with. P2s and P3s should be considered for promotion to a higher priority. Assignees should be found for any bugs promoted to P1.
This is the list of untriaged bugs according to the new process.
This is the list of bugs waiting on needinfo for more than 2 weeks according to the new process.
Internally, PSM makes use of a number of whiteboard tags for organizational and prioritization purposes. They are as follows:
- [psm-assigned] are bugs that currently have an assignee. These should all be P1.
- [psm-backlog] consists of the backlog of bugs we should fix in PSM. These should all be P2 or P3. If they are P1, they should have an assignee and the tag should be [psm-assigned].
- [psm-cleanup] consists of code maintenance bugs that would make development easier, but don't directly impact functionality. These are probably mostly P3 or P5.
- [psm-tracking] are meta bugs that track larger work. These should all be P3.
- [psm-deprecation] are bugs that involve deprecating weak cryptography
- [psm-clientauth] consists of bugs involved with TLS client authentication
- [psm-smartcard] are bugs involving PKCS#11 devices
- [psm-documentation] are bugs on writing or improving PSM documentation
- [psm-waiting] are bugs that are waiting on some external input
- [psm-blocked] are bugs that are blocked on other work
- [psm-intermittent] are bugs filed for intermittently failing tests in PSM
- [psm-would-take] are bugs where we would review patches from contributors, but otherwise we won't be working on them. These should be P5.
These are the remaining untriaged bugs with respect to internal bug management.