We have a policy in Moodle that, at the moment, all bug fixes go into 2.6 and 2.5 branches, and only security fixes go into Moodle 2.4. This means we need to know what is a security bug. At the moment, we seem to be implicit using the definition "a bug that an evil hacker could exploit", however, I am not sure that I agree.
I actually have a text-book definition of what IT security is, thanks to the OU course M886 Information Security Management.
Security is ensuring (as far as possible) the
-
- confidentiality,
- integrity and
- availability
of information (that is important to your users).
The next stage in the analysis is to look a threats (things that might compromise one of those things) and vulnerabilities (the weaknesses in your system (and that is the whole system, software + hardware + users) that might be a way that one of the threats can actually damage confidentiality, integrity or availability.
OK, enough theory for now. Just note that a threat does not have to be some sort of evil hacker. It could be something like a power cut or hard disc failure, and the corresponding vulnerabilities would be not having a failover server, or a backup.
So anyway, the suggestion I want to make is that our current definition "bug someone could exploit" is not quite right. For example, issues like
- An issue where some data is not written to the backup file correctly (e.g. MDL-44018), or
- where some incorrect SQL can corrupt other data, as well as the DB update it is supposed to do (e.g. MDL-34451)
are security bugs, and should be fixed in 2.4 too.
This then leads to a second point. At the moment, another part of the security policy is that all security bugs get held for integration until just before the next stable release. This is where the issue of "bug someone could exploit" is important. If a bug is exploitable, then delaying integration is correct. If, however, the bug is a security issue, but not exploitable by a malicious hacker, then we should be integrating it as soon as possible.
So, in summary: we still need to track which bugs are exploitable, and handle the patches appropriately, but that does not mean that only exploitable bugs should have the fix back-ported to 2.4.