https://bugs.webkit.org/ is currently running Bugzilla 3.2.3, which reached EOL last month. You should upgrade to 4.0.
Some notes for anyone looking into this: Bugzilla on bugs.webkit.org has a number of local modifications (which aren't always identified by comments) that must be merged into a new version and then qualified in a test environment before being deployed. The custom templates are the most difficult to merge because they're not modified in place, so the changes have to be reapplied to new copies of the updated templates. Many of the local modifications should have bugs (enhancement requests) filed on <https://bugzilla.mozilla.org/> so that we can eventually get out of the business of local modifications to make upgrades easier. There are some notes here on how to upgrade, but it may be easier to take a diff of the changes against 3.2.3 and then apply them to 4.0: <http://trac.webkit.org/wiki/UpdatingBugzilla>. After it's deployed, there is usually fallout from the UI changing in the form of complaints, and you'll rarely get any accolades for finishing the update. (Just something to look forward to. :)
Would you agree to attach a diff of the bugs.webkit.org code vs vanilla Bugzilla 3.2.3? I'm wondering how much code could be moved into an extension (which would save you a lot of trouble every time you want to upgrade).
Bugzilla 4.2 has been released this week. It has many security improvements compared to 3.x.
How would someone who doesn't work at Apple attempt such an upgrade? It seems we'd need access to the server? (This bug came up again today in discussing why webkit-patch is so slow... one of the reasons being it talks to bugzilla via page scraping.)
(In reply to comment #4) > How would someone who doesn't work at Apple attempt such an upgrade? It seems we'd need access to the server? (This bug came up again today in discussing why webkit-patch is so slow... one of the reasons being it talks to bugzilla via page scraping.) The bulk of the work is doing the merge and cleaning up conflicts, then fixing any issues that occurred as a result of the merge. You could perform the merge, set up a test server, and then make sure basic functionality works, then commit the changes to a branch or generate a patch. Having said that, I'm going to attempt to upgrade Bugzilla during the WebKit Contributors Meeting.
(In reply to comment #5) > Having said that, I'm going to attempt to upgrade Bugzilla during the WebKit Contributors Meeting. Status update: I've merged the changes up to v4.2.1, but I need to shake out merge issues on a test instance of Bugzilla. Due to various scheduling issues, I won't be able to work on this for a couple of weeks. Will get back to it as soon as possible.
Fantastic! Thank you for looking at this Dave!
*** Bug 82632 has been marked as a duplicate of this bug. ***
Working on this now at the WebKit Contributors Meeting.
Bugzilla 4.4 has been upgraded meanwhile.
And 4.4.1 includes several security fixes. Any progress since your last comment 9?
As far as I know, we still use 4.2.11. 4.2.16 is the latest and the last relase of 4.2.x since 4.2.x reached of its EOL on 2015 Dec 22: https://www.bugzilla.org/news/
Any interest to upgrade bugzilla to a still supported version?
Testing upgrade of Bugzilla 5.0.3.
<rdar://problem/22524280>
*** Bug 167052 has been marked as a duplicate of this bug. ***
Bugzilla has been upgraded to version 5.0.3.