I got an email this morning from the maintainer of Testopia to inform me that Testopia 2.5 is finally released! This is the first version to work with Bugzilla 4.2.1 (if you are still running Bugzilla 4.0.x or 4.2, upgrade to 4.2.1 first). The announcement has not be made official yet, but this should be done in the coming hours, hopefully. Meanwhile, you can already download Testopia 2.5. Note that there is no need to apply any patch anymore to make it work (which is why you need Bugzilla 4.2.1 instead of e.g. 4.2, because 4.2.1 has some changes included in it to avoid to patch the core code to make Testopia work). And if you find any problem which hasn’t been reported yet, feel free to file a new bug (bugs only, no support questions). Have fun!
UPDATE: The announcement has finally been made here.
May 30, 2012 01:05 PM
During the week-end, I received a pertinent email from a former Bugzilla developer who replied to an email I sent to all reviewers about the pretty low activity in the Bugzilla project during the current development cycle. He argued that one of the reasons which made him go away, and which probably took some other contributors away as well, is our high code quality standards we have in this project. The point is that we deny review if submitted patches do not follow our guidelines or are poorly written compared to what we expect in our codebase. He suggested that reviewers should accept and commit lower quality patches, and file follow-up bugs to clean up the new code. I then brought this discussion on IRC with other core developers, and we realized how hard it is to define the right level of code quality. The problems are:
So what’s the right threshold to not make new and occasional contributors go away without badly impacting our codebase? Which rules do other Mozilla and non-Mozilla projects use to solve this problem? Please share your experience with us.
May 15, 2012 05:56 PM
We released Bugzilla 4.3.1, 4.2.1, 4.0.6 and 3.6.9 a few hours ago, and they all contain 2 security fixes. All installations are highly encouraged to upgrade to these new releases. Bugzilla 3.6.9 and 4.0.6 only contain the two security fixes mentioned in the security advisory. Bugzilla 4.2.1 also contains a pretty large list of bug fixes, which makes it a good candidate to upgrade to the 4.2.x series if you didn’t upgrade to 4.2 yet. Note that Bugzilla 4.2.1 is also the first release to work with Testopia without needing to be patched first. A new release of Testopia should be available soon, which will take advantage of the improvements and new hooks available in 4.2.1.
We also released Bugzilla 4.3.1 which is the first development snapshot of the 4.4 series. I’m going to list some of the new features and improvements available:
We are one month away from the freezing date for new features in Bugzilla 4.4. So if some of you really want something for 4.4, you have exactly one month left to submit patches, or find a kind developer to write the patch for you. Also note that Bugzilla 4.4 will be the last release to support Perl 5.8.x. The next major release, Bugzilla 4.6, will require Perl 5.10.1 or better.
April 19, 2012 01:10 AM
You probably noticed that there has been no activity related to the development of Testopia, a Bugzilla extension, for more than a year. The reason is that its maintainer, who was the single contributor to this project, had a new job and has no time to work on it anymore. Consequently, the latest version of this extension, Testopia 2.4, which was released in October 2010 (!), only works with Bugzilla 3.6, but not 4.x.
You will be happy to hear that with the help of some new contributors wanting to make Testopia work with Bugzilla 4.2, I committed several patches to the bzr repository which make it work pretty decently with Bugzilla 4.2.1 (probably also with Bugzilla 4.0.x, but I didn’t test). There is no official release yet (it should be named Testopia 2.5), but you can download updated files using bzr. Make sure to revert changes made to the core code of Bugzilla first before applying the new code.
To make things clear: I’m not the new maintainer of this extension, and I have no plan to take this role. I’m busy enough with my role as assistant project lead + reviewer + QA lead + bug triager + patch writer for the Bugzilla project. I simply decided to help the new contributors who jumped in these last few days and used my commit access to the Testopia repository to commit some patches. The Testopia maintainer is still alive, and emailed me this morning. So he is still the one who will take the decision to release 2.5 when it’s ready.
Update: Starting with Bugzilla 4.2.1, you no longer need to patch the source code of Bugzilla to make it work with Testopia 2.5! If you are upgrading from Testopia 2.4 or older, make sure to revert the changes made to the source code first.
April 09, 2012 05:58 PM
This is just a quick note to let you know that once we branch for Bugzilla 4.4 in May, I will commit a patch which will make Bugzilla 4.5 and newer to require Perl 5.10.1 as a minimum. This means Bugzilla won’t support Perl 5.8.x anymore. So Bugzilla 4.4 will be the last release to support the oldish Perl 5.8.x. This new requirement is tracked in bug 655477.
March 29, 2012 09:24 PM
There has been some complains these last few days on IRC and in the support mailing-list/newsgroup that admins couldn’t upgrade their Bugzilla installation to 4.2 due to the lack of a CVS mirror for this branch. As announced 3 years ago in the developers mailing-list and on b.m.o., and 1.5 years ago on the bugzilla.org website, the Bugzilla team switched from the old CVS to the more modern Bazaar (or bzr for short) VCS. If you use our tarballs to download Bugzilla, then you don’t really care about this change, and the process to upgrade won’t change for you. If you use CVS and you wonder how to upgrade using Bzr, here is how you can do it:
March 02, 2012 03:04 PM
Now that Bugzilla 4.2 is released, I could finally focus on enhancements instead of fixing blockers and doing QA. This week, I decided to spend some time to improve the performance of Bugzilla. My main focus was show_bug.cgi, i.e. bug reports. I plan to look at other CGI scripts soon, hopefully within 2 weeks.
You will be happy to hear that in the last 3 days, I managed to divide the time spent to load large bug reports such as bmo bug 38862 (235 comments, 32 attachments and 55 CC’ed users) or bmo bug 18574 (760 comments, 63 attachments and 170 CC’ed users!!) by a factor of 2 when using mod_cgi (-50%), and by 30% with mod_perl. The exact load time in seconds depends on the bugs being viewed and on your hardware, but these percentages seem pretty consistent with the different tests done this week. All my patches have been checked in upstream (see rev. 8133 – 8142), and Bugzilla 4.3.1 will be the first release to benefit from them all. Two of them have been backported to 4.2.1 as they are well contained and fix obvious problems, and the other ones are either too invasive for a stable branch or have unclear benefits (the perf win varies between a few 1/1oth of second to 2-3 seconds depending on the test installation).
Now talking about bmo specifically, I gave a look at the InlineHistory extension for the first time, and I proposed a patch which highly decreases the load time of bug reports. dkl did some testing for me with and without mod_perl, and he found these results:
for bug 38862: 5.18 s (unpatched) -> 3.01 s (patched)
for bug 18574 + mod_cgi: 8.01 s (unpatched) -> 4.57 s (patched)
for bug 18574 + mod_perl: 5.76 s (unpatched) -> 4.06 s (patched)
Now I hope the same gain will be visible once these patches are applied to bmo, but the hardware + software configurations of bmo are so different from our test environments that it’s hard to say for sure till the changes are committed and pushed to production. Fingers crossed!
March 02, 2012 12:49 AM
We released Bugzilla 4.2 today, exactly one year after our previous major release, 4.0! Bugzilla 4.2 now supports SQLite, lets you create attachments simply by pasting text into a text field, can send bug changes notifications in HTML format, supports more complex queries, lets you disable old target milestones, versions and components (so that you don’t need to delete them, but also don’t let users report new bugs to them), has accessibility improvements, and much more…
This release also means that Bugzilla 3.4.x is no longer supported. Installations still running 3.4.14 or older are highly encouraged to upgrade to 4.2, especially to benefit from the security improvements made in newer versions. This also means that Bugzilla 4.0.x will now only get security fixes, and other bug fixes won’t be accepted on this branch anymore, unless they fix critical flaws, such as upgrade issues or dataloss.
The Bugzilla team will now focus on the next major release, Bugzilla 4.4, which we expect to release before the end of the year. We expect to release the first development snapshot (4.3.1) in a few weeks. New features will be accepted for the next two months, till the end of April. Then we will focus on stabilization to prepare Bugzilla 4.4rc1.
If you are interested in helping with the development of Bugzilla, now is a good time to join the team and contribute with new features and/or bug fixes. Due to other activities and because life can sometimes make you very busy, some core developers had to stop their contributions to the Bugzilla project in the last few months and so we would be very happy to see new faces. Bugzilla needs to be faster, nicer, more user friendly, and all this is only possible with your help, your ideas and your feedback. So even if you aren’t a Perl expert, there is a lot of place for everyone (you can do a lot with HTML + JS + CSS only, think about the User Interface!). If you are not sure about how to contribute or help, feel free to join us on IRC in the #bugzilla channel. There is always someone around to answer your questions.
February 22, 2012 11:50 PM
We released Bugzilla 4.2rc2, 4.0.4, 3.6.8 and 3.4.14 a few minutes ago. They all contain various security fixes which are described in the Security Advisory. 4.2rc2 should be our last release candidate before 4.2 final, which we expect to release in the 2nd half of February. On the other end, 3.4.14 is very likely our last release for the 3.4 branch. Once 4.2 final is released, we won’t support 3.4 any longer. This means that admins still running 3.4.x or older are highly encouraged to upgrade. Users should pester their admins to upgrade if they don’t do it themselves.
Now is a good time to explain (again) why upgrading is not only about getting new features and bug fixes, but also to keep your installation secure. Below are some security fixes and/or enhancements made to various releases:
Since Bugzilla 4.4, the X-XSS-Protection header is used to block simple XSS attacks.
Till recently, no token check was done before accepting new bug submissions or before uploading an attachment to an existing bug. The rationale behind this was that in older versions of Bugzilla there was no easy way to do it from the WebServices API, and we didn’t want to break existing 3rd-party tools which were legitimately interacting with Bugzilla. As the lack of token validation could be used by attackers to submit unwanted new bugs or attachments, it has been decided that a token was required in these cases too, and not only when updating a bug or an attachment. But to not break 3rd-party tools, these token checks have been implemented in Bugzilla 4.2 only, meaning that Bugzilla 4.0 and older are still vulnerable to these attacks. If you want your installation to be protected against this kind of vulnerabilities, upgrade to 4.2!
Bugzilla 4.2 has a new parameter which lets admins decide how complex a password must be to be accepted by Bugzilla. Up to 4.0, Bugzilla accepted all passwords which were long enough (min 6 characters by default). Now you can enforce the complexity: uppercase + lowercase characters, letters + numbers, etc… If you want this feature, upgrade to 4.2!
As Bugzilla accepts all attachments independently of their MIME type, it was possible to attach HTML files which could try to abuse users using a method known as clickjacking. To prevent this, the “Details” page of attachments now display the source code of these HTML files instead of rendering them. This security enhancement has been implemented in Bugzilla 4.0.4 and newer (including 4.2). If you want it, upgrade!
Since Bugzilla 4.0, the X-Frame-Options: SAMEORIGIN header is sent for all pages (besides attachments when delivered from their alternate host). This prevents to load a Bugzilla page from within a frame outside Bugzilla itself. This, combined with the clickjacking protection above, prevents an attacker to create an HTML page with malicious code in it to force a user to make undesired changes to Bugzilla. If you want this, upgrade!
Since Bugzilla 4.0, a new parameter lets admins enable the Strict-Transport-Security header to force the communication between Bugzilla and the user to be made over SSL only. This prevents data to be sent unencrypted.
To prevent Internet Explorer 8 and newer from sniffing the content of attachments, Bugzilla 4.0 and newer now pass the X-Content-Type-Options: nosniff header to avoid some malicious attachments to be rendered as HTML files.
Since Bugzilla 3.6, if you try to guess someone else’s password and you fail 5 consecutive times, your IP is blocked for the next 30 minutes. If you still run Bugzilla 3.4 or older, Bugzilla will accept all your attempts to crack the victim’s password, severely increasing the risk that the attacker manages to do it.
Those of you who are still running very old versions of Bugzilla (older than 3.2) don’t have their login cookies protected against JavaScript as they don’t have the HttpOnly attribute set. This means a malicious HTML page could steal your login cookies very easily and they could then be used to impersonate your user account. These same cookies also do not have the Secure attribute set which prevents them to be transmitted on unsecure connections. And last but not least, tokens used by Bugzilla 3.2.9 and older are not generated using a cryptographically secure pseudorandom number generator. This means that with some effort, your installation could be abused by an attacker who managed to guess how tokens are generated in your installation.
Now I think you know enough about security features implemented in Bugzilla to decide what you want to do. If security matters to you, you should upgrade to at least Bugzilla 4.0.4, and seriously plan to upgrade to 4.2 once it’s released later this month.