Those reading earlier entries will notice I was puzzling over two strange commits attached to a (then) sec-locked bug that forced an RC2 and appeared limited in scope. They were indeed limited in scope, but to deal with a problem that has now become public; namely, a certificate authority had credentials stolen enabling an Iranian-based attacker to sign multiple bogus certs. At least one, and possibly more, escaped.
This is one of those cases where I question why something where the exploit was, technically, already in the wild was not publicly disclosed and I would have probably held the release for it at the time.
It is now unclear exactly how much of an impact this bug has because everyone knows about the bogus certs that got released and they are already revoked at the OCSP level. Still, there is the possibility they could be used for nefarious purposes under certain circumstances and I will be releasing a "4.0s" later today with display-version 4.0 but updated build-IDs incorporating this fix. This will coincide with 3.6.16 nicely in any case. For Classilla users who follow this blog, this will be part of Classilla 9.2.2 as well.
Since I'm forcing a re-release, this will also include the more targeted fix for issue 37 which I am pretty sure is secure and stable. That should make all you JavaScript performance gearheads happy again. It will not include the AltiVec WebM accelerator; that bug is snowballing a bit and I want it to have beta coverage. You should expect these builds sometime this evening Pacific time and the G5 is already cranking them out as you read this. (UPDATE 9:10pm: Updates are now available. There will not be a separate changeset pack as, with the exception of the one-liner for issue 37, it is exactly the same and the security issue is in the Mozilla branch.)
Thursday, March 24, 2011
Wednesday, March 23, 2011
Release postmortem and goodies in the next minor release
So while we didn't have anything on Firefox 4's numbers, we had more downloads in 30 hours than we did in a month on any of the individual betas. Not bad!
The change that I landed last-minute due to the crash that cropped up does have a performance impact, but some users are seeing a hit significantly worse than my measurements. I'll talk about that in a minute. If you are one of those users, and you weren't crashing in b12, you could revert to that temporarily pending followup. Note that you will get pestered to update unless you turn that off too.
I should also use this spot to state, since it was a big concern to people in the previous entry, that plugins will have glitches. The code holding it together is kludgy at best and will eventually not work, because these plugins are no longer updated for PPC, and I don't know what the changes occurring in "Firefox 5" will do either. Right now most of the glitches are limited to scrolling artifacts. I have always suggested installing an add-on such as Flashblock, which is what I do myself, and then you can enable only the Flash applets you actually need to see. Remember, plugins will be pref'ed off by default in the next major release due to imminent security and compatibility issues.
Which brings us to the next minor release. While Mozilla is hemming and hawing about how they will set up their new rapid release schedule, and I will of course have commentary on that when they're done, we're going to continue our development on this branch. The first and most important thing will be to find a faster fix for the crashed-out JavaScript issue 37 that does not hit performance as badly (preferably at all), but the second will be to get AltiVec acceleration into WebM playback. WebM actually, believe it or not, already has this code, but Mozilla is not using it. What we'll be doing is transplanting some more of the WebM accelerated source into the tree, then modifying the Mozilla build system to properly integrate the VMX accelerator code. Note that this will not require AltiVec: G3 users can still play WebM video, just with the non-AltiVec generic C decoder that is already in use. However, G4 and G5 owners should see a boost in performance; how much I don't exactly know yet, and we might need to translate some more of it manually. We'll start with that however.
Because both of these changes are a little risky, there will be a single minor beta (I think there's a Jonathan Coulton song by that title :P ) incorporating both new updates. I hope to have that out to play with in a couple of weeks. You will not be automatically updated to it -- watch this space for more.
The good news is that other than the known issues and the JavaScript performance question, there have been no major problems with the rollout. So job well done. More work ahead.
The change that I landed last-minute due to the crash that cropped up does have a performance impact, but some users are seeing a hit significantly worse than my measurements. I'll talk about that in a minute. If you are one of those users, and you weren't crashing in b12, you could revert to that temporarily pending followup. Note that you will get pestered to update unless you turn that off too.
I should also use this spot to state, since it was a big concern to people in the previous entry, that plugins will have glitches. The code holding it together is kludgy at best and will eventually not work, because these plugins are no longer updated for PPC, and I don't know what the changes occurring in "Firefox 5" will do either. Right now most of the glitches are limited to scrolling artifacts. I have always suggested installing an add-on such as Flashblock, which is what I do myself, and then you can enable only the Flash applets you actually need to see. Remember, plugins will be pref'ed off by default in the next major release due to imminent security and compatibility issues.
Which brings us to the next minor release. While Mozilla is hemming and hawing about how they will set up their new rapid release schedule, and I will of course have commentary on that when they're done, we're going to continue our development on this branch. The first and most important thing will be to find a faster fix for the crashed-out JavaScript issue 37 that does not hit performance as badly (preferably at all), but the second will be to get AltiVec acceleration into WebM playback. WebM actually, believe it or not, already has this code, but Mozilla is not using it. What we'll be doing is transplanting some more of the WebM accelerated source into the tree, then modifying the Mozilla build system to properly integrate the VMX accelerator code. Note that this will not require AltiVec: G3 users can still play WebM video, just with the non-AltiVec generic C decoder that is already in use. However, G4 and G5 owners should see a boost in performance; how much I don't exactly know yet, and we might need to translate some more of it manually. We'll start with that however.
Because both of these changes are a little risky, there will be a single minor beta (I think there's a Jonathan Coulton song by that title :P ) incorporating both new updates. I hope to have that out to play with in a couple of weeks. You will not be automatically updated to it -- watch this space for more.
The good news is that other than the known issues and the JavaScript performance question, there have been no major problems with the rollout. So job well done. More work ahead.
Tuesday, March 22, 2011
Chemspill on 4.0 final
Due to a late-breaking issue with the JavaScript accelerator, revised versions of 4.0 are now available. Note the version is the same, so if you downloaded TenFourFox earlier today or yesterday, you may need to grab it again. I apologize for the inconvenience. This version is about 10-15% slower than before, but is much more stable, and of course is still by far the fastest JavaScript on PowerPC.
Sunday, March 20, 2011
TenFourfox 4.0 final released!
Since we don't get the official Firefox 4, I figured, why wait for the official release date? So go get it. This release fixes a subtle but nasty crash glitch in the JavaScript accelerator, fixes some more Command-shortcuts once and for all, and should also resolve trouble with window stacking. I've been using it myself on my G5 and iBook G4 for the last week and it's great. You'll love it too.
I should add one note about the build: before I left for my mini-vacation, Mozilla had been planning to make RC1 into 4.0 final, and I left the G5 buildhost to chug out the various architectures while I gallivanted around the coast. Mozilla then made a quick late-breaking announcement and popped out an RC2 with these fixes for bug 642395. Don't bother trying to look at the bug as it's sec-locked and I'm not part of the Mozilla security group either; just look at the diffs. It appears these changes are to temporarily blacklist certain certificates issued by Usertrust and I don't know why yet despite some cursory snooping around. The nature of the fix suggests this is temporary and of limited import, so rather than invalidating a whole lot of build work which has already been certified, I have elected to push out TenFourFox final relative to RC1 (those marked changes are the only difference between RC2 and RC1) unless I discover that the issue in question is more severe. If these patches are still in the tree by the time the next maintenance security/stability release comes due, then they will become part of TenFourFox also.
Which brings us to our next point: will there be point releases for Firefox 4? Signs point to yes. This is very good news, because I am hoping that Cairo 1.10 lands on mozilla-2.0 and helps our software rendering performance (see issue 7). If nothing else, it keeps us stabilized until we must do battle with Firefox 5. That will be the subject of a post to be made in the very near future.
For builders who want to build on this new stable (ho ho ho) basis, there are now new build instructions and the changesets for 4.0 final are relative to mozilla-2.0, not mozilla-central (although necessarily they would probably still largely apply there too). You probably want to clone mozilla-2.0 separately if you want to make your own builds off that stable branch and use those changesets. New changesets for "Firefox 5" are a totally separate topic, but assuming that we make the jump to Fx5 (again, a subject for a post coming soon), I will not be popping out separate beta changesets until Fx5 has itself entered beta -- i.e., no alpha changesets, sorry, unless there is significant demand.
In security news, Adobe Flash is once again being actively attacked. Adobe's advisory implies, but does not state clearly, that a fix will be issued for 10.1 (or PowerPC). This fix is supposed to come out sometime this week. If Adobe does not fix this for PPC, then watch out. Remember, plugins are deprecated in 4.0, and will be pref'ed off in the next major release. Get your Flashblock on now; it works fine with TenFourFox.
Anyway, go grab TenFourFox 4.0 final and make sure to flaunt it in the faces of your weenie Intel Mac-using friends. They'll be oh so jealous. ;)
I should add one note about the build: before I left for my mini-vacation, Mozilla had been planning to make RC1 into 4.0 final, and I left the G5 buildhost to chug out the various architectures while I gallivanted around the coast. Mozilla then made a quick late-breaking announcement and popped out an RC2 with these fixes for bug 642395. Don't bother trying to look at the bug as it's sec-locked and I'm not part of the Mozilla security group either; just look at the diffs. It appears these changes are to temporarily blacklist certain certificates issued by Usertrust and I don't know why yet despite some cursory snooping around. The nature of the fix suggests this is temporary and of limited import, so rather than invalidating a whole lot of build work which has already been certified, I have elected to push out TenFourFox final relative to RC1 (those marked changes are the only difference between RC2 and RC1) unless I discover that the issue in question is more severe. If these patches are still in the tree by the time the next maintenance security/stability release comes due, then they will become part of TenFourFox also.
Which brings us to our next point: will there be point releases for Firefox 4? Signs point to yes. This is very good news, because I am hoping that Cairo 1.10 lands on mozilla-2.0 and helps our software rendering performance (see issue 7). If nothing else, it keeps us stabilized until we must do battle with Firefox 5. That will be the subject of a post to be made in the very near future.
For builders who want to build on this new stable (ho ho ho) basis, there are now new build instructions and the changesets for 4.0 final are relative to mozilla-2.0, not mozilla-central (although necessarily they would probably still largely apply there too). You probably want to clone mozilla-2.0 separately if you want to make your own builds off that stable branch and use those changesets. New changesets for "Firefox 5" are a totally separate topic, but assuming that we make the jump to Fx5 (again, a subject for a post coming soon), I will not be popping out separate beta changesets until Fx5 has itself entered beta -- i.e., no alpha changesets, sorry, unless there is significant demand.
In security news, Adobe Flash is once again being actively attacked. Adobe's advisory implies, but does not state clearly, that a fix will be issued for 10.1 (or PowerPC). This fix is supposed to come out sometime this week. If Adobe does not fix this for PPC, then watch out. Remember, plugins are deprecated in 4.0, and will be pref'ed off in the next major release. Get your Flashblock on now; it works fine with TenFourFox.
Anyway, go grab TenFourFox 4.0 final and make sure to flaunt it in the faces of your weenie Intel Mac-using friends. They'll be oh so jealous. ;)
Monday, March 7, 2011
NecesRC delays and living la vida stable
Mozilla has spun mozilla-2.0 off into its own stable branch to generate the Release Candidates. Congratulations, we made it! Whatever else happens, we are almost certain to continue surviving through future versions of Firefox 4/Mozilla 2, as it is highly unlikely that Mozilla will throw one of our known show-stopper insurmountable technical hurdles into a maintenance branch. (There is an early development hurdle with Firefox 5 which is going to present a problem, but I'll discuss that in due time. Fortunately, I am reasonably confident that this technical requirement can be worked around.)
Now that we are on a stable branch for sure, updates will be handled a little bit differently. Previously I would jump on the tree as soon as it was held for tagging by Release Engineering so that no or very few bugs would land that should not be in the beta release. Since our QA demands are much less than Mozilla's (only two supported OSes and one supported architecture), building, testing and certifying releases usually only took a day or two after that, and so routinely we were popping out betas sometimes as much as a week or more before the official betas would come out. Well, no longer. As I alluded to in the last post, it behooves us to wait as long as possible on a stable branch to make sure everything's on the branch that needs to be there, because the risk of waiting too long and getting an unstable patch in the pull is lower than the risk of jumping on the tree too early and missing a security or stability issue that lands at the last minute.
For that reason, 4.0 final and all subsequent releases off the stable Mozilla 2.0 branch will be released pretty much simultaneously with Mozilla's releases so I can make sure that changesets match. Unfortunately, you can't do this with about:buildconfig because the changeset displayed is based on the internal TenFourFox repo and not Mozilla's, but we can do this internally with a bit of Mercurial magic on the build system. Therefore, don't expect 4.0 final much before the official release day, nor any future 4.x release. We'll still be punctual, just not fashionably early. :)
Builders and our Fink-based audience will be happy to know that when these stable releases go out, they will also be accompanied by new changesets against mozilla-2.0 instead of mozilla-central, as I know the current changesets do not apply completely cleanly to the trunk repo. On a stable branch they should have much fewer variances and therefore ought to apply without much fuzzing. Our internal copy of mozilla-central will also be rebased on this clean changeset too so that everything is consistent. I plan to do this for each new branch in the future so that there will be much less junk metadata getting carried forward.
There are a couple of 10.4Fx-specific bugs that should also be fixed in 4.0 final, none serious showstoppers, but might as well get them in before the end as the changes should be very safe. In fact, I have preliminary fixes in my tree already and have been using the "RC" on my G5 for the past few hours now. Looks good so far; later this week I'll dump a build on the iBook G4 and see how it does with that.
So, champagne and drinks all around: we made it! Firefox 4 is still on the Power Mac and still on Tiger! I have some ideas for more PowerPC-specific optimizations for TenFourFox 5, too, but more on that once we branch.
Now that we are on a stable branch for sure, updates will be handled a little bit differently. Previously I would jump on the tree as soon as it was held for tagging by Release Engineering so that no or very few bugs would land that should not be in the beta release. Since our QA demands are much less than Mozilla's (only two supported OSes and one supported architecture), building, testing and certifying releases usually only took a day or two after that, and so routinely we were popping out betas sometimes as much as a week or more before the official betas would come out. Well, no longer. As I alluded to in the last post, it behooves us to wait as long as possible on a stable branch to make sure everything's on the branch that needs to be there, because the risk of waiting too long and getting an unstable patch in the pull is lower than the risk of jumping on the tree too early and missing a security or stability issue that lands at the last minute.
For that reason, 4.0 final and all subsequent releases off the stable Mozilla 2.0 branch will be released pretty much simultaneously with Mozilla's releases so I can make sure that changesets match. Unfortunately, you can't do this with about:buildconfig because the changeset displayed is based on the internal TenFourFox repo and not Mozilla's, but we can do this internally with a bit of Mercurial magic on the build system. Therefore, don't expect 4.0 final much before the official release day, nor any future 4.x release. We'll still be punctual, just not fashionably early. :)
Builders and our Fink-based audience will be happy to know that when these stable releases go out, they will also be accompanied by new changesets against mozilla-2.0 instead of mozilla-central, as I know the current changesets do not apply completely cleanly to the trunk repo. On a stable branch they should have much fewer variances and therefore ought to apply without much fuzzing. Our internal copy of mozilla-central will also be rebased on this clean changeset too so that everything is consistent. I plan to do this for each new branch in the future so that there will be much less junk metadata getting carried forward.
There are a couple of 10.4Fx-specific bugs that should also be fixed in 4.0 final, none serious showstoppers, but might as well get them in before the end as the changes should be very safe. In fact, I have preliminary fixes in my tree already and have been using the "RC" on my G5 for the past few hours now. Looks good so far; later this week I'll dump a build on the iBook G4 and see how it does with that.
So, champagne and drinks all around: we made it! Firefox 4 is still on the Power Mac and still on Tiger! I have some ideas for more PowerPC-specific optimizations for TenFourFox 5, too, but more on that once we branch.
Subscribe to:
Posts (Atom)