It's been a relatively long standing policy of the project to not generate security advisories for low risk denial of service attacks. I've seen several rationales used over the time for these. Most notably:
* You need commit access to the repository. * There are easier ways to DoS Subversion. I think we should produce advisories for all vulnerabilities in Subversion. Subversion is used in a variety of configurations and is almost certainly being used in ways we can not predict. These configurations make it unreasonable for us to be able to access the risk that a vulnerability poses to a given installation. We shouldn't support just the majority of our users but rather should support all of our users. We support fully anonymous commits, even though most of users do not use this functionality. If we are going to support a method of operation, part of supporting that means producing security advisories to the risks of using that method of operation.. Part of the logic surrounding this policy has been the idea that we do not want to alarm users by security advisories that do not generally apply to them. I think some things have changed over the last 10 years since we started this policy. Security vulnerability advisories are no longer rare or uncommon, I see one virtually every day, many of which do not apply to me and my configuration. The security community has gotten better at communicating risk too. There are now systems like CVSSv2[1] that can be used to communicate the level of risk to the majority of the users. Users have become more aware that the number of advisories does not translate into actual risk. The argument that there are easier ways to DoS Subversion is rooted in the idea that commit access translates into some degree of use of resources on the server. E.G. If I can commit enough data to the repository then the repository will run out of disk space and this will deny the ability to commit to other users. These sorts of risks are inherent in operating a Subversion server and should be obvious to most administrators. We should not avoid pointing out vulnerabilities simply because we have inherent risks. If there are flaws that shouldn't be inherent but are easier to exercise than the flaw we are considering, then we should endeavor to fix those flaws as well rather than avoiding advising our users of the vulnerability we have solved. Nearly 3 years ago cmpilato and other developers stated that our vision as a project was to be "Enterprise-class centralized version control for the masses." [2] It is my view that part of being enterprise-class is providing advisories for all your vulnerabilities. I believe a new approach is called for from the project regarding security advisories. 1) Begin producing advisories for all vulnerabilities, even low risk denial of service attacks that in most configurations require commit access. 2) Begin calculating the base CVSSv2 score and vector and including them in our advisories. CVSSv2 is designed around considering the most common configurations, which means our scores would be based around the assumption that commit access requires authentication. 3) Release low risk and low impact vulnerabilities as part of normal releases. High risk and/or high impact vulnerabilities can still be handled via emergency releases. 4) Educate our users on these changes and on how to understand the risks. Our advisories already do a good job of communicating risk. I really don't think our users will be alarmed by this, especially if we make some effort to explain the change to them and educate them. [1] http://www.first.org/cvss/cvss-guide.html [2] http://svn.haxx.se/dev/archive-2010-04/0047.shtml
