Developer Area/Security Team: Difference between revisions
From Mahara Wiki
< Developer Area
No edit summary |
m (remove useless html tags) |
||
| Line 1: | Line 1: | ||
Here is a description of the rules and procedures that the [https://launchpad.net/~mahara-security/+members security team] follows. | Here is a description of the rules and procedures that the [https://launchpad.net/~mahara-security/+members security team] follows. | ||
===Guiding principles=== | ===Guiding principles=== | ||
| Line 11: | Line 9: | ||
# We release security fixes as soon as possible, balancing the urgency/severity of a problem as well as the frequency of updates for site admins. Therefore we may "sit" on non-critical and non-public issues for a short time in order to include them as part of a larger security update. | # We release security fixes as soon as possible, balancing the urgency/severity of a problem as well as the frequency of updates for site admins. Therefore we may "sit" on non-critical and non-public issues for a short time in order to include them as part of a larger security update. | ||
# If the details of a security issue are made public before a fix is released, we can unhide the relevant bugs but we must release a fix as soon as possible (i.e. we cannot sit on those ones). | # If the details of a security issue are made public before a fix is released, we can unhide the relevant bugs but we must release a fix as soon as possible (i.e. we cannot sit on those ones). | ||
===Procedures=== | ===Procedures=== | ||
| Line 31: | Line 27: | ||
# Once everything is ready, we run through the [[Developer Area/Release Instructions|release process]]. This starts with the fixes being submitted through gerrit (marked as "verified +1" "code review +2" by the submitter) and ends with official announcements. | # Once everything is ready, we run through the [[Developer Area/Release Instructions|release process]]. This starts with the fixes being submitted through gerrit (marked as "verified +1" "code review +2" by the submitter) and ends with official announcements. | ||
# The Debian unstable package is uploaded and debdiffs for Ubuntu packages are posted on Launchpad. | # The Debian unstable package is uploaded and debdiffs for Ubuntu packages are posted on Launchpad. | ||
Revision as of 17:34, 7 October 2011
Here is a description of the rules and procedures that the security team follows.
Guiding principles
- Above all else, we need to protect Mahara users to the best of our ability.
- We keep security vulnerabilities secret until a fix is released.
- Before fixes are released, we only share details of security flaws with people involved in releasing fixes.
- Once fixes are public, we release details of the flaws (i.e. full disclosure) but we do not provide exploit code which makes it easy to exploit unpatched sites.
- We release security fixes as soon as possible, balancing the urgency/severity of a problem as well as the frequency of updates for site admins. Therefore we may "sit" on non-critical and non-public issues for a short time in order to include them as part of a larger security update.
- If the details of a security issue are made public before a fix is released, we can unhide the relevant bugs but we must release a fix as soon as possible (i.e. we cannot sit on those ones).
Procedures
Here's roughly what we do when we receive notice of an unpublished security flaw:
- We review/test the report to confirm that it is a problem and create a private security bug on Launchpad.
- We acknowledge receipt of the problem to the reporter and ask them to keep it quiet while we release a fix for it (we also ask how they want to be credited with the discovery of this problem).
- We fix the problem on:
- the supported stable releases (i.e. the last two)
- the versions of the mahara package in Debian and Ubuntu
- master
- The fixes are not reviewed through gerrit or committed to the bug tracker. Instead, they are attached as patches to the private bugs on Launchpad.
- The fixes are reviewed by another developer manually.
- We request CVE numbers for each separate issue from [email protected]
- Mahara advisories (for the security forum) are prepared.
- We prepare, test and update Debian packages for oldstable and stable and submit them to the embargoed security queue.
- Once everything is ready, we run through the release process. This starts with the fixes being submitted through gerrit (marked as "verified +1" "code review +2" by the submitter) and ends with official announcements.
- The Debian unstable package is uploaded and debdiffs for Ubuntu packages are posted on Launchpad.