• 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.

make -f client.mk

from comm-central/, everything works fine till I get this error message:

/usr/bin/python2.7 ../../../mozilla/_tests/mozmill/resources/installmozmill.py ../../../mozilla/_tests/mozmill/../mozmill-virtualenv
Python: 2.7.1 (r271:86832, Sep  5 2011, 15:04:00)
[GCC 4.5.2]
New python executable in /root/tmp/tb/comm-central/obj-i686-pc-linux-gnu/mozilla/_tests/mozmill-virtualenv/bin/python2.7
Also creating executable in /root/tmp/tb/comm-central/obj-i686-pc-linux-gnu/mozilla/_tests/mozmill-virtualenv/bin/python
Installing setuptools….
Complete output from command /root/tmp/tb/comm-ce…ualenv/bin/python2.7 -c “#!python
\”\”\”Bootstra…sys.argv[1:])

” /root/tmp/tb/comm-ce…ols-0.6c11-py2.7.egg:
error: invalid Python installation: unable to open /root/tmp/tb/comm-central/obj-i686-pc-linux-gnu/mozilla/_tests/mozmill-virtualenv/include/multiarch-i386-linux/python2.7/pyconfig.h (No such file or directory)
—————————————-
…Installing setuptools…done.
Traceback (most recent call last):
File “virtualenv/virtualenv.py”, line 1965, in <module>
main()
File “virtualenv/virtualenv.py”, line 795, in main
never_download=options.never_download)
File “virtualenv/virtualenv.py”, line 895, in create_environment
search_dirs=search_dirs, never_download=never_download)
File “virtualenv/virtualenv.py”, line 588, in install_setuptools
search_dirs=search_dirs, never_download=never_download)
File “virtualenv/virtualenv.py”, line 562, in _install_req
cwd=cwd)
File “virtualenv/virtualenv.py”, line 863, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command /root/tmp/tb/comm-ce…ualenv/bin/python2.7 -c “#!python
\”\”\”Bootstra…sys.argv[1:])

” /root/tmp/tb/comm-ce…ols-0.6c11-py2.7.egg failed with error code 1
Failure to install virtualenv
make[5]: *** [mozmill-virtualenv] Erreur 1
make[5] : on quitte le répertoire « /root/tmp/tb/comm-central/obj-i686-pc-linux-gnu/mail/test/mozmill »
make[4]: *** [libs] Erreur 2
make[4] : on quitte le répertoire « /root/tmp/tb/comm-central/obj-i686-pc-linux-gnu/mail »
make[3]: *** [libs_tier_app] Erreur 2
make[3] : on quitte le répertoire « /root/tmp/tb/comm-central/obj-i686-pc-linux-gnu »
make[2]: *** [tier_app] Erreur 2
make[2] : on quitte le répertoire « /root/tmp/tb/comm-central/obj-i686-pc-linux-gnu »
make[1]: *** [default] Erreur 2
make[1] : on quitte le répertoire « /root/tmp/tb/comm-central/obj-i686-pc-linux-gnu »
make: *** [build] Erreur 2

The problem is that the script looks for pyconfig.h in mozmill-virtualenv/include/multiarch-i386-linux/python2.7/, but the right path is mozmill-virtualenv/include/python2.7/, i.e. without multiarch-i386-linux/. Anyone knows how to fix this problem?

Note: I won’t give any price to the winner.

En arrivant sur la partie protégée, j’ai constaté que la page me demandant mon nom d’utilisateur et mon mot de passe avait l’URL suivante:

lmpasswdlg.html?l='14159490828c4a1e...',p='14159496828c4a19...'

