Developer Area/Security Team

Here is a description of the rules and procedures that the security team follows.

Guiding principles

1. Above all else, we need to protect Mahara users to the best of our ability.
2. We keep security vulnerabilities secret until a fix is released.
3. Before fixes are released, we only share details of security flaws with people involved in releasing fixes.
4. 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.
5. 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.
6. 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:

1. We review/test the report to confirm that it is a problem and create a private security bug on Launchpad.
2. 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).
3. We fix the problem on:
   1. the supported stable releases (i.e. the last two)
   2. the versions of the mahara package in Debian and Ubuntu
   3. master
4. 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.
5. The fixes are reviewed by another developer manually.
6. We request CVE numbers for each separate issue from [email protected] (see this email template)
7. Mahara advisories (for the security forum) are prepared.
8. We prepare, test and update Debian packages for oldstable and stable and submit them to the embargoed security queue.
9. 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.
10. The Debian unstable package is uploaded and debdiffs for Ubuntu packages are posted on Launchpad.

Fixing security bugs the right way

When preparing a fix for a security bug, we need to ask three questions:

1. How can I fix this bug?
2. Where else could the same problem pop up?
3. What could we do in Mahara to prevent bugs like this one to ever happen again?

Here's an example of the thought process for a cross-site scripting bug that someone reported:

1. I can fix this bug by escaping the string.
2. It could happen anywhere else in templates. So I need to check every Dwoo template.
3. We could prevent this from happening by turning template auto-escaping ON.

In other words, we are fixing the problem in two ways and we are making sure that we fix all instances of this problem at once.