Bug#413926: wordpress: Should not ship with Etch
Sorry to be a queue-jumper, but I'd like to see the TC address this wordpress question quickly so that the release team doesn't have to make a decision by default for etch while the TC is deliberating (or sleeping, as the case may be :-). In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413926;msg=99, Neil McGovern seems to make a good point that wordpress's security track record is comparable to that of other web apps in the same category, such as phpmyadmin, moodle, phpbb2, and bugzilla. However, on closer examination, the source data that Neil used here (svn://svn.debian.org/svn/secure-testing/data/CVE/list) covers *all* historical CVEs dating back to 1999. This means that, while the history for phpbb2 and bugzilla includes CVE entries dating back to 2002, and the history for phpmyadmin stretches back to 2001, the earliest CVE for wordpress, a comparatively young piece of software, is CVE-2004-1559. Viewed this way, wordpress definitely appears to have one of the /highest/ rates of security holes for webapps of its class. If the security team believes this is likely to remain the case, then it seems perfectly reasonable to me that they would not want the package to be included in a stable release. FWIW, I also took a look at some popcon numbers for these webapps, and here's what I found for number of reported installs: phpmyadmin: 3504 wordpress: 245 phpbb2: 197 bugzilla: 148 So that makes wordpress somewhat middle-of-the-road by this metric. But of course, almost all of the packages with higher CVE counts, in addition to having longer histories, also have much longer install bases -- packages like the kernel, the web browsers, apache2, ethereal, and php4. I would conclude here that there's insufficient grounds for overriding the security team's decision. Does anyone disagree or think more information is needed, or should I propose a vote? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#413926: wordpress: Should not ship with Etch
* Anthony Towns: Viewed this way, wordpress definitely appears to have one of the /highest/ rates of security holes for webapps of its class. 14 bugs per year versus 12 for moodle and phpbb2 doesn't seem that big a difference to me. I'm not sure that bug counts like this are really useful though -- they don't measure the severity of the problems, and could be indicative of popular code that's being regularly fixed as much as low quality code that's being regularly broken. Unfortuantely, our severity ratings aren't very good (this covers only bugs from 2005 onwards): moodle|low|5 moodle|medium|4 moodle|unimportant|5 moodle|unknown|9 phpbb2|high|1 phpbb2|low|4 phpbb2|medium|5 phpbb2|unimportant|16 phpbb2|unknown|15 wordpress|high|1 wordpress|low|5 wordpress|medium|7 wordpress|unimportant|11 wordpress|unknown|15 Apart from that, I'm not sure how much meaning we should attach to these numbers, even if we had a higher number of vulnerabilities and more rigorous analysis of each one. (For instance, #363580 is apparently not included in the counts above.) From a software quality point of view, wordpress shares many of the design flaws typically found in PHP applications. For instance, it does not use prepared statements, and consequently does not separate SQL statements and their parameters in a way that can be audited in a straightforward manner: wp-includes/registration.php: return $wpdb-get_var(SELECT ID FROM $wpdb-users WHERE user_email = '$email'); The function that guards $email against malicious characters is contained in the file wp-includes/formatting.php, without any hint that it is security-relevant. In another case, it's less clear if it's impossible to inject SQL via the configuration option start_of_week. wp-includes/general-template.php: $arcresults = $wpdb-get_results(SELECT DISTINCT WEEK(post_date, $start_of_week) AS `week`, YEAR(post_date) AS yr, DATE_FORMAT(post_date, '%Y-%m-%d') AS mmdd, count(ID) as posts FROM $wpdb-posts WHERE post_type = 'post' AND post_status = 'publish' GROUP BY WEEK(post_date, $start_of_week), YEAR(post_date) ORDER BY post_date DESC . $limit); AFAICS, that option is not properly sanitized when it is being set. Wordpress includes a private copy of ezSQL (LGPLed, according to an extremly brief statement by upstream), without proper attribution in the debian/copyright file. But all that can be considered best current practice, so to speak, and should not necessarily be a reason to exclude a package from a stable release. There might be non-technical concerns regarding the promises of security support or the maintenance status in Debian, but I'm not qualified to judge that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413926: wordpress: Should not ship with Etch
On Tue, Mar 13, 2007 at 01:46:45AM +1000, Anthony Towns wrote: Dividing by years gives: CVEs Earliest Years CVEs/Year 43 2004 3 14.3 wordpress 63 2002 5 12.6 phpbb2 37 2004 3 12.3 moodle 46 2002 5 9.2 bugzilla 45 2001 6 7.5 phpmyadmin Viewed this way, wordpress definitely appears to have one of the /highest/ rates of security holes for webapps of its class. 14 bugs per year versus 12 for moodle and phpbb2 doesn't seem that big a difference to me. Sure. I'm not arguing that I would have made the same decision as the security team in their place, I just think that there's insufficient evidence to support overriding their decision. I'm not sure that bug counts like this are really useful though -- they don't measure the severity of the problems, and could be indicative of popular code that's being regularly fixed as much as low quality code that's being regularly broken. Indeed, standing alone a bug count can equally suggest a thorough audit or a terribly buggy piece of software. As the folks doing the backports of security fixes for wordpress, aren't the security team best positioned to know which applies here? FWIW, I also took a look at some popcon numbers for these webapps, and here's what I found for number of reported installs: phpmyadmin: 3504 wordpress: 245 phpbb2: 197 bugzilla: 148 Of those packages, wordpress was the only one not released with sarge, so I don't think the numbers are readily comparable. Fair enough. We seem to have a statement of support from upstream, and an endorsement from Neil that it's been supportable as far as testing-security was concerned, as well as from Martin Zobel-Helas who's one of the stable release managers, so I can't see the need to decline to release it. I give a lot of weight to concerns expressed by the security team. Granted, they don't get to pick their bugs, and it would be unreasonable for the security team to throw out, say, all packages that had ever had security bugs, or to decline to support all packages of Priority optional or lower due to lack of manpower; but I think the difference between this package is bound to have security issues because it's large and addresses a difficult problem space, and this package is bound to have security issues because its very poorly designed or has atypically low standards for acceptance of contributions is relevant. It's my impression that the security team's objections to wordpress stem from a belief that it lies in the latter category. I'd consider it the maintainer's and RMs' call though. Ok, does that mean you agree the TC should not override any decisions here? Hmm -- if it's the RMs' call, I guess that means Andi and I both are required to abstain from any vote on this (Constitution 6.3.2). Is it still ok for me to call for a vote? :) (FWIW, as RM the decision I consider to have made is defer to the judgement of the security team, so I guess the TC does have a choice on who to overrule...) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
