Instead of integrating with bugzilla, we’ve used the mediawiki framework. The reasons for this many. The biggest reason is to make the “Testzilla” as accessible as possible to as many people as possible. It is also to lower the bar to usability… anyone can look at information on the wiki, but dealing with Testzilla can be trickier (perhaps). Also, Testzilla itself hasn’t been updated in many years, which means a lot of hacking to make it work. Other solutions were either too complicated (Testopia) or didn’t integrate with anything else we currently had (using mediawiki allows us to re-use our authentication from my.mandriva.com).

Anyways, the basic idea is to have a page per package (urpmi, eclipse, evolution, whatever) and on this page will be testcases — descriptions of ways to test programs in that package. Where possible, automated or semi-automated testcases should be written and these get committed to subversion and referenced from the wiki page (the downside here is we need a mechanism to get testcases from people without commit access in, but the upside is it is faster, provides versioning, and won’t bog down the wiki with (hopefully!) numerous testcases).

I’ve already implemented the main page, which can be found at wiki.mandriva.com/en/Testing, and from there you can get to the various testcases (there’s only one on there right now). There is a cookie-cutter template to be used to start new testcases pages, and there are some new macros that make integrating with subversion and bugzilla a little easier/nicer.

All in all, I think this has the potential to do really good things for Mandriva, and probably other distributions as well. With the ability for anyone to create testcase pages, testcases, send an email with an automated testcase attached to our new testcases_@_mandrivalinux_dot_org “exploder” to get committed to subversion, it should be extremely easy and straightforward for people to get involved.

This is something that quite a few people on the cooker list expressed an interest in, so I’m hoping this will nicely take off and become yet another useful resource for the Mandriva community.

The upgrade went quite smooth (due to the preparation and, most importantly, notes taken from the testing almost two months ago), so everything should be up and running in good order. If there are issues, feel free to comment to me directly or file a bug report. I think, however, that users will find the new version of Bugzilla contains some welcome features and I also took the opportunity to change the layout somewhat to make it adhere more to web standards (such as making font resizing easier, etc.). I also condensed the layout somewhat by using the default Bugzilla templates and re-working them from scratch.

I hope everyone likes it. There will probably be more tweaks coming and rc2 is supposed to be coming out fairly soon from what I’ve heard, so there will still be changes forthcoming, although I hope they are more minor than what changed tonight. I’m also hoping this will improve performance somewhat as Bugzilla 3.2 is using InnoDB rather than MyISAM storage types, which from my understanding should also help improve performance.

So far it’s looking pretty good and has some really nice features to it. Due to the heavy changes in the templates, the templates look more stock now than they did before, which actually manages to clean up a lot of the interface and remove duplicate information. I also took the opportunity to style it as best I can to respect user font sizing. The look has changed a little bit along the way as I had to redo all the theming from scratch.

Anyways, for anyone interested in taking a peek at it or playing around with it a bit before it goes live, you can do so at bugzilla.annvix.ca. It’s a snapshot of the Mandriva database from a week ago (more or less), and uses the same authentication, etc. as the Mandriva bugzilla. To prevent confusion, I’ve turned postfix off so mail notifications aren’t being sent.

All-in-all, the upgrade should go fairly smoothly and result in downtime of an hour or two, when it happens. It could probably be implemented now, but I’d rather wait until 2009.0 is released and things have settled down, so consider this a preview until such a time as it does get moved over. Any suggestions or whatever are also welcome.

I was wandering around and found Battle of the Titans: Mandriva 2008 vs OpenSUSE 10.3. Interesting read; I like how Mandriva comes out on top although there are definitely areas we can improve upon. But what else is new? Every distro has areas that can be improved upon.

Anyways, in the comments I’m reading: “the sad part is an unexpected secrecy in Mandriva”, which refers to a bug aliased as CVE-2007-2834, for which the individual didn’t have access to. Of course, he starts a FUD-based tirade on his own blog Planete Beranger. And this is where the fun begins.

At this point, Beranger decides to go on a tirade about hidden bug reports. Good thing Adam is around to smack some sense into him (I’m assuming Beranger is a him, but I don’t really know). He has some nice nuggets like:

Anyway, the sad part is an unexpected secrecy with Mandriva: try a search for http://qa.mandriva.com/show_bug.cgi?id=CVE-2007-2834 and you will get a blunt:
You are not authorized to access bug #33759.

Huh?!

And indeed, the access to http://qa.mandriva.com/show_bug.cgi?id=33759 is denied!

I very much dislike this huge blunder from Mandriva’s part: are they trying to play Microsoft, or what?! Hiding bug reports is unacceptable!

Hmmm… well, if he would have bothered to ask anyone, he would have had his answer fairly quickly as to what the deal with that report is. The contents of this bug report is, exactly:

Description: [reply] Opened: 2007-09-19 17:06 CEST
Private
Name: CVE-2007-2834
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2834
Reference: IDEFENSE:20070917 Multiple Vendor OpenOffice TIFF File Parsing
Multiple Integer Overflow Vulnerabilities
Reference: URL:

http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=593

Reference: CONFIRM: http://www.openoffice.org/security/cves/CVE-2007-2834.html
Reference: DEBIAN:DSA-1375
Reference: URL: http://www.debian.org/security/2007/dsa-1375
Reference: BID:25690
Reference: URL: http://www.securityfocus.com/bid/25690

