31.6.0 available

31.6.0 is available (downloads, release notes, hashes). This includes all the security issues to date, but no specific TenFourFox changes. It becomes final Monday evening Pacific time as usual assuming no critical issues are identified by you, our lovely and wonderful testing audience.

IonPower: phase 5!

Progress! I got IonPower past the point PPCBC ran aground at -- it can now jump in and out of Baseline and Ion code on PowerPC without crashing or asserting. That's already worth celebrating, but as the judge who gave me the restraining order on behalf of Scarlett Johansson remarked, I always have to push it. So I tried our iterative π calculator again and really gave it a workout by forcing 3 million iterations. Just to be totally unfair, I've compared the utterly unoptimized IonPower (in full Ion mode) versus the fully optimized PPCBC (Baseline) in the forthcoming TenFourFox 31.6. Here we go (Quad G5, Highest Performance mode):

% /usr/bin/time /Applications/TenFourFoxG5.app/Contents/MacOS/js --no-ion -e 'var pi=4,top=4,bot=3,minus = true;next(pi,top,bot,minus,3000000);function next(pi,top,bot,minus,num){for(var i=0;i<num;i++){pi += (minus == true)?-(top/bot):(top/bot);minus = \!minus;bot+=2;}print(pi);}'
3.1415929869229293
0.48 real 0.44 user 0.03 sys

% /usr/bin/time ../../../obj-ff-dbg/dist/bin/js --ion-offthread-compile=off -e 'var pi=4,top=4,bot=3,minus = true;next(pi,top,bot,minus,3000000);function next(pi,top,bot,minus,num){for(var i=0;i<num;i++){pi += (minus == true)?-(top/bot):(top/bot);minus = \!minus;bot+=2;}print(pi);}'
3.1415929869229293
0.37 real 0.21 user 0.16 sys

No, that's not a typo. The unoptimized IonPower, even in its primitive state, is 23 percent faster than PPCBC on this test largely due to its superior use of floating point. It gets even wider when we do 30 million iterations:

% /usr/bin/time /Applications/TenFourFoxG5.app/Contents/MacOS/js --no-ion -e 'var pi=4,top=4,bot=3,minus = true;next(pi,top,bot,minus,30000000);function next(pi,top,bot,minus,num){for(var i=0;i<num;i++){pi += (minus == true)?-(top/bot):(top/bot);minus = \!minus;bot+=2;}print(pi);}'
3.1415926869232984
4.20 real 4.15 user 0.03 sys

% /usr/bin/time ../../../obj-ff-dbg/dist/bin/js --ion-offthread-compile=off -e 'var pi=4,top=4,bot=3,minus = true;next(pi,top,bot,minus,30000000);function next(pi,top,bot,minus,num){for(var i=0;i<num;i++){pi += (minus == true)?-(top/bot):(top/bot);minus = \!minus;bot+=2;}print(pi);}'
3.1415926869232984
1.55 real 1.38 user 0.16 sys

That's 63 percent faster. And I'm not even to fun things like leveraging the G5's square root instruction (the G3 and G4 versions will use David Kilbridge's software square root from JaegerMonkey), parallel compilation on the additional cores or even working on some of the low-hanging fruit with branch optimization, and on top of all that IonPower is still running all its debugging code and sanity checks. I think this qualifies as IonPower phase 5 (basic operations), so now the final summit will be getting the test suite to pass in both sequential and parallel modes. When it does, it's time for TenFourFox 38!

By the way, for Ben's amusement, how does it compare to our old, beloved and heavily souped up JaegerMonkey implementation? (17.0.11 was our fastest version here; 19-22 had various gradual degradations in performance due to Mozilla's Ion development screwing around with methodjit.)

% /usr/bin/time /Applications/TenFourFoxG5-17.0.11.app/Contents/MacOS/js -m -n -e 'var pi=4,top=4,bot=3,minus = true;next(pi,top,bot,minus,30000000);function next(pi,top,bot,minus,num){for(var i=0;i<num;i++){pi += (minus == true)?-(top/bot):(top/bot);minus = \!minus;bot+=2;}print(pi);}'
3.1415926869232984
4.15 real 4.11 user 0.02 sys

Yup. I'm that awesome. Now I'm gonna sit back and go play some well-deserved Bioshock Infinite on the Xbox 360 (tri-core PowerPC, thank you very much, and I look forward to cracking the firmware one of these days) while the G5 is finishing the 31.6 release candidates overnight. They should be ready for testing tomorrow, so watch this space.

