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]