(J’ai tronqué ces deux variables pour qu’elles tiennent dans la largeur de cette page.) En regardant le code source de la page, et en particulier son code JavaScript, j’ai constaté que ces variables correspondaient respectivement au nom d’utilisateur du site et à son mot de passe, mais en version encryptée. À ce stade, je m’attendais à ce que le script prenne les données entrées par l’utilisateur, les encrypte et les compare aux valeurs ci-dessus. Dans ce cas, il n’y aurait pas eu moyen d’obtenir facilement le nom d’utilisateur et le mot de passe. Or, et c’est là que ça devient intéressant, le script fait exactement l’inverse. Il décrypte ces valeurs pour les comparer en clair aux valeurs entrées par l’utilisateur! Il ne me restait plus qu’à exécuter ce code moi-même avec les valeurs ci-dessus, et regarder les valeurs ainsi retournées:
login = ‘cdists’, password = ‘eca0665′. Wow! Et me voilà dans la partie “protégée” du site. Vous parlez d’une protection!

Donc tout ce code ne sert strictement à rien:

function HexToDec(c) {
  var alpha="aA";
  if (c>='a' && c<='f')
    return c.charCodeAt(0)-alpha.charCodeAt(0)+10;
  if (c>='A' && c<='F')
    return c.charCodeAt(0)-alpha.charCodeAt(1)+10;
  else
    return eval(c);
}

function EnDecrypStr(sSecret) {
  var sSecretTodo=sSecret;
  var sPassword="$%¢£²¼|*°«¢@%)-¾?";
  var strOut="";
  var l=sPassword.length;
  var l2=sSecretTodo.length/2;
  for (var x=1; x<=l2; x++) {
    var g=((x-1) % l);
    var iChar=sPassword.charCodeAt(g);
    var c1=HexToDec(sSecretTodo.charAt((x-1)*2));
    var c2=HexToDec(sSecretTodo.charAt((x-1)*2+1));
    var c=c1*16+c2;
    iChar=c^iChar;
    strOut=strOut+String.fromCharCode(iChar);
  }
  return strOut;
}

function HexToUnicode(str) {
  var strOut="";
  var s1=16;
  var s2=16*16;
  var s3=16*16*16;
  var l2=str.length/4;
  for (var x=1; x<=l2; x++) {
    var c1=HexToDec(str.charAt((x-1)*4));
    var c2=HexToDec(str.charAt((x-1)*4+1));
    var c3=HexToDec(str.charAt((x-1)*4+2));
    var c4=HexToDec(str.charAt((x-1)*4+3));
    var c=c1*s3+c2*s2+c3*s1+c4;
    strOut=strOut+String.fromCharCode(c);
  }
  return strOut;
}

// proviennent de l'URL ci-dessus
var l = '14159490828c4a1e809b947915191a8d0f14129693828b4f';
var p = '14159496828c4a19809b947115191e8e0f14169493828f4a1a809897';

var login = EnDecrypStr(l);
login = HexToUnicode(login);
var passwd = EnDecrypStr(p);
passwd = HexToUnicode(passwd);

if (CompareUnicodeString(my_Login, login)
    && CompareUnicodeString(my_Password, password)) {
 .... // success
}

Je ne me suis même pas donné la peine de regarder ce que pouvais bien faire la fonction CompareUnicodeString(), bien que son nom soit suffisamment explicite. J’avais déjà les informations dont j’avais besoin. Ou comment écrire du code compliqué pour rien et faire croire aux webmasters que leur site sera protégé….

1. Don’t highlight the domain name of the website: browser.urlbar.formatting.enabled = false (new in Fx 6)
2. Always display the protocol of the page (including http://): browser.urlbar.trimURLs = false (new in Fx 7)

Now, does someone know a way for a sysadmin to easily stop notifications about new releases for all users on Mac OS X? At work, users do not have admin privs and so cannot do the updates themselves. As we get a lot of comments from our users that Firefox asks them to update, we need a way to force Firefox to shup up. Asking each user to edit their preferences to disable notifications is out of question. And it’s also out of question to update Firefox on 70 computers every 6 weeks (yes, a sysadmin’s weekly job is not to update Firefox all the time, especially when he works part-time!). Updates are usually only acceptable when everybody is on vacation, i.e. Easter, summer and Christmas mostly (which means every 4 months). But in 4 months, Mozilla releases 3 new versions of Firefox!! Hum…. too frequent updates, this reminds me another story about Firefox last year.

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.

• 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.

The keyboard is totally unresponsive, and you have to reboot the PC by pressing the reboot button. When I do that, the PC first seems to reboot correctly, but suddenly decides to reboot again a few tens of seconds later, sometimes even after I’m already logged in. After the second reboot, everything goes fine again… till I try to shutdown my PC again. Hum! So I uninstalled VirtualBox 4.1.0, as this version seems broken, as reported in the VirtualBox bugtracker too.

These days, I’m pretty irritated with all these new releases which break stuff. Mageia 1 and KDE 4.6 (also here and here) come to mind. Instead of new releases with new features, I would prefer stable releases with bugfixes only.

Update: VirtualBox 4.1.2 has this problem fixed.

Bugzilla 4.0.2

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)!