Pwn2Own this Power Mac (plus: IonPower's time is running out)

All of the mighties fell at this year's Pwn2Own, including Firefox, where clever minds find gaping holes for fun and a small amount of profit (but then it also makes a great resume builder, which may be a more reliable paycheque). The holes last year were quickly patched, and after I determined we were also vulnerable we followed suit. As usual, for this year's naughtiness Mozilla already has patched versions available, including ESR 31.5.3.

However, the two holes used for this year's marvelous and somewhat alarming crack are not exploitable in TenFourFox directly: the SVG navigation fault cannot be effectively used to escalate privileges in TenFourFox's default configuration, and we don't even build the code that uses JavaScript bounds checking. The navigation fault may have other weaponizeable vectors and we do want to roll that fix, but the good news is 31.6 will come out this weekend, so no urgent chemspill is necessary unless I discover some odd way of busting through it between now and then.

I lost about a week of hacking time to one of my occasional bouts of bronchitis, which is pushing IonPower's timing very close to the wire. We need two cycles for 38 to allow localizers to catch up and people to test, and of course somewhere in that timeframe we also have to finish the move from Eric Schmidt is a Poopypants Land Google Code. Over the weekend I got IonPower to pass the test suite in Baseline mode, which is very encouraging, but some of the same problems that doomed PPCBC's Ion work are starting to rear up again.

The biggest problem that recurred is an old one: Ion's allocator is not endian-safe. I get bad indicies off it for stack slots and other in-memory boxed values and all but the simplest scripts either assert deep within Ion's bowels (not our new PowerPC backend) or generate code that is verifiably wrong. Unfortunately, Mozilla doesn't really document Ion's guts anywhere, so I don't know where to start with fixing it, and all the extant Ion backends, even MIPS, are little-endian. Maybe some Mozilla JIT folks are reading and can comment? (See also the post in the JavaScript engine internals group.)

One old problem with bad bailout stack frames, however, is partially solved with IonPower. I say partially because even though the stack frame is sane now, it still crashes, but I have a few ideas about that. However, the acid test is getting Ion code to jump to Baseline, run a bit in Baseline, and then jump back to Ion to finish execution. PPCBC could never manage this without crashing. If IonPower can do no better, there is no point in continuing the porting effort.

Even if this effort runs aground again, that doesn't make IonPower useless. PPCBC may pass the test suite, but some reproducible bugs in Tenderapp indicate that it goes awry in certain extremely-tough-to-debug edge cases, and IonPower (in Baseline mode) does pass the test suite as well now. If I can get IonPower to be as fast or faster than PPCBC even if it can't execute Ion code either, we might ship it anyway as "PPCBC II" in Baseline-only mode to see if it fixes those problems -- I have higher confidence that it will, because it generates much more sane and "correct" output and doesn't rely on the hacks and fragile glue code that PPCBC does in 24 and 31. I have to make this decision sometime mid-April, though, because we're fast approaching EOL for 31.

Also, as of Firefox 38 Mozilla no longer supports gcc 4.6, the compiler which we build with. However, I'm not interested in forcing a compiler change so close to the next ESR, and it appears that we should still be able to get it working on 4.6 with some minor adjustments. That won't be the case for Fx39, if we're even going to bother with that, but fortunately there is a gcc 4.8 in MacPorts and we might even use Sevan's gcc from pkgsrc. Again, the decision to continue will be based on feasibility and how close Electrolysis is to becoming mandatory before 45ESR, which is the next jump after that. For now, TenFourFox 38 is the highest priority.

IonPower now beyond "doesn't suck" stage

Very pleased! IonPower (in Baseline mode) made it through the entire JavaScript JIT test suite tonight (which includes SunSpider and V8 but a lot else besides) without crashing or asserting. It doesn't pass everything yet, so we're not quite to phase 4, but the failures appear to group around some similar areas of code which suggest a common bug, and one of the failures is actually due to that particular test monkeying with JIT options we don't yet support (but will). Getting closer!

TenFourFox 31.6 is on schedule for March 31.

The Final Kiss-Off, starring Google Code

So, we expected this. Starting in August 2015, all Google Code projects (that includes TenFourFox and Classilla) will become read-only, and then inaccessible except in archival format in January 2016 (and completely gone by 2017). We'd already moved downloads to SourceForge because Google Code wouldn't up our downloads quota, so now it's time to finish the transition.

Google Code was a free service and we never paid, so I can't be too angry about it, but it's yet another lesson to never depend on Google for anything you want to last. I would like to take issue with them on one thing, though: in their blog post they claim that "[a]fter profiling non-abusive activity on Google Code, it has become clear to us that the service simply isn’t needed anymore." Well, you morons, what did you think would happen after you stopped allowing new downloads? Did you expect that to cause more people to host with you? Sheesh.

The prior plan will now continue with a target of TenFourFox 38, with a couple changes. We will still be reviewing issues on Google Code to determine their likelihood of completion, and transferring them to SourceForge tickets as appropriate; the rest will be closed. Similarly, only current wikidocs will move -- I won't be moving the entire release notes corpus; that's just ludicrous. However, I'll probably maintain parallel release notes on SourceForge for the remainder of 31 to facilitate the process, and I'll also select a couple historical releases for archiving on SourceForge as well (definitely the first Minefield beta, probably 4.0.3 because it was the last non-XUL build, and probably 17.0.11 because it was the last gcc 4.0.1 build). Everything else will be available while they last, and on July 31st I'll log in and write a juvenile and petty message for the Google admins to see. If you want a specific version or a specific changeset pack, now's the time to archive them.

Classilla will also be making a similar transition, but we have a specific problem in that systems that aren't already running Classilla can't bootstrap or update (i.e., some older browsers can't handle SourceForge, and can't download a copy of the browser). The current solution (short of using another computer) is to get a copy from Google Code, which offers a direct download instead of reflecting through a mirror, but that won't be an option in not too much longer. Instead, I will host an archival copy of Classilla on the Floodgap gopher server -- gopher, of course, because any classic Mac can access it with pretty much any classic Mac browser -- and you can use that to download the newest Classilla from there if you don't have any other option. 9.3.4 will hopefully come out as soon as I'm done with TenFourFox 38. (If you're using Firefox or TenFourFox to read this and you want to explore Gopherspace, install OverbiteFF, also written and maintained by yours truly.)

