7.0 was converted to final this morning and I'm pulling down 8 beta 1 for initial conversion as we speak. This will require more work than 7 because Mozilla committed a number of 10.5/10.6-specific widget changes which will need to be rewritten for 10.4, but I'm pretty confident this is possible. You'll be the first to know.
A number of people have privately asked me whether TenFourFox is susceptible to the BEAST SSL attack revealed over the weekend. This rather startling hack was able to decrypt a Paypal cookie sent over SSL, allowing the attacker to assume the identity of the logged-in user. It should come as no surprise that 1) the Mozilla security team has been discussing this (along with representatives from Google, which uses the Netscape-originated Network Security Services library also) for several months, and 2) as shipped, TenFourFox is not vulnerable. Notice that I said "as shipped." The exploit demonstrated by Rizzo and Duong used a Java applet to do the server thrashing needed to get the key out, and TenFourFox disables all plugins including the Java Embedding Plugin, so the applet cannot run. It may be possible to do something similar in Flash (though such code has not yet? surfaced), but obviously this doesn't ship enabled in TenFourFox either, and the version of WebSockets in Firefox 7 and TenFourFox 7 cannot be used to trigger this exploit.
Even with plugins, Java and/or other suitable footholds available, the SSL flaw in question is not trivial to exploit: not impossibly hard nor prohibitively expensive, but neither is it simple, quick or easy. An attacker must have control of the network the victim is using (such as a compromised or open wireless link), and must be fast enough to spy on the connection and manipulate the victim's browser to try combinations on the server the victim is accessing before the session terminates. Under the optimal conditions of the demonstration the "victim" was pwned in about two minutes; real world assaults will undoubtedly require significantly more time. It is also possible for servers to immunize themselves against the attack by negotiating ciphers that are not vulnerable to the flaw Rizzo and Duong are taking advantage of; RC4/ARC4 is one such cipher and Google is using it already on its services.
The best solution is to leave TLS 1.0 behind, but for a variety of reasons this has yet to happen, and perhaps this will be the impetus to change to a safer, later TLS version. Once a final fix is decided upon for NSS, there may or may not be a 7 chemspill; we'll follow Mozilla's lead here. A similar fix will be included in Classilla, which is technically vulnerable but hard to exploit because OS 9's MRJ is mercifully too old and Flash 7 does not support sockets of the type required.
Tuesday, September 27, 2011
Friday, September 23, 2011
Super omnibus update: 7.0 RC, updated QuickTime Enabler, and Floodgap is back up
Well, heck, let's start with the good news first. AT&T installed the T1 on Monday and DSL Extreme activated it earlier today, so Floodgap and its associated projects, including TenFourFox.com, is back online. Point your friends, enemies, rather less good enemies of theirs and friends of those people's less good enemies to it.
The T1 comes at (naturally) a substantially greater hosting cost; though it is amortized against using it for my other projects and as my regular means of Net access, it's still a pricey (but very smooth and low-latency) way of getting hosts online compared to DSL or cable, neither of which were practical options for reasons many of you already know. As a policy matter I do not accept project donations as this has the risk of encouraging expectations I and the other contributors can't satisfy, but I am considering allowing Blogger to put ads on this blog to make a little of the money back. I won't object if you Adblock them away, of course.
Mozilla has signed off on the 7 release candidate, so now we have our release candidate available ahead of Firefox 7's formal launch on September 27th. As with previous release candidates, if there are no showstoppers then this will become the formal release. There is one small fix in this version (in addition to Mozilla's fixes): because Floodgap was down there was nothing to post update snippets against, so this fix adds the 7-specific update checks. As a result, there is also a new set of changesets for builders. Read the release notes and grab for your architecture:
Also available, as promised in the previous blog entry, is a new version of the TenFourFox QuickTime Enabler. If you are new to the QTE, please see this blog entry for basic instructions; in short, the QTE allows you to play certain media types outside of the browser in QuickTime, including H.264 video (which Firefox can't play at all) and most other audio and video files by right-clicking and selecting Open Media in QuickTime. In alpha-45, here's what's new:
"One more thing." Many of you will have read the press coverage about the "BEAST" SSL chosen plaintext attack demonstrated at ekoparty this weekend. Virtually every browser is vulnerable to this; Opera has already released a patch and Chrome has one in testing. Note that Mozilla and Chrome share SSL code (i.e., they both use NSS), so the same fix is likely to appear in Firefox, but it is not currently in 7. There is substantial argument about how easy it is to pull off in practice, but certain things can make it easier, and we might talk about this once Mozilla goes public with a final determination.
Man, it's good to be online again.
The T1 comes at (naturally) a substantially greater hosting cost; though it is amortized against using it for my other projects and as my regular means of Net access, it's still a pricey (but very smooth and low-latency) way of getting hosts online compared to DSL or cable, neither of which were practical options for reasons many of you already know. As a policy matter I do not accept project donations as this has the risk of encouraging expectations I and the other contributors can't satisfy, but I am considering allowing Blogger to put ads on this blog to make a little of the money back. I won't object if you Adblock them away, of course.
Mozilla has signed off on the 7 release candidate, so now we have our release candidate available ahead of Firefox 7's formal launch on September 27th. As with previous release candidates, if there are no showstoppers then this will become the formal release. There is one small fix in this version (in addition to Mozilla's fixes): because Floodgap was down there was nothing to post update snippets against, so this fix adds the 7-specific update checks. As a result, there is also a new set of changesets for builders. Read the release notes and grab for your architecture:
Also available, as promised in the previous blog entry, is a new version of the TenFourFox QuickTime Enabler. If you are new to the QTE, please see this blog entry for basic instructions; in short, the QTE allows you to play certain media types outside of the browser in QuickTime, including H.264 video (which Firefox can't play at all) and most other audio and video files by right-clicking and selecting Open Media in QuickTime. In alpha-45, here's what's new:
- Updated for Gecko 7 (alpha-43 will not work with 7.0)
- Overly long URLs don't cause garbage characters in the URL dialogue anymore; they will simply be truncated (but will still play)
- If you are not offered the QuickTime option initially, start to play the video. When the video appears and starts, right click again and see if the option is offered then. If it is, and you open the file in QuickTime, the enabler will now automatically stop the video in the browser (if possible) so that you aren't playing it in two places. This should enable JavaScript-based video code that tries to detect browser capabilities to also be playable in the Enabler.
"One more thing." Many of you will have read the press coverage about the "BEAST" SSL chosen plaintext attack demonstrated at ekoparty this weekend. Virtually every browser is vulnerable to this; Opera has already released a patch and Chrome has one in testing. Note that Mozilla and Chrome share SSL code (i.e., they both use NSS), so the same fix is likely to appear in Firefox, but it is not currently in 7. There is substantial argument about how easy it is to pull off in practice, but certain things can make it easier, and we might talk about this once Mozilla goes public with a final determination.
Man, it's good to be online again.
Sunday, September 4, 2011
7.0b1 available, whither 6.0.2, and a special pirate edition: YARR, THIS INTERPRETER SUX
So, it's Labor Day weekend and I've spent it watching Law and Order DVDs, painting the house trim and tweaking TenFourFox. Today, for those of you with nothing better to do on a holiday weekend either, 7.0 beta 1 is available, roughly corresponding to Firefox 7 beta 4. Generally I am loathe to talk about subjective speed improvements in this blog because they are just that, subjective. However, there is a lot to like about Fx7, and the biggest one isn't the memory footprint improvements (because we're forced to take a hit on that, read on). Instead, it's the graphics stack, and the new Cairo really benefits our rendering pipelines. Pages paint quicker, animations are snappier and movie playback is less jerky. The improvement is subtle, and there is still much improvement to come, but I think virtually everyone will notice the difference. Tobias, the early trailblazer on 7, said it was the first version he felt was truly useable on his PowerBook. While I politely demur that I've been perfectly happy with TenFourFox on my iBook G4 ;) , I certainly do agree that 7 is better in nearly every metric.
Also new in 7 is the beginnings of a new HTML5 canvas backend (Azure, which will eventually take over the entire rendering pipeline; fortunately for us, the CoreGraphics version is likely to work and even if it doesn't there's still Cairo), improvements to Sync, a new Telemetry module for reporting performance back to Mozilla (we don't track this information ourselves, but if you want to remind Mozilla that PowerPC lives, go for it :), a new API for sites to determine load times and adjust themselves to slower systems, and CSS3 ellipsis support.
Oh, and it takes http:// out of the menu bar. Strangely, I'm not as offended by this as I thought I would be, but I'm not wild about it. gopher:// does still appear, though, and so does https://, so I guess that's all that matters. :D
So, yeah, about that "memory footprint" thing. Firefox 7 is being touted as the first product of Mozilla's MemShrink project, bragging numbers that reduce its overall memory usage by 20-50%, will leak considerably less, and will more aggressively release memory as tabs are closed. Naturally such must be taken with a grain of salt, but I will say that memory usage is noticibly less on both my G5 and my iBook. In typical usage on the iBook, comparing 6 versus 7, 7 seems to use about 25% less memory, and the system is able to reclaim it more easily.
Our problem, however, is it appears we are dramatically underestimating the PowerPC's JavaScript stack demands. Longtime TenFourFox veterans will recall several bugs that in succeeding order jack up the stack ceiling more and more, and in this version we jump from 64MB of stack to 256MB of stack (repairing issue 85). This is unfortunately unavoidable because the PowerPC ABI requires us to save registers to the stack on function calls and the PPC has a massive number of registers. As OS X has a hard cap limit we must ask for this cap in advance, and the original limits we asked for were too small because our stack frames are so much larger, causing it to crash out on certain scripts. This means in the worst case the browser may require a minimum of 256MB of RAM just for the stack, let alone the app or the rest of the OS. For this reason, starting with 7.0, the minimum system requirements will be for 512MB of physical memory. Systems with 256MB of RAM will no longer be supported. Every Power Mac we support in TenFourFox is capable of at least that much; even my Outrigger beige Power Mac 7300 has a gig, and my blueberry iBook G3 has 576MB. The recommended minimum will now move to 768MB. Fortunately, thanks to the other improvements, you'll be able to do more with the rest of your memory, and the 256MB is only a peak possibility, not a persistent requirement. So do yourself and your Mac a favour (RAM is dirt cheap these days) and max out your memory now.
A few of you will be wondering about that cryptic title, and that's the other thing that we need to mention: YARR sucks. Mozilla is expanding their JIT to JavaScript regular expressions using WebKit's YARR library. YARR originally used the Perl-Compatible Regular Expression library (or at least their heavily hacked version of it) as the interpreter fallback for when a JIT was not available, and since we don't (yet) have support for methodjit or the Nitro assembler on PowerPC, we used PCRE for regexp evaluation. In 7.0 Mozilla "upgraded" YARR to a version that now uses its own interpreter as the fallback instead of PCRE. All of their shipping platforms use the JIT, which to be sure, is very quick.
We knew about this going in and several of Tobias' patches were to fix the JavaScript core to deal with the situation where the YARR JIT was not enabled. When I got this together and ran it through Dromaeo for conformance testing, however, I was shocked to see the G5 drop from 110+ runs/sec (in 6) to a dismal 65. All of this regression was paid on the regular expression part of the benchmark. When I hacked PCRE back into the JSRegExp portion of the library, the number went back to the old figure. While WebKit admits benignly that YARR's interpreter is "slower" than PCRE, frankly we really take it in the shorts with YARR and so will any other tier-3 platform that doesn't yet have methodjit/macro assembler support. I filed this with Mozilla as bug 684559 so they can ignore it, but we are shipping with PCRE back because we can't afford a hit like that. Eventually we will have methodjit and we can play in the full JIT party too, but that won't be for a couple cycles yet.
Specific to us, because of my continuing downtime (AT&T is coming out to look at installing a second NID this week for my T1), there has not been any new TenFourFox-specific features in 7 other than updating Sluggo for the new Apple CEO. However, as mentioned, issue 85 is repaired, and a 10.5 specific bug with dropdowns (issue 72) has a putative fix. This fix is limited to 10.5; if you are one of those affected by that bug, please let me know if triggering dropdowns actually crashes the browser instead, because this would imply that my theory is incorrect (i.e., that issue 9 should only be worked around on 10.4). 10.4 is not affected by this issue. This version does not fix issue 84, the table spacing issue; although we have test cases, we haven't narrowed it down to the exact Mozilla patch that provoked the issue and I don't want to wreck my one working 6 repo until I don't need it anymore since none of my ad-hoc offline repos have history. As this bug is a simple nuisance, occurs only on certain sites and the sites in question are otherwise useable, we're shipping with this bug for now.
Soon we will need to turn our efforts to methodjit so that we can keep pace with Mozilla's improvements to JavaScript. If you know PowerPC assembly language and want to help, we can always use more coders.
I'm also working on a new release of the TenFourFox QuickTime Enabler. Watch for it in the coming week or two.
In news from the Mountain View mothership, Mozilla is planning a chemspill for their chemspill, viz., a Firefox 6.0.2. This version "fixes the fix" for DigiNotar, which seems to have caused some collateral damage, but their fix-fix is similarly controversial. I am not planning to generate a 6.0.2 as 6.0.1 will fail safe and I'm not convinced there won't be more changes in the pipeline before 7 emerges. If you are affected by the changes in 6.0.1, you could always use this beta, of course. :) However, if there is a large demand for it, I will consider releasing it as well.
For now, read the 7.0 beta release notes, and grab for your architecture:
Also new in 7 is the beginnings of a new HTML5 canvas backend (Azure, which will eventually take over the entire rendering pipeline; fortunately for us, the CoreGraphics version is likely to work and even if it doesn't there's still Cairo), improvements to Sync, a new Telemetry module for reporting performance back to Mozilla (we don't track this information ourselves, but if you want to remind Mozilla that PowerPC lives, go for it :), a new API for sites to determine load times and adjust themselves to slower systems, and CSS3 ellipsis support.
Oh, and it takes http:// out of the menu bar. Strangely, I'm not as offended by this as I thought I would be, but I'm not wild about it. gopher:// does still appear, though, and so does https://, so I guess that's all that matters. :D
So, yeah, about that "memory footprint" thing. Firefox 7 is being touted as the first product of Mozilla's MemShrink project, bragging numbers that reduce its overall memory usage by 20-50%, will leak considerably less, and will more aggressively release memory as tabs are closed. Naturally such must be taken with a grain of salt, but I will say that memory usage is noticibly less on both my G5 and my iBook. In typical usage on the iBook, comparing 6 versus 7, 7 seems to use about 25% less memory, and the system is able to reclaim it more easily.
Our problem, however, is it appears we are dramatically underestimating the PowerPC's JavaScript stack demands. Longtime TenFourFox veterans will recall several bugs that in succeeding order jack up the stack ceiling more and more, and in this version we jump from 64MB of stack to 256MB of stack (repairing issue 85). This is unfortunately unavoidable because the PowerPC ABI requires us to save registers to the stack on function calls and the PPC has a massive number of registers. As OS X has a hard cap limit we must ask for this cap in advance, and the original limits we asked for were too small because our stack frames are so much larger, causing it to crash out on certain scripts. This means in the worst case the browser may require a minimum of 256MB of RAM just for the stack, let alone the app or the rest of the OS. For this reason, starting with 7.0, the minimum system requirements will be for 512MB of physical memory. Systems with 256MB of RAM will no longer be supported. Every Power Mac we support in TenFourFox is capable of at least that much; even my Outrigger beige Power Mac 7300 has a gig, and my blueberry iBook G3 has 576MB. The recommended minimum will now move to 768MB. Fortunately, thanks to the other improvements, you'll be able to do more with the rest of your memory, and the 256MB is only a peak possibility, not a persistent requirement. So do yourself and your Mac a favour (RAM is dirt cheap these days) and max out your memory now.
A few of you will be wondering about that cryptic title, and that's the other thing that we need to mention: YARR sucks. Mozilla is expanding their JIT to JavaScript regular expressions using WebKit's YARR library. YARR originally used the Perl-Compatible Regular Expression library (or at least their heavily hacked version of it) as the interpreter fallback for when a JIT was not available, and since we don't (yet) have support for methodjit or the Nitro assembler on PowerPC, we used PCRE for regexp evaluation. In 7.0 Mozilla "upgraded" YARR to a version that now uses its own interpreter as the fallback instead of PCRE. All of their shipping platforms use the JIT, which to be sure, is very quick.
We knew about this going in and several of Tobias' patches were to fix the JavaScript core to deal with the situation where the YARR JIT was not enabled. When I got this together and ran it through Dromaeo for conformance testing, however, I was shocked to see the G5 drop from 110+ runs/sec (in 6) to a dismal 65. All of this regression was paid on the regular expression part of the benchmark. When I hacked PCRE back into the JSRegExp portion of the library, the number went back to the old figure. While WebKit admits benignly that YARR's interpreter is "slower" than PCRE, frankly we really take it in the shorts with YARR and so will any other tier-3 platform that doesn't yet have methodjit/macro assembler support. I filed this with Mozilla as bug 684559 so they can ignore it, but we are shipping with PCRE back because we can't afford a hit like that. Eventually we will have methodjit and we can play in the full JIT party too, but that won't be for a couple cycles yet.
Specific to us, because of my continuing downtime (AT&T is coming out to look at installing a second NID this week for my T1), there has not been any new TenFourFox-specific features in 7 other than updating Sluggo for the new Apple CEO. However, as mentioned, issue 85 is repaired, and a 10.5 specific bug with dropdowns (issue 72) has a putative fix. This fix is limited to 10.5; if you are one of those affected by that bug, please let me know if triggering dropdowns actually crashes the browser instead, because this would imply that my theory is incorrect (i.e., that issue 9 should only be worked around on 10.4). 10.4 is not affected by this issue. This version does not fix issue 84, the table spacing issue; although we have test cases, we haven't narrowed it down to the exact Mozilla patch that provoked the issue and I don't want to wreck my one working 6 repo until I don't need it anymore since none of my ad-hoc offline repos have history. As this bug is a simple nuisance, occurs only on certain sites and the sites in question are otherwise useable, we're shipping with this bug for now.
Soon we will need to turn our efforts to methodjit so that we can keep pace with Mozilla's improvements to JavaScript. If you know PowerPC assembly language and want to help, we can always use more coders.
I'm also working on a new release of the TenFourFox QuickTime Enabler. Watch for it in the coming week or two.
In news from the Mountain View mothership, Mozilla is planning a chemspill for their chemspill, viz., a Firefox 6.0.2. This version "fixes the fix" for DigiNotar, which seems to have caused some collateral damage, but their fix-fix is similarly controversial. I am not planning to generate a 6.0.2 as 6.0.1 will fail safe and I'm not convinced there won't be more changes in the pipeline before 7 emerges. If you are affected by the changes in 6.0.1, you could always use this beta, of course. :) However, if there is a large demand for it, I will consider releasing it as well.
For now, read the 7.0 beta release notes, and grab for your architecture:
Wednesday, August 31, 2011
6.0.1 now available
6.0.1 is now available. As mentioned in the previous blog entry, this repairs the issue with fraudulent SSL certificates released by DigiNotar. Please note that all previous versions of TenFourFox are vulnerable to these certificates, so you are strongly urged to upgrade. There are no other changes to this version, and as such, there is no new changeset pack for builders (the old 6.0 one continues to apply to the current release repository). Read the release notes, then grab for your architecture:
Tuesday, August 30, 2011
6.0.1 chemspill imminent
Mozilla has decided to release a 6.0.1 chemspill due to a nasty issue with more fraudulent SSL certificates being issued through a compromised certificate authority (DigiNotar). Unlike the earlier issue that brought us 4.0s back in the day, this one actually requires the entire root certificate to be withdrawn because it is believed that the CA is completely pwned (rather than just a matter of blacklisting a few rogue certs). These malicious certificates are believed to already be in the wild, and there's apparently quite a few as Google Chrome's bad certificate count is up by 247! Mozilla is tracking the issue as bug 682927, but it is currently sec-locked pending release.
Obviously this is a serious enough compromise that we will also be issuing a 6.0.1 which is being built on the G5 as you read this. (Classilla users, this fix will be ported to 9.2.3 when I can get the G4 MDD system back online; unfortunately Classilla development is stalled entirely until my connectivity is restored.) I plan to have 6.0.1 available either tomorrow or Thursday. Although issue 85 has a fix, I do not plan to have it ride along with this release because it may increase memory pressure on marginal systems. More about that when the 7 beta emerges, which I plan to work on as soon as Mozilla certifies beta 3 (probably this week also).
Obviously this is a serious enough compromise that we will also be issuing a 6.0.1 which is being built on the G5 as you read this. (Classilla users, this fix will be ported to 9.2.3 when I can get the G4 MDD system back online; unfortunately Classilla development is stalled entirely until my connectivity is restored.) I plan to have 6.0.1 available either tomorrow or Thursday. Although issue 85 has a fix, I do not plan to have it ride along with this release because it may increase memory pressure on marginal systems. More about that when the 7 beta emerges, which I plan to work on as soon as Mozilla certifies beta 3 (probably this week also).
Tuesday, August 23, 2011
Decisions on 7.0
6.0r is mostly a success, with the majority of users pretty happy with the improvements. We do finally have a reduced test case for issue 84 (the table rendering problem which was reported by some users), but I don't have a cause for it yet since my debugging was limited to what I could do pretending to buy stuff at Starbucks and hiding in the back leeching off the WiFi. With this smaller and fully independent test case I hope to be able to do a more work to that end on the debugging G5. I'm also thinking about grabbing 5.0.1 and making a internal-only build to see if the bug was there too.
On the Floodgap connectivity front, AT&T should hopefully have the T1's NID in by the end of this week, if DSL Extreme's rollout schedule is in any way accurate. Then it's just a matter of running the line into the server room and getting the CSU/DSU up, and we should be good.
Once the T1 is in and we're back in business, I intend to start on Fx7 immediately, which as I mentioned earlier is mostly done already due to Tobias' hard advance work. If it's not, then we might try the emergency repo trick again that we used for 6.0 final, but I'm really nervous about a beta that's going to have no testing at all except for what Tobias himself has done, and I won't have full Mercurial history for debugging. Either way, I intend to deal with this no later than the end of the month. I am hoping to land a few riskier fixes such as a putative fix for issue 72, and put issue 78 to rest at the same time; I also have an idea to deal with user reports of intermittent and inconsistent JavaScript-related crashes, but naturally such bugs intrinsically lack stable test cases and the fix is a bit drastic, so I haven't decided if I'm going to try it or not. (I do have the fix written up, but without a test case, I have no idea if it actually accomplishes what I think it does.)
On the Floodgap connectivity front, AT&T should hopefully have the T1's NID in by the end of this week, if DSL Extreme's rollout schedule is in any way accurate. Then it's just a matter of running the line into the server room and getting the CSU/DSU up, and we should be good.
Once the T1 is in and we're back in business, I intend to start on Fx7 immediately, which as I mentioned earlier is mostly done already due to Tobias' hard advance work. If it's not, then we might try the emergency repo trick again that we used for 6.0 final, but I'm really nervous about a beta that's going to have no testing at all except for what Tobias himself has done, and I won't have full Mercurial history for debugging. Either way, I intend to deal with this no later than the end of the month. I am hoping to land a few riskier fixes such as a putative fix for issue 72, and put issue 78 to rest at the same time; I also have an idea to deal with user reports of intermittent and inconsistent JavaScript-related crashes, but naturally such bugs intrinsically lack stable test cases and the fix is a bit drastic, so I haven't decided if I'm going to try it or not. (I do have the fix written up, but without a test case, I have no idea if it actually accomplishes what I think it does.)
Tuesday, August 16, 2011
6.0r available
Thanks to you sharp-eyed people, issues 81 and 82 have been repaired in TenFourFox 6 (that means printing and print preview should now work correctly again in 10.4, and progress bars shouldn't shimmy around in 10.5), and the fixes are now spun out as 6.0r. I really appreciate everyone's patience with the server downtime and the delay in getting this out, but we've still met the release date, and we're still at source parity with Firefox 6!
To reiterate for people new to this blog, since this is now the "update channel" until I get Floodgap and my business line up again (I just signed a T1 contract with DSL Extreme today, so let's hope that works out), this is the intended final version of TenFourFox 6.0. If you are still using the 6.0 release candidate that came out on Saturday, please download and replace it with 6.0r. The version will still be 6.0, but about: should show a build ID of 20110815. Since there are no other showstoppers, this will replace 5.0, and there will be no subsequent 5.0 or 4.0 releases.
As one more reminder, plugins are disabled by default, and are no longer supported. If you are new to this policy, refer to previous entries in this blog, or see this wiki entry on plugin support.
For builders, there is a new changeset pack up to apply to mozilla-release with the issue 81 and 82 fixes in it.
Please read the revised release notes, and then download the version for your architecture:
To reiterate for people new to this blog, since this is now the "update channel" until I get Floodgap and my business line up again (I just signed a T1 contract with DSL Extreme today, so let's hope that works out), this is the intended final version of TenFourFox 6.0. If you are still using the 6.0 release candidate that came out on Saturday, please download and replace it with 6.0r. The version will still be 6.0, but about: should show a build ID of 20110815. Since there are no other showstoppers, this will replace 5.0, and there will be no subsequent 5.0 or 4.0 releases.
As one more reminder, plugins are disabled by default, and are no longer supported. If you are new to this policy, refer to previous entries in this blog, or see this wiki entry on plugin support.
For builders, there is a new changeset pack up to apply to mozilla-release with the issue 81 and 82 fixes in it.
Please read the revised release notes, and then download the version for your architecture:
Subscribe to:
Posts (Atom)