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! :)
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. :)
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.
CSRF vulnerabilities in attachment.cgi and post_bug.cgi
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!
Configurable password complexity for user accounts
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!
Clickjacking in attachments with the text/html MIME type
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!
X-Frame-Options: sameorigin header
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!
Strict-Transport-Security (STS) header
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.
X-Content-Type-Options: nosniff header
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.
Lockout policy to prevent brute force
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.
And much more…
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.
After a very long delay due to some nasty blockers, we finally released Bugzilla 4.2rc1 last night! Just to name a few new features or improvements:
- SQLite is now supported and becomes the 4th supported database besides MySQL, PostgreSQL and Oracle. Its support must still be considered as experimental, though.
- It is now possible to create an attachment by pasting text into a text field, without having to save your text as a file on your machine. Of course, you can still upload files as you always did.
- By default, bugmails are now sent in HTML format instead of the plain text format used till now. There is a user preference to select the format you want (text only, or text+html).
- The searching system has been improved, especially the Custom Search section in the Advanced Search page. It’s now easier to build more complex queries.
- Old components, versions and milestones can be disabled if you no longer want users to use them. Bugs which already use them are not affected, but users won’t be able to report new bugs into them (e.g. against an old version, or against a deprecated component).
- A custom field can now be displayed based on multiple values of another field. For instance, this lets you display a custom field in several products. Till now, you had to choose between a single product and all products.
- Most administrative changes made in Bugzilla are now logged and stored in the audit_log table. There is no UI to access this table yet, but developers can already start build their own tools for auditing.
- There have been several accessibility improvements to become more compliant with the W3C Web Accessibility Initiative. The project just started, and a lot of work is still needed.
- Users without editbugs privileges can no longer remove other users from the CC list of bugs.
- The encoding of text files can be automatically detected when uploading them as attachments.
- Tabular reports are now sortable based on any column.
- Buglists have a new default column list: product | component | assignee | bug status | resolution | bug summary | last change date
- Math::Random::Secure is no longer used to generate cryptographically secure pseudorandom numbers. We use Math::Random::ISAAC instead.
- X-Frame-Options = SAMEORIGIN is now passed to all page headers to protect users from framing and subsequent possible clickjacking problems.
- Two new WebServices methods have been added: Product.create and Group.create.
- Bugmails are now fully localizable and customizable (no hardcoded strings anymore).
Read the complete Release Notes to discover other new features or improvements. As it’s still a release candidate, do not forget to report any regression or broken feature to us, so that we can investigate and fix them before 4.2 final.
IMPORTANT NOTE FOR ORACLE USERS: There is still a bug when upgrading to 4.2rc1 using Oracle. Make sure to apply the patch from bug 715870 before upgrading! This patch will be in 4.2 final (or 4.2rc2, if there is one).
We also released Bugzilla 4.0.3, which is our current stable release, and Bugzilla 3.6.7 and 3.4.13. All these releases contain two security fixes. Bugzilla 4.2rc1 also has some security improvements which have not been backported to stable branches to not break 3rd-party applications.
With the coming release of Bugzilla 4.2, the 3.4.x series will reach End Of Life, meaning that no more security fixes will be released for this series. If you have Bugzilla 3.4.x or older, you are highly encouraged to upgrade to Bugzilla 4.2rc1 or 4.0.3.
I just created an "official" Bugzilla page on Google+: https://plus.google.com/104215203522965843895. Feel free to look at it from time to time to get the latest news about the Bugzilla development.
Note: I won’t give any price to the winner.
If you are like me and want to compile DBD::Oracle to use with Bugzilla and your installation of Oracle 10g XE, simply type the following command from the bugzilla/ root directory:
Of course, you must have installed oracle-xe-univ-10.2.0.1-1.0.i386.rpm already. This should save you a few headaches to make it work. :)
More than 3 months after our last releases, we finally released Bugzilla 4.1.3, 4.0.2, 3.6.6 and 3.4.12 last night. Bugzilla 3.6.6 and 3.4.12 are security releases for our old supported branches. Bugzilla 4.0.2 contains security fixes and several useful bug fixes, including:
- The Bug.create() WebService method now throws an error if you pass a group name which doesn’t exist. In Bugzilla 4.0 and 4.0.1, this group name was silently ignored, leaving your bug unsecure if no other group applied.
- Moving several bugs at once into another product works again. In Bugzilla 4.0 and 4.0.1, it displayed the same confirmation page again and again, and changes were never committed.
- Marking a bug as a duplicate now works in Internet Explorer 9.
- The XML-RPC interface now works with SOAP::Lite 0.711 and 0.712 under mod_perl.
- and much more!
I strongly recommend to upgrade to 4.0.2, which is much more stable and usable than 4.0 or 4.0.1!
And for those who love to live dangerously, we also released Bugzilla 4.1.3, our lastest development snapshot. It contains all the security and bug fixes mentioned above. As we don’t accept any new features for Bugzilla 4.2 since we released 4.1.2, we focused on fixing regressions and other nasty bugs. Bugzilla 4.1.3 should be much more usable than 4.1.2, even if it’s not production-quality yet. Depending on how things go and the feedback we get, this could be the last development snapshot before 4.2rc1. Note that once Bugzilla 4.2 is released (probably near the end of this year), Bugzilla 3.4 will reach End Of Life and we won’t support this branch anymore.
We had another Bugzilla meeting on IRC yesterday (channel log), and the three topics were about Bugzilla 4.0.2, 4.2rc1 and about Bugzilla 5.0. So I’m going to give you a brief summary of what has been discussed.
We still have a few blockers for 4.0.2. Due to security bugs being under investigation, we are probably going to release Bugzilla 4.0.2, 4.1.3, 3.6.6 and 3.4.12 before we branch for 4.2rc1. ETA: asap (I cannot be more precise as it all depends on our free time, as we are all volunteers; but this should be done in the coming few days or weeks)!
The list of blockers for 4.2rc1 is pretty large. Fortunately, they all have a developer assigned to them, and so we can expect some activity there, at least once the security releases mentioned above are out. ETA: several weeks, maybe July?
What will come after Bugzilla 4.2 depends on the progress made to redo the UI of Bugzilla, especially about show_bug.cgi, see bug 662605. Once the new UI is complete, we will call Bugzilla 5.0. Meanwhile, we will release Bugzilla 4.4, 4.6, … till the new UI (which is developed in its own branch) is merged with the main tree. Besides the new UI, we defined some main goals for the next release (independently of its version being 4.4 or 5.0), and we will try to fix as many of them during the next development cycle. As major Bugzilla releases are time-based, instead of feature-based, probably not all these enhancements will be implemented on time for the next release. If there is one you really cannot live without, feel free to join us and help implement them. New contributors are always welcome! ;)
Before programming, programmers usually go to school at least till the age of 16 (and then there is also high school and university for some of them). During the secondary school, pupils all learn the order of operations in mathematics. In particular, they all learn that -4^2 = -16, because exponents always take precedence over +, -, * and /. There is no exception to this rule, except in the world of spreadsheets, including Excel, OpenOffice and LibreOffice. Here, there are some developers (I hope not all of them) who either never went to school, or preferred to sleep during maths classes. Why? Because in their world, -4^2 = 16. Arghh! In the world of spreadsheets, only Gnumeric developers seem to have gone to school and remember what their maths teachers told them, and Gnumeric works just fine. Oh, and guess what? Scientific tools like Gnuplot and Mathematica also return -16, as well as Perl and Python and probably mostly everything else which exists in the world.
OpenOffice bug 24271 comment 1:
"you're wrong. The function works according to the mathematical rules. -4^2 is -4*-4 or 16"
OpenOffice bug 24271 comment 27:
"Result of input '=-2^4' can't be anything else than (-2)^4! Here the '-' can't be anything else than an algebraic sign, interpretation as a subtraction operator for '-(2^4) is completely useless like a mathematical expression '/3'"
LibreOffice bug 37271 comment 1:
"Imho LibO "intuitively" correctly recognizes the difference between a "Sign of a number" ant the subtraction operator. I disagree with reporter's interpretation. [...] Please provide information concerning public available mathematical sources supporting your thesis."
These last two comments are from the same developer (one who definitely never went to school). The OpenOffice bug has been marked as INVALID, and the LibreOffice bug has been marked as NOTABUG (a synonym but more polite bug resolution to say INVALID). It’s just unacceptable that developers intentionally ignore mathematicals rules which are universally accepted across the whole world, and decide to reimplement their own rules, and then treat users who are totally right as if they said that 1+1=3. A more respectful (but still unsatisfying) bug resolution would have been WONTFIX with the comment that the reporters of the bugs are right, but due to the way Excel works, and for compatibility reasons with Excel, they are forced to do this incorrect statement that -X^2 = (-X)^2. Also, the helper assistant should pop up and warn the user about this misbehavior.
I hope the developers who wrote these comments above are not the ones who write the core code of OpenOffice/LibreOffice! Else I wouldn’t be surprised to discover that 1+1=3 is finally correct too. :)
Since the release of Bugzilla 4.0 in mid-February, you may have noticed that I strongly reduced my involvement in the Bugzilla project. There are several reasons for this decision:
- I spent so much time at the end of last year and at the beginning of this one in writing and reviewing patches to fix the remaining nasty blockers for 4.0 that I needed some rest. As the QA lead, I also spent a fair amount of time checking all the regressions reported in the last few months and testing Bugzilla 4.0 as much as possible to make sure it was ready for release. Among others, this meant also updating all our automatic QA test scripts (which use Selenium) to correctly run with 4.0.
- I was also involved in several discussions taking place among core developers and managers about the way Bugzilla should go and the way the Bugzilla project is managed, and there are some hot topics where we are far from a consensus. All these discussions take a lot of time and energy too. This is not the right place to give details, though. Those who are concerned by these discussions already know the details.
- The main reason why I joined the Bugzilla team in August 2004 was because there were obvious broken or missing features in the version of Bugzilla available at that time, i.e. Bugzilla 2.18rc2. As the code didn’t look too terrible, I decided to give it a try and fix some bugs myself, and that’s how I started contributing. But as time passed, obvious broken features were fixed, and obvious missing features were implemented. So I then focused on more difficult, but less annoying, bugs and missing features. And with the releases of Bugzilla 4.0 and 4.1.1, I came to a point where all I think was important to have was there. You guess what this means. My motivation to implement new features obviously decreased, mostly because they aren’t trivial to implement and the benefit for users is smaller.
I think now is a good time to see how much I contributed to the project in these last 7 years, and what I achieved during this time. As I was checking this myself today, I thought you may be curious to know what were my main contributions, and so I decided to share the list below. Note that I fixed 1224 bugs in the Bugzilla product, so I’m not going to list them all. Only the outstanding bug fixes and new features are listed below, ordered by release versions:
Bugzilla 2.16 – 4.0
34 security bugs, across all versions.
Bug 206037: There were many places where user data was incorrectly filtered before being displayed in the web browser, which could potentially lead to XSS or break pages entirely. This was a pain to fix all these places, and I had no fun in doing this, but it was necessary to really protect our users.
Other contributions for this release were all bug fixes as Bugzilla 2.18 was already feature frozen when I joined the project.
Bug 180879: Till now, everybody could edit flags in bugs. I implemented permissions for flags so that admins could decide who would be allowed to request a flag, and who would be allowed to grant and deny them. Mozilla uses this feature heavily e.g. for their blocking and approval flags.
Bug 319055: If a bug comment had a "." on its own line, the remaining part of the comment was skipped in bugmails.
In this release, I also helped with the cleanup process to remove all these old %FORM, SendSQL() and other oddities which were in Bugzilla 2.x.
Bug 46296: Till now, all parameters were listed in a single page, making the page ridiculously long and parameters hard to find. I refactored this into separate panels, grouped by topic. I also did it in a way that parameter descriptions could be localized.
Bug 301508: CGI.pl was a kind of black hole with tons of subroutines in it, to achieve many unrelated goals. With the help of other developers, we moved these subroutines into modules, grouped logically. This was a required cleanup to be able to develop new features without adding additional mess to the code.
Bug 313020: I implemented the ability to tag bugs individually. These tags then appeared as normal saved searches in the footer of pages, so that you could easily list all bugs with the same tag.
I also helped with removing stuff from globals.pl, another black hole used in previous releases.
Bug 38862: In order to protect users from malicious attachments, I implemented the ability to specify an alternate host for attachments. You can even set it to have one different host per bug, to avoid attachments from one bug to interact with attachments from another bug. That’s the configuration used e.g. by Mozilla.
Bug 44595: I implemented the ability for admins to delete attachments, e.g. malicious ones, or because they contain confidential data which wasn’t supposed to be attached to the bug.
Bug 87795: When creating a new user account, you now get a token by email to confirm that your email address is valid, rather than assuming that it’s the case and sending the password by email directly. This also lets you choose your password yourself rather than generating a random one automatically.
Bug 92515: When the resolution on a bug is wrong, you can now change it without having to first reopen the bug. In some other bugs, I also fixed several such annoying two-steps processes which were not needed and irritating.
Bug 94534: I implemented the ability for admins to customize the list of bug resolutions. Admins can add/edit/remove resolutions from the web UI directly instead of having to hack the source code to make it work.
Bug 174039: When filing a new bug, you can set flags at the same time, instead of having to file the bug first and then edit it.
Bug 189627: I implemented the ability to give canconfirm, editbugs and editcomponents privs on a per-product basis so that installations with many distinct products can better separate user privileges (and only give privileges for products they are working on).
Bug 274802: Previously, when you were moving a bug from one product which has some given flag types to another product which has a different set of flag types, all existing flags set to the bug were deleted. Now, if the target product has a flag type with the same name as the original product, Bugzilla migrate the old flag to the new one.
Bug 282121: globals.pl is now gone. All subroutines have been moved into their respective modules. At this point, we can say that the old and ugly code has been removed from the source code. Bugzilla 3.0 is born!
Bug 287326: I implemented the ability to add custom single-select fields to bugs. This was the second custom field type being implemented, after free text fields.
Bug 317409: I implemented the ability to hide obsolete attachments in bug reports.
Bug 330487: In Bugzilla 2.x, an admin had to manually check if there were new releases of Bugzilla, or at least watch some mailing-list to get this information. Now, Bugzilla can automatically notify admins when a new release is available.
Bug 340426: It was a pain to be forced to scroll to the bottom of the page to access links such as "New", "Search", "Log in", etc… I duplicated these links to the top of the page to avoid this problem.
Bug 344875: I implemented the ability to create and control custom fields from the web UI. Before that, you had to run a script from the shell.
Bug 354661: I created a search plugin for Firefox 2+ and IE 7+.
Bug 101179: Till now, bug statuses were hardcoded in the source code. Admins can now add/edit/remove them from the web UI. I also implemented the ability to control which transitions were allowed.
Bug 218618: When viewing a patch, line numbers are now displayed, greatly helping to locate code and changes in files.
Bug 304005: Bugzilla is now able to authenticate against a SMTP server to send bugmails.
Bug 182238: Till now, the timezone used to display the timestamp of comments was controlled by the admin. Now, each user can select the timezone of his choice.
Bug 108243: You can now display bug flags in buglists.
Bug 302542: You can now delete series in new charts, either one by one, or when deleting a product.
Nothing exciting from me in this release. I spent most of my time fixing regressions and doing QA. I only implemented minor new stuff.
Bug 119703: You can now create an attachment simply by pasting text into a text field, instead of being forced to attach a file.
Bug 142394: You can now sort columns in tabular reports.
Bug 466968: I did a major cleanup of the mail-generation code. It’s now much easier to extend and customize it, and bugmails are now fully localizable.
Bug 529974: Users with local editcomponents privs, i.e having such privs for some products only, can now also edit flag types for these products. Before that, you had to ask someone with global editcomponents privs to do changes for you.
As you can see, I hacked many different parts of the Bugzilla code, implementing various major features. Now, I came to the point where I think I implemented most things I considered important, from my point of view. I still have one last new feature which is in progress, which is the ability to identify the sender of an email sent to email_in.pl, see bug 419203. I hope to have this feature ready for 4.2. After that, it’s unclear what my contributions to the project will be, if any. There are two additional features which would be great to see being implemented:
- Bug 123130: Let several Bugzilla installations talk to each other, e.g. for dependencies or to get the bug status and resolution of an external bug.
- Bug 55970: Add the ability to better track progress of a bug relative to several branches.
I think those two features together would be great candidates to define what would be called Bugzilla 5.0. But maybe I won’t be around anymore when this happens, as Bugzilla 5.0 isn’t expected before 2012 at the earliest (Bugzilla 4.2 will be released at the end of 2011, and I suppose there will be a 4.4 before 5.0).
On http://www.debian.org/security/, I can read:
"Debian takes security very seriously. We handle all security problems brought to our attention and ensure that they are corrected within a reasonable timeframe."
By default, there is no reason to not believe them. But while talking with the administrator of Samba Bugzilla in bug 7121, I realized this was far from being true! What follows is specific to the Bugzilla case, but I guess there are plenty of other similar examples for other Debian packages.
This security report set the urgency to "High", and despite the corresponding bug report has been reported to Debian more than a month ago asking the maintainer of the Bugzilla package to release new versions, nothing has been done so far. Even Secunia marked this security issue as "moderately critical", which is the third level out of five. And I myself emailed the Bugzilla package maintainer at Debian a few days ago, but got no response so far.
So my question is this: how can Debian honestly argue that they take security very seriously? It looks like it takes ages to get something done, which is usually not a big deal when talking about new features, but is definitely a problem when talking about security.
I wanted to know if there were other older unpatched security bugs relative to Bugzilla packages, and I’m a bit irritated to see that there are many! Some of them are two years old! Yes, very seriously!
Bugzilla developers at Mozilla are in no way in charge to maintain these packages, neither for Debian, nor Fedora, nor Mandriva nor any other Linux distro, so we have no control at all on that. And people often come on IRC asking us for help, because their Bugzilla package provided with their Linux distro is broken or behaves in a weird way (typically a broken configuration or customization). And guess what? Most of the time, they use the Debian package. Yes, very seriously! For comparison, Fedora updated their Bugzilla packages the day after we released 3.6.4, and Mandriva the week after! It looks like they take security a bit more seriously.
We released Bugzilla 4.0 a few minutes ago! It has many new features and improvements compared to Bugzilla 3.x, and comes almost 4 years after Bugzilla 3.0 (which was released in May 2007). With this major release, Bugzilla 3.2 reached End Of Life (EOL) and is now unsupported. Everybody running a version older than 3.4.10 should upgrade to 4.0 to get future security and stability fixes.
Bugzilla 4.0 got full testing from the QA team, and should be considered stable:
All tests successful.
Files=55, Tests=11621, 2473 wallclock secs ( 1.86 usr 0.23 sys + 21.95 cusr 1.66 csys = 25.70 CPU)
Update: If you get the error "ExpiresActive not allowed" from Apache when upgrading to Bugzilla 4.0, edit your Apache config file httpd.conf as explained in the Bugzilla documentation. Till now, you probably had:
<Directory /var/www/html/bugzilla> ... AllowOverride Limit </Directory>
Now the AllowOverride command must be:
AllowOverride Limit FileInfo Indexes
in order to force the web browser to update its cache with newer CSS and JS files when they change (e.g. when upgrading to a newer release in some months). If Bugzilla 4.0 is working fine without this change, then this means that you either don’t use mod_cgi, or this feature is not enabled in your Apache server.
Update 2: Contrary to what Samuel Gibbs said in his post, we are not dropping support for all versions of Bugzilla 3. As I said above, only support for Bugzilla 3.2 and older is dropped. This means that Bugzilla 3.4 and 3.6 are still supported, at least till the end of the year.
Update 3: Bugzilla 4.2 should be released at the end of this year, if everything goes well.
Yesterday (23 hours ago, to be exact), we released new versions of Bugzilla which all include fixes for critical security vulnerabilities. The most critical one is described in CVE-2010-4568 and you can get the patches from bug 621591 for all versions of Bugzilla 3.2 and newer. This means that we provided no patch for Bugzilla 3.0.11 and older, and so if you are running such an old version, then you are in trouble, and you would have to backport the patches to your installation yourself. If you didn’t yet, now would be a good time to decide to upgrade to Bugzilla 3.6.4, or 4.0rc2 which should now be stable enough. You have been warned! :)
About Bugzilla 4.0rc2, note that this is probably our last release candidate before 4.0 final, which we expect to release mid-February. When 4.0 final will be released next month, we will also stop supporting Bugzilla 3.2.x. So if you run something older than Bugzilla 3.4.10, then you should really upgrade. Just for your information, Mozilla, GCC and Xfce already upgraded to 3.6.4 today. So this is doable even for large installations. ;)
If you are curious to know the version running on some well known Bugzilla installations worldwide, I collected this information in a single place: http://lpsolit.wordpress.com/bugzilla-usage-worldwide/. I think this way of doing it is better than writing a new article each summer, as I did for the last three years. This page also lists the approximate number of bugs contained in the DB, to give you an idea how big an installation is.
It’s pretty cool to know that so many large companies and projects use Bugzilla to track their bugs. For instance: kernel.org, RedHat, Novell, Mandriva, Mozilla, WebKit, KDE, GNOME, Logitech, Facebook, GCC, Apache and especially Yahoo! with more than 4 million bugs! I hope even more companies and projects will use Bugzilla in the future. :)
Last night, we released Bugzilla 4.0rc1 and Bugzilla 3.6.3, as well as security-fixes only 3.4.9 and 3.2.9.
Bugzilla 4.0rc1 comes 3 months after our latest development snapshot 3.7.3, and is considered stable enough for use in non-critical environments. If nothing serious is found in this release candidate, we will release Bugzilla 4.0 final in a few weeks (probably in December). Else we may release another release candidate if major problems are found. Bugzilla 4.0rc1 comes with many improvements over Bugzilla 3.6, for instance: automatic detection of duplicates when reporting a new bug, improved search and attachment details pages, autocompletion for all user fields (requires JSON-RPC to work on your installation), a new default status workflow, the ability for Bugzilla to remember more than one search at once, several new WebService methods among which the highly desired Bug.update() method, the ability to display multi-select custom fields as a column in bug lists (including bug flags!), and many new code and template hooks to help you write extensions without having to hack the core code.
Bugzilla 3.6.3 is our latest stable release, which includes several bug fixes as well as three security fixes, as described in the security advisory. It contains no new features.
Note that once Bugzilla 4.0 is released, we won’t support the 3.2.x series anymore. Installations running such old versions should upgrade to either 3.6.3 or 4.0 final when it comes out.
It’s usually easier to make Bugzilla work with Apache, but IIS7 made things a lot easier than in previous versions, and it’s now pretty trivial to make it work with IIS too. The screenshots below are in french, but I guess you can understand what needs to be done.
Only two actions are needed, as shown above. Two new panels will be displayed:
That’s it! Bugzilla should work fine now. :)
Our latest stable release, Bugzilla 3.6.2, is now available in 10 languages: bg, cs, de, en, es-es, fr, ja, pl, pt-br, and zh-tw. No idea what happened to the russian team, which disappeared soon after 3.5.2. No idea either for the belarusian team, which stopped releasing new templates after 3.2.3. If you don’t want to install the l10n templates yourself, but you want to see how Bugzilla looks like in other languages, you can play with this test installation, which has all the available l10n templates installed.
For those who use GCC Bugzilla and Sources Bugzilla (sourceware.org), please note that they have both been upgraded to 3.6.2+ (Sources Bugzilla was running 2.17.5 two hours ago, haha).
We released Bugzilla 3.6.2, 3.4.8, 3.2.8, and 3.7.3 last night! They all contain fixes for 4 security bugs, and Bugzilla 3.6.2 and 3.7.3 also include numerous bug fixes. Bugzilla 3.6.2 is our most stable release, and is the recommended version to use in production. Bugzilla 3.7.3 is a development snapshot to let you test what will become Bugzilla 4.0. Bugzilla 3.7.3 is now feature complete, and I hope our next release on the 4.0 branch will be 4.0rc1, assuming we manage to fix all remaining blockers (18 blockers as of today). There is no ETA for 4.0rc1 yet, but probably around September or October, if everything goes well. Note that many bugs and regressions are being found in 3.7.x, so you shouldn’t use Bugzilla 3.7.3 in production (but we would be happy that you install it in a test environment and help us catch remaining bugs and regressions before we reach the release candidate phase).
Bugzilla 3.7.3 being feature complete, and no major changes in templates being expected, now is also a good time for localizers to start their work on the 4.0 branch. Once you are ready, feel free to ping me on IRC (nick: LpSolit), or leave a comment to this post with a URL to your website, and I will add it to our list of available localized tarballs (of course, if you have checkin privs, you can update the list yourself). For new localizers, please don’t waste your time translating Bugzilla 3.2.8 or 3.4.8. Bugzilla 3.2 will reach End Of Life at the end of the year or early next year, when Bugzilla 4.0 is released, and Bugzilla 3.4 should reach EOL at the end of next year. Focusing on Bugzilla 3.6 and 4.0 only is a better way to spare some time. ;)