Bugzilla 4.2rc1

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?

Bugzilla 5.0

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!

PS: Je ne contribue en aucun cas au projet Mageia, mais je me permets de faire de la pub pour des applications/OS/initiatives qui en valent la peine. Et Mageia en fait définitivement partie. Je souhaite plein de succès à cette nouvelle et courageuse équipe.

But when you report this bug to the OpenOffice (see also here) and LibreOffice Bugzilla installations, you are considered as being completely dumb:

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.

• 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.

Bugzilla 2.18

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.

Bugzilla 2.20

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.

Bugzilla 2.22

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.

Bugzilla 3.0

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+.

Bugzilla 3.2

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.

Bugzilla 3.4:

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.

Bugzilla 3.6

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.

Bugzilla 4.0

Nothing exciting from me in this release. I spent most of my time fixing regressions and doing QA. I only implemented minor new stuff.

Bugzilla 4.2

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).

“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.

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)
Result: PASS

Enjoy!

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.

The second reason mentioned in these bugs is that the code is mostly unmaintained, has performance issues, and makes things harder to further develop Firefox. Maybe that’s true, but moving the code into an extension isn’t going to make it faster, more maintainable or easier to keep compatible with future versions of Firefox. And users who use them daily, such as myself, will have to deal with the too numerous addons to find the one suitable for my purposes (and no, I have no fun going through this unusable addons.mozilla.org website to find the extension I need for my version of Firefox, which doesn’t suck because it freezes Firefox everytime it looks for new articles in the RSS feeds I have, which doesn’t add 3 icons here and there with no way to remove them, which doesn’t display a stupid popup every X minutes that there are 13 new articles, which isn’t disabled everytime there is a new release of Firefox because the addon author needs 6 months to update the max version, etc…).

So instead of a simple and clear UI like this:

I will have to either use Google Reader (no, I don’t need nor want Google to manage all my tasks. Google is not the Web, the Web is not Google), or try to find a suitable addon. I know so many people who have no idea what an addon is, that I think it’s inappropriate to put everything into extensions. If I want a browser with mostly no feature by default and no button and no toolbar of any kind, then I suppose I can use Lynx. And if the goal is to be as fast as Google Chrome at all cost and to have the same UI as Google Chrome, then I suggest to merge both projects. I don’t want a clone of Google Chrome, I want Firefox!

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.

“Je suis dealer, je n’ai pas d’emploi, j’agresse les gens et ne suis pas du tout intégré. J’ai brûlé mes papiers d’identité et prétends avoir moins de 18 ans (donc mineur).” Résultat? Pas expulsable, car le pays d’origine ne peut être établi.

Cherchez l’erreur!! En résumé, si vous êtes malhonnête, vous ne risquez pas grand chose: pas expulsable, car le pays d’origine ne peut être identifié; pas de peine de prison ferme, car elles sont déjà pleines; pas ammendable, encore faudrait-il avoir de l’argent; à peine inquiété, car soi-disant mineur (mais bien sûr!). Mais si vous êtes honnête, vous vous passez vous-même la corde autour du coup, et attendez que l’administration donne un coup de pied dans la chaise sur laquelle vous vous trouvez. C’est ça, la défense des droits de l’homme!

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.