What happened to Mozilla Update?
Well, its obvious by now, things haven’t exactly gone as planned with Mozilla Update Beta. While it’s online, it’s not exactly operating as designed, with new submissions/updates having not been processed for one month now. This, of course, rumors of a situation or conflict within Mozilla Update, Its even been on MozillaZine, though in a rather surprising and unexpected way. In this post, I’m going to try to explain what happened, with as little bias as possible with regard to the events.
For the record, I’m no longer the module owner of Mozilla Update, as of January 16, 2005. That role now belongs to Scott Kveton. With the way rumors go around Mozilla, I should say this up front, I wasn’t forced out or anything of the sort. I’ve chosen to step down from that role because of time, mostly, along with an increasing lack of motivation to remain owner of the code. The project’s growing size requires quite a bit of time to manage, which is something I don’t have anymore, my life situation changed quite a bit since I started working on it almost a year ago. Also, Hendikins is no longer working on the project either, he was co-administrator and spent *alot* of time pruning the comments section for spam, contributing alot to the increasing accuracy of the ratings.
In November, after the Firefox 1.0 release, there was a meeting held about the status of Update-beta, which was originally planned, but never really scheduled (in fact, it was opposed by Mozilla QA) to launch for Firefox 1.0. At that meeting, the general plan was for a release the second week of December. There was also discussion of QA, and several bugs were filed. My understanding was QA would begin testing update-beta.mozilla.org, as evidenced by bugs that got filed, etc.
Unfortunately, communication didn’t maintain at this good level for December, because of both mistakes made by myself, as well as mozilla.org. In the absense of good communication, I operated based on my own assumptions and information about the December time-table, expecting formal QA plus community members to be testing update-beta as they’d test a nightly release of Firefox, the development pace wasn’t that ambitious. All of the big changes were complete, and the update-beta site was open for testing, many authors were testing the functionality and many bugs, although most of them minor, were reported.
Several days before update-beta launched, the database and backend were migrated to the new site, so that new submissions would be processed by the new code, this froze update.mozilla.org in favor of update-beta.mozilla.org, and allowed the admins/editors and authors to use the new code to find any major showstoppers.
With a rather sucky turn of events, it was much closer to the Christmas holiday than I would’ve liked, with the positive feedback and already overdue 2nd week of December launch date hanging around, along with my desire not to keep update.mozilla.org frozen any longer than it had to be from new arrivals (if I knew then what I know now. heh), I chose, failing to ensure mozilla.org was ok with the idea, but also without any feedback about what the status of update-beta in their view was, to launch update-beta late on December 23rd.
In short, this action would prove bad very quickly. 2 security bugs were found within the first 24 hours in the Developer backend. Neither of these bugs affected author-level access, only editors. The first, was in the user manager, which would accidentally erase all admins/editors if used by an editor (Bug 275904), the other, allowed an editor to create an admin account (Bug 275905). Now, while these are serious bugs, they’re not critical for 2 reasons, (1) Mozilla Update has no editors that are untrusted, and (2) All Editors for Mozilla Update were admins less than 24 hours before. Meaning, that they wouldn’t get any privledges from Bug 275905 that they wouldn’t have had before anyway, and they were perfectly trustable and could’ve been bumped to admin status to workaround Bug 275904. Situation contained right? Wrong.
That action wasn’t taken, instead, in an alarmist move by mozilla.org, they locked permissions on the server, and disabled (403 Forbidden) any script that touched the DB, including the entire DeveloperCP (including Admin access) as well as comments/ratings. At this point, the only thing that gets updated is downloadcounts, presumably because it appeared to critical to mangle.
Now, I can understand the alarmist handling, the holidays leaves them without the full staff, and I wasn’t available all day on the 24th/25th, but, it also says there was a complete ignorance of how Mozilla Update operated within mozilla.org.
Now, a month later, the situation is unchanged, as far as end-users are concerned. The site remains closed to new additions and the only note about any of this is this revised disclaimer on the front page.
“Please note that the Mozilla Update site is undergoing a design update and a rewrite based on user input.” The security bugs found have been long fixed, even thoguh I’m told that mozilla.org hasn’t blessed the patches to land on the live site. Why not? If they were worth closing the site for, arent’ they worth landing?
Security of UMO is a phrase that’s being thrown around quite a bit as the excuse for why its remained in a stagnate state for a month. In fact, there’s a security audit in progress, or will be soon if it isn’t underway already. Hopefully the completion of that audit will calm some nerves and find remaining issues that haven’t been found in Update 1.x already. Though its certainly not a good excuse for keeping Update 1.0 disabled while Update 0.9 was allowed to function normally. Update 1.0 closes many security issues known at the time to be 100% exploitable in Update 0.9.
A short list of fixed security bugs in update 1.0: (of varying size, the SQL Injection and CSRF bugs are quite large patches, IIRC)
Bug 247318 Prevent cross-site request forgery
Bug 250596 URL parameters not cleaned
Bug 256972 SQL injection all over update php code
Bug 257516 Disclosure of author’s email address
So, while I’m not going to argue for the DevCP to be opened to be public, if they’re afraid of it. Comments/Ratings should be openable, particularly with the SQL Injection bug in it fixed. DevCP can also be open to trusted users, just as it was with update 0.9, the code is certainly no worse, and is quite a bit more usable.
The current situation has left authors and users without official updates for a month, which breaks Firefox 1.0’s extension update mechanism that end-users expect to function in the 1.0 version of the product. It prevents authors from distributing updates (even security updates) to their extensions/themes.
In my opinion, this situation is unacceptable. and shouldn’t have been allowed to blossom into an update freeze for a month. There’s no good excuse for it. Admins/Editors could be allowed to push items through, if the server restrictions were changed. If they’re waiting for the Developer CP to be trustable to allow updates at all again, then there’s a real obvious answer, editor laziness, because the only thing a fully-open Developer CP gives them (which presumably is coming with Update 1.0.1/1.1, whichever they’re calling it), that a restricted to trusted-users only one doesn’t, is author-added items, which is less work on the editors. Which means, that not only does Mozilla Update need a security audit, it needs a check of its staff.
They’ve also dropped the ball by not telling any of this to authors. There’s been no official announcement to authors as to why their items have not been touched in the bugs that were pending, or that Mozilla Update is closed to new listings (in fact, all changes to any listing. heh)
So, in closing, I accept my responsibilty to what happened with regard to my failing to maintain communication, and while I’m still going to volunteer with Mozilla, I’m not likely to spend much time with Update anymore, except for questions/support where needed.
Though I’m also going to call on the Update team to be more transparent with what’s going on with the community who supports it. Mozilla Update isn’t the only source for extensions, just because it’s linked with Firefox/Thunderbird makes it the most obvious, but trust is earned, and is not automatic. Never telling authors who you depend on for listings what’s going on, isn’t going to get you anywhere, and neither is claiming you’re redesiging based on user input. (Particularly when the sites largest form of user feedback is 403 Forbidden.)
Remember, Mozilla Update has a target audience, just like Firefox does. That audience isn’t its developers, or its Admin/Editor staff, never has been. It should not be the Mozilla Foundation or MF Sysadmins either, Its the end-users of the site, who are its target audience, most of them are Firefox or Thunderbird users, and Mozilla Update plays an important role in the success of both of those products.
Its time to publish an announcement to MozillaZine (and MozillaNews or anywhere else it should be seen), no matter how unpopular, as to what’s going on, what it means to end-users (that they’re not getting updates) and authors (that they can’t make any) and when both groups of users of Firefox can expect to have the situation restored.
UMO Bits N Bytes
Chris Crews has some issues with why Update is still static, and why we’re not unlocking DevCP at present. I realize that we’re sort of putting out our extension/theme authors in the process, and I would like to apologize for the ongoing delay and t…