So, so long, Google Code. You were cool while you lasted, and then Google killed you, because Google is a bunch of poopiepants.

On the IonPower side, we're about 2/3rds passing the test suite, though I'm dealing with a really nasty snarled crash in debug toggled calls that I can't unwind yet (PPCBC passes this test, of course, so it's something about IonPower I haven't figured out). But we're making progress!

SuperFREAK! SuperFREAK! Temptations, sing!

Remember those heady days back when people spelled out W-W-W and H-T-T-P in all their links, and we had to contend with "export only" versions of cryptography because if you let those 1024-bit crypto keys fall into the wrong hands, the terrorists would win? My favourite remnant of those days is this incredibly snide Apple ad where tanks surround the new Power Mac G4, the first personal computer classified by the Pentagon as a munition ("As for Pentium PCs, well ... they're harmless").

Unfortunately, a less amusing remnant of that bygone era has also surfaced in the form of the FREAK attack (see also POODLE, CRIME and BEAST). The idea with export-grade ciphers is that, at the time, those naughty foreign governments would have to make do with encrypting their network traffic using short keylengths that the heroic, not-at-all-dystopian denizens of the NSA could trivially break (which you can translate to mean they're basically broken by design). As a result, virtually no browser today will advertise its support for export-grade ciphers because we're not supposed to be using them anymore after the Feds realized the obvious policy flaw in this approach.

But that doesn't mean they can't use them. And to prove it, the researchers behind FREAK came up with a fuzzing tool that gets in the middle of the secure connection negotiation (which must happen in the clear, in order to negotiate the secure link) and forces the connection to downgrade. Ordinarily you'd realize that something was in the middle because completing the handshaking to get the shared secret between server and client requires a private key, which the malicious intruder doesn't have. But now it has another option: the defective client will accept the downgraded connection with only a 512-bit export-compliant RSA key from the server, trivial to break down with sufficient hardware in this day and age, which the intruder in the middle can also see. The intruder can factor the RSA modulus to recover the decryption key, uses that to decrypt the pre-master secret the client sends back, and, now in possession of the shared secret, can snoop on the connection all it wants (or decrypt stored data it already has). Worse, if the intruder has encrypted data from before and the server never regenerated the RSA key, they can decrypt the previous data as well!

There are two faults here: the server for allowing such a request to downgrade the connection, and the client for accepting deficient keys. One would think that most current servers would not allow this to occur, stopping the attack in practice, and one would be wrong. On the FREAK Attack site (which doubles as a test page), it looks like over a quarter of sites across the IPv4 address space are vulnerable ... including nsa.gov!

What about the client side? Well, that's even worse: currently every Android phone (except if you use Firefox for Android, which I recently switched to because I got tired of Android Chrome crashing all the damn time), every iOS device, and every Mac running Safari or Chrome is vulnerable, along with anything else that ships with a vulnerable version of OpenSSL. Guess what's not? Firefox. Guess what's also not? TenFourFox. NSS does not advertise nor accept export-only keys or ciphers. TenFourFox is not vulnerable to FREAK, nor any current version of Firefox on any platform. Test it yourself.

Classilla is vulnerable in its current configuration. If you go into the settings for security, however, you can disable export-only support and I suggest you do that immediately if you're using Classilla on secure sites. I already intended to disable this for 9.3.4 and now it is guaranteed I will do so.

What about Safari or OmniWeb on Power Macs? I would be interested to hear from 10.5 users, but the test site doesn't work correctly in either browser on 10.4. Unfortunately, because all Macs (including 10.6 through 10.10) are known to be vulnerable, I must assume that both Tiger and Leopard are also vulnerable because they ship a known-defective version of OpenSSL. Installing Leopard WebKit fixes many issues and security problems but does not fix this problem, because it deals with site display and not secure connections: the browser still relies on NSURL and other components which use the compromised SSL library. I would strongly recommend against using a non-Mozilla browser on 10.7 and earlier for secure sites in the future for this reason. If you use Android as I do, it's a great time to move to Firefox for Android. Choice isn't just a "nice thing to have" sometimes.