Integer overflow in the TIFF parser in OpenOffice.org (OOo) before 2.3
allows remote attackers to execute arbitrary code via a TIFF file with
crafted values of unspecified length fields, which triggers allocation
of an incorrect amount of memory, resulting in a heap-based buffer
overflow.

——- Comment #1 From Vincent Danen 2007-09-20 19:07:11 CEST [reply] ——- Private
Fixed.

Pretty spicy stuff, no? In fact, if you looked it up on MITRE’s website, entry CVE-2007-2834 you’ll see the same thing (minus the “Fixed” comment). In fact, you’ll see more.

Oh, and lookee here, you’ll also see this:

MANDRIVA:MDKSA-2007:186
URL:http://www.mandriva.com/security/advisories?name=MDKSA-2007:186

And what happens when you follow that link? Well, you get to see that it was fixed in CS3, 2007.0, and 2007.1. Doesn’t indicate 2008, of course, because it was fixed when 2008 was cooker, thanks to this (public) report: Bugzilla bug #33824.

Now, of course, all of this could have been settled with a simple email. Instead, this Beranger fellow starts spreading FUD, looks like he’s seriously lacking in the investigation skills department, and generally makes a fool of himself.

So, what’s the deal with the private bug report? Well, it’s 1) boring and 2) an internal tracker. Yes, the security team uses bugzilla to track issues we need to deal with. Are these safe for public consumption? Sometimes. Are they interesting to the public? Not really. I think the result is more interesting. For instance, I think that the actual advisory, MDKSA-2007:186, would be far more interesting than a bug report that’s essentially a carbon-copy of the original CVE entry. Now, in this case, perhaps bug #33824 could have had the alias CVE-2007-2834 as it was issued to resolve only one bug.

So, what do we do when an advisory deals with more than one CVE or issue? We can’t give one bug two different aliases. So, let’s look at bug #34610 (libvorbis). If you look at the dependencies, you’ll see bugs #33871 and #33872. Both are private. Both have aliases for the two CVE’s fixed in that advisory. Both use them as aliases. Sure, I could remove the aliases from the CVE-entry-clone-reports, but I can’t assign both to one bug. Or what about the kernel? Or firefox?

My point is, internal tracking bugs have absolutely no relevance to anyone outside of the security team, so no, I don’t see the point in making them public, even after they’re dealt with. It’s nothing more than a glorified TODO list. The advisory itself, and the associated bug report, are important… both of those are public. We’re not trying to hide any details… those details can be found in a dozen places: the public bugzilla advisory report, the official advisory on the website, the security-announce mailing list, the CVE dictionary, NVD, Secunia, Bugtrack (the website and the mailing list), the full-disclosure mailing list… the list goes on.

This fellow should have done a bit more research before starting in on his conspiracy theory. It was both amusing and infuriating… amusing at his ignorance, infuriating that he would start the FUD train without even firing off a simple email saying “wtf guys, this bug is private?!?”. An easy explanation could have been given and the FUD train wouldn’t have left the station.

It’s nice to see both Adam and Fabrice straighten this guy out in comments on his blog, and Fabrice made his own blog post regarding it to.

Fabrice said it quite well: “So next time guys, get your facts ”

I agree with that sentiment whole-heartedly.

Well, he was wrong, it still doesn’t work with Deskzilla. Our bugzilla is pretty hacked up, so it’s not too surprising.. it seems to me that it deviates quite a bit from standard bugzilla. FWIW, Deskzilla works great with the Annvix bugzilla.

PyBugz, on the other hand, seems to be a great query tool for our bugzilla. It seems to be quite Gentoo-centric (which is ok), so it doesn’t work to post a new bug to bugzilla. It does work to submit a comment to bugzilla, however, and authentication works, which is great. The problem is, as I just discovered, if you submit a comment to a private bug (our “group” feature… I have no idea if this is from bugzilla or something we added, but you can have bugs appear only to certain groups; we use it for hiding security-related issues), it unsets the group flag (effectively making a security-related bug from being private to public). Note to self… do not use PyBugz to post comments to our bugzilla.

But for a query tool it works like a hot damn:

vdanen@odin:~/ >% bugz --base 'http://qa.mandriva.com' search \
--assigned-to warly@mandriva.com
 * Using http://qa.mandriva.com
 * Searching for bugs with the following options:
 *    assigned_to          = warly@mandriva.com
   5856 warly                Services logs are duplicated (ex: LDAP)
   6638 warly                bugzilla asks to login too many times
   7429 warly                MIssing hd.img in 10.0 beta1/beta2/RC1 ISO
...

(the list is pretty long so I’ve truncated it, wc tells me there’s 177 bugs there).

Anyways, I thought I’d mention how slick this thing is… I’m pretty impressed by it. Seems to be a lot faster than trying to use the web interface directly and could also be scriptable to create reports of how good (or bad) people are doing with their bugs (not to mention possibly creating customized daily TODO lists)… the possibilities are pretty limitless.

Oh, for anyone wanting to use this on OS X, you should download the latest python from pythonmac, which is 2.4.3 (fink only has 2.4.2, and OS X 10.4 comes with 2.3.5). You’ll also want to grab the current svn version of PyBugz (it doesn’t work very well with the 0.6 tarball release on the site), and you’ll also need to download ElementTree, which PyBugz requires (very easy to install python module). Install the updated Python first however and make sure the PATH is setup and such appropriatly before installing ElementTree or it could get installed in the wrong place. Once you do that, it’ll work peachy on OS X.