And now for something completely different: Classilla is back

(If you're reading this in Classilla, turn on slow scroll mode or hold down Command as you scroll. I'm still trying to figure out why the browser won't repaint on this blog by itself.)

It is no secret that Classilla has gotten backburnered because of TenFourFox, and to my regret, but there's only one of me. While we have had some substantial code contributors to this project, especially Tobias and Ben but many others, Classilla has only had a couple small patches from outside contributors and none to the core code. That is undoubtedly because it's much harder to get a build running and much harder to work with when you do, but that doesn't change the fact that it's almost entirely been a single nerd effort and this particular nerd has had bigger fish to fry. TenFourFox is the browser I use on my personal systems more than 90% of the time (Classilla and regular Firefox on my token Intel systems takes up the remainder), and I have a rule that I work hardest on the software I actually use myself.

Still, I love the classic Mac OS for its simplicity and its ease of use. Its technical underpinnings and limited multitasking may occasionally be frustrating, and everyone knows that if you push it too hard you'll be forcibly rebooting for your troubles. But there are to this day advantages to the lovely Platinum UI that OS X has not replicated and given its new direction probably never will, including its better human interface consistency, window shading, and true spatial Finder. Lots of applications and great games won't run on anything else, and so Classilla still meets a need for me today on those systems I've dedicated to running OS 9. Plus, I chafed a little bit at that Ars article, since Andrew didn't even try to explore its admittedly unusual features. ;)

So here is Classilla 9.3.3, a long delayed update. It's not the browser I wanted to release; what I wanted to release was a regular security rollup, including fixing a long-standing problem in JavaScript principals, and the partial work on that which did not build required a non-trivial rollback to get it back to compiling. Once that was done, the biggest amount of backlogged complaints received through Report-A-Bug (yes, I do actually read these) was about HTTPS sites that came up with a mysterious error -8182. A quick dive in the source code shows that the closest error base was -8192 (in security/nss/lib/util/secerr.h) and that SEC_ERROR_BAD_SIGNATURE was +10 ... which equals -8182. When the certificates for the offending sites were examined, they were all signed with SHA-256, which is the new certificate standard due to potential weaknesses in current SHA-1 certificates. In fact, by 2017, all three major browsers will no longer regard SHA-1 certificates as trusted and no major website will be using them, so this was critical support to add or at least mitigate.

My first thought was to allow this fatal error to become a non-fatal error that someone could override, similar to forcing acceptance of certificates that were expired or the wrong domain name. In fact, I did implement this (using a different error code so that SHA-1 certs that didn't validate would still fail with a fatal error code), because one day there will be a certificate signing algorithm beyond even the whole of SHA-2. But by 2017, virtually every certificate would fail this test because there would be almost no SHA-1 (let alone MD5) certificates left, meaning certificate verification would essentially not take place for any site. As a future-proofing stopgap, that's one thing, but there must be a better solution in the meantime. How much work would it be to add this support so that Classilla's NSS could actually do the verification?

Interestingly, even though the NSS (Network Security Services) library in Classilla is old, roughly equivalent to 3.7.8 with patches, there was a SHA-2 implementation in its hash algorithm suite that had never been hooked up to anything. In fact, Classilla didn't even have it in its CodeWarrior project files. It compiled and appeared to support everything necessary for a complete SHA-2 implementation (including SHA-256, SHA-384 and SHA-512 variants), so I sat down and noted everywhere that SHA-1 was referenced and duplicated that using the same API. And what the heck -- it worked. Plus, it's a template if SHA-384 or SHA-512 certificates become more common; they can be implemented in exactly the same way. At some point SHA-1 certificate support will also be sunsetted in Classilla, and will be treated as an unknown algorithm, but I will probably not do this until well after the major browsers no longer accept them either.

Server Name Indication was a tougher one. SNI is an extension to the initial TLS handshake that allows virtual hosts on the same server to have different certificates; Mozilla did not support it until Firefox 2.0 (Gecko 1.8.1). Without this support, site hostnames will not appear to match, requiring a fallback to that override dialogue box I'm trying to avoid. Digging through old issues I found a patch in Bugzilla that seemed to fit the bill in a simple sense, but not only did it not work, it made the browser incredibly unstable. NSS can be very byzantine to understand with earlier versions festooned with magic constants and offsets, and one wrong move will upset the entire apple cart. So I pulled that out and tried to hack in some support of my own, but as soon as I turned it on, HTTPS hosts complained my handshake was bad. I had to use openssl on my POWER6 as a dummy server to debug what was going back and forth over the wire until I figured out where my byte offsets were going wrong after a marathon 12 hour hack session. Once this was done, suddenly a great many sites started working even better, to the point where we can ourselves deprecate the flawed SSLv3 in favour of TLSv1 as well (and SSLv2 is now, finally, disabled by default).

I'm not sure how much more I can cram into Classilla NSS. It supports Diffie-Hellman exchange for forward secrecy, but it has absolutely no support for elliptic curve variants (for example, it supports DHE-RSA-AES256-SHA, but not ECDHE), which are more complex but much more performant for a given bit length; implementing this means not only porting over the hashing algorithms but also writing up the TLS hello extension used to negotiate them. Session ticket support is possible, but requires some substantial refactoring under the hood, and there is little payoff given the effort required. TLSv1.1 similarly is possible, but will require a lot of reworking, and many features of TLSv1.2 such as Galois/Counter Mode would have to be implemented from scratch (of terribly questionable utility on a platform where most systems are uniprocessor). However, TLSv1.3, currently in draft, will remove support for non-AEAD ciphers and Classilla's cipher suite is all non-AEAD, so being just short of a complete rewrite it would be nearly impossible to implement it in any reasonable time period. At some point the combination of MD5 and SHA-1 used in TLSv1 will be considered similarly weak, and TLSv1 will also be deprecated, though I don't expect that for some time yet to come. For the next few years even sites that eventually implement TLSv1.3 will still downgrade to TLSv1 and Classilla will still be able to access them. In fact, it is the only classic Mac OS browser now that can.

Compared to those two big updates, the remaining changes are relatively pedestrian. There are some new Byblos stelae for Bing and DuckDuckGo, and Byblos stelae can be stored in Documents:Byblos: so that you can keep the custom ones you write between updates. I fixed issues with custom user agents, wallpapered an annoying layout crash and refreshed user agent strings and SSL certificates. Plus, mail and news is a little faster by not constantly loading an ancient 404 URL from Mozilla (I'm sure their network ops office appreciates the load of thousands of classic Macs being lifted).

For 9.3.4 I intend to return to the security rollup I wanted to complete, and hopefully the hiatus between versions will be much less this time. Layout is still going to be limited, but as Byblos improves I intend to rely more on it to help sites help themselves. If you have a Byblos stele that works well for you, please submit it. I also really want to figure out what the heck is up with this blog layout and scrolling!

Classilla was tested on 9.2.2 on the big 1.8GHz MDD G4, 9.2.2 on my strawberry iMac with a 600MHz Sonnet HARMONi G3, 9.2.2 on my Twentieth Anniversary Macintosh with a 500MHz G3, 9.1 on my 7300+G4/800, 9.1 on my 1400+G3/466 and 8.6 under Rhapsody Blue Box on the Wally G3. Download it now.

It was nice to get the browser and a wonderful classic OS working on the modern web once again, and even though TenFourFox is my priority, I am delighted to say that Classilla is still my joy.

Do not purchase if tamper-evident seal is damaged

Leviathan Security this week managed to catch, red-handed as it were (the malicious server appears to be in Russia and is even named, puckishly, kulak), a Tor exit node actively patching software and modifying it as it came over the wire. Long hypothesized but now finally demonstrated in the wild, this particular node was looking for uncompressed Portable Executable (Windows) binaries and monkeypatching them on their way back to the requester. In fact, it was so active that it gave itself away by trying to patch nearly anything that looked like a Windows application; a smarter node would only patch specific binaries and pass others unmodified, meaning these stealthier malefactors may never be discovered by security researchers even if they do in fact exist.

This applies to unencrypted downloads, of course; assuming no flaws allowing a man-in-the-middle attack, this sort of screwing around would be immediately obvious on a TLS connection. On Google Code, we had encrypted downloads, but Google Code (meanie) no longer allows uploads (scum); SourceForge's mirror network only supports regular HTTP downloads, which are not encrypted (please upvote this ticket if you have an SF account).

Are we high risk? No. You probably have a higher risk of developing Ebola than getting a tainted TenFourFox. It's hard to patch a compressed binary in flight, so it would almost certainly be a complete substitution, it would have to be done on a machine that can build such binaries and it would need to do something interesting on a Power Mac, and given all those preconditions frankly I'm not aware of someone who hates me that much except possibly the cute shop girl at the AT&T store who won't give me her phone number.

Still, I'd like to guard against that possibility, or of any network-imported code over an insecure channel (network snippets, for example, can be loaded into the start page -- which has chrome privileges -- and this should make you suddenly feel very icky and vulnerable). This ties in nicely with a recurring thought I've had of redoing the new tab and start pages so that we're not getting snippets from Mozilla anymore about browser things that don't really apply to us or aren't otherwise compatible. To that end, I think publishing a verifiable hash for all downloads and redoing the new tab (possibly just using a blank one?) and start page for 38ESR will achieve that. We also need to ensure the following:

• It should not require any special software to verify the hash. You should be able to do it with the tools that come with 10.4.11.
• The hash list needs to be secure, or that could be tampered with too.
• The new tab and start pages should not do network loads.

Here's how we'll accomplish that:

• The most secure hash algorithm that comes with Tiger's built-in OpenSSL appears to be RIPEMD-160; it doesn't support SHA-2, or I'd use that. RIPEMD-160 is a less common hash function but to date cryptanalysis has not demonstrated collisions so far with known attack methods (here's some light bathroom reading on that topic). You can verify that the .zip file downloaded properly by simply going into Terminal and typing (this is the actual hash):

  % openssl dgst -ripemd160 TenFourFox7450-31.2.0.app.zip
  RIPEMD160(TenFourFox7450-31.2.0.app.zip)= e6637dff473f68d2b4a4b6b920c70183d8658dea

• While we can't upload to Google Code any more, we can certainly post things. The Google Code project page is secured by SSL -- https://tenfourfox.googlecode.com -- and the hashes will either be listed there or on one of the wiki pages. You can grab the hashes securely before you update, download the file from SourceForge, and check that the hash matches. If it does, you have excellent assurance it has not been tampered with in transit. Hashes will be posted for the changesets too.

• We'll be taking the network and dynamic code out, which as a side benefit will reduce their overhead, and possibly some other minimizing changes. I'll probably still allow the old pages by an about:config switch, though I haven't really plotted how the infrastructure will look either. Just expect this for the next ESR.

Assuming no one finds any glaring holes in this idea, I'll probably implement the hashes for 31.2.0 and the 34 changesets this weekend in my copious spare time. It's just a little bit of extra insurance for our users who may be in more difficult circumstances.

34 up

I'm typing this in 34 beta, finally, after a large merge where Mozilla destroyed almost all of the old Nitro macroassembler framework that was used for JaegerMonkey and YARR way back when. I restored the pieces we still use, hacked them to be independent and modified PPCBC to point to those. That works as well as 33 did, at least, and it still passes tests. The remainder of the build was relatively uninteresting except for some moved files and a crash introduced with printing that I backed out (it's a Windows-specific change in cross-platform code we don't actually need for our old printing API), though I haven't tried to make an opt build.

Mozilla has two big, though probably survivable, changes for 35 and 36. For 35, Mozilla is updating libvpx, a change that historically tended to upset our custom AltiVec VP8 decoding and will undoubtedly need tweaking to reassemble the fragments. For 36, though, Mozilla is merging DOM and content together, a major seismic shift to unify two core portions of Gecko that have been separate components in the source code even going back to the antediluvian Netscape days. Ironically, this second larger change is the least likely to be problematic for us because it's almost all cross-platform code which we don't have many patches in, but it may invalidate some sections of code indirectly.

Either way, I think I'd like to start the process early on these in order to have extra time for the expected additional merge work, so 34 is going to be changesets-only too; I'll do a little more fiddling with it and then upload them this weekend. I may release 35 as an aurora since that will necessarily require opt builds to be done, though I want to start on the port of MIPS-IonMonkey as soon as I'm done with 35 or 36.

Well, it was a good idea at the time

The MP3 idea is shelved for the moment mostly due to bugs in how 31ESR manages media streams (these bugs are also in the regular Firefox, so they're a Mozilla problem). While the MP3 decoder is mostly written and working except for arbitrary seeking which is still problematic and has been disabled for the moment, there are various glitches in streaming music services that make it not ready for 31 (especially on Amazon Music, which is what it was originally written for). These nuisances don't make it unplayable, but they do make it annoying, such as streams failing to time out and requiring full buffering, audio glitches with seeking when tracks switch, and some tracks that fail to play at all. Regular ESR 31.2.0 shows all these problems too, so it's not us, but I can't find a specific fix for these and the proper reworking was probably spread along multiple fixes around Fx33 or Fx34.

Because it mostly works but fails in subtle ways, I will leave it in 31.3 but disabled. To avoid a situation with plugins (this is why we can't have nice things) where people post instructions but don't link back to posts explaining limitations in support, you'll have to find the setting yourself. Seeking doesn't work (except for replaying from the beginning) and there are other bugs which I won't fix in the 31 timeframe, so don't even bother reporting them. No further work will be done on it until we get to 38, assuming we do. If you give these instructions out and you don't remind people of this, I will cut out your intestines with a rusty spoon.

The 34 port hopefully will be done by this weekend and then I need to figure out what to do with it.

Poodles are fine dogs. SSLv3 is not a fine protocol.

For the hat trick, the security researchers who brought you BEAST and CRIME now introduce POODLE, the "Padding Oracle On Downgraded Legacy Encryption" attack. The attack allows an SSLv3 connection to be gradually broken down using a dramatically faster method that coughs up a byte of the session cookie on average one out of 256 tries. Ironically, because the demonstrated attack vector is JavaScript, our JIT makes us more vulnerable to this because we run JavaScript faster.

There is no fixing SSLv3 against this -- it's a fundamental flaw in the protocol that can't be worked around, and while previous weaknesses were mitigated somewhat with cipher changes there's no easy way out this time. Most browser vendors, including Mozilla, are taking this as the last straw and ending support for SSLv3, especially since TLS v1 and its successors have been around so long. Even Classilla supports TLS v1.

What will happen is that starting in Firefox 34, all connections must use TLS v1 or higher, giving servers a six-week cycle to do any necessary upgrades. We will follow suit: if Mozilla does not do this first, we will also set TenFourFox on the corresponding ESR release (31.3) to do the same. If you want to do this early, go into about:config and set security.tls.version.min to 1; if this causes problems with HTTPS sites you visit, switch back and tell them to get with it. Classilla users are advised to disable SSLv2 and SSLv3 in the Preferences window, under Security (leave TLS checked). The next version of Classilla, if and when I get those SSL changes done, will have them defaulted off as well.

34 is about 80% done (slogging through JavaScript), and the MP3-enhanced 31 is now playing substantially more audio files without problems. There is still a critical issue with parsing MP3 metadata and it's still quite crashy, but it's developing pleasingly quickly.

31.2.0 available, and music to your ears

31.2.0 is now official.

Also, now I can make that announcement: tonight, TenFourFox played its first MP3 audio file properly with its own internal decoder in-browser (using a modified version of minimp3, a heavily distilled-down version of ffmpeg's MP3 decoder component). Although Firefox can play MP3s using OS X AudioToolbox, the AudioToolbox in 10.4 does not support MP3, so we had to roll our own implementation. Although the codec is still under patent, it's old and we're non-profit and the code has been part of Linux distros for a long time, so we might be able to sneak by without anyone caring. (I hope I won't regret this.)

This code is not ready for primetime: it can't seek within a stream yet, it asserts all over the place with some MP3 files -- I suspect another lurking endian problem in Mozilla's built-in MP3 frame parser since I've already had to fix one of them to even get this far -- and it crashes if you try to queue up two files, though this is a memory allocator issue with its decoder tables and I have an idea how to fix it. It's also kind of slow, though this is partially because I'm on a debug build, partially because the code is not very optimized, and partially because Mozilla disables bigger buffering with audio-only streams, all of which are solveable.

However, the payoff is now music streaming sites like Amazon Cloud Player will "just work." (Amazon Music complains it needs Flash, but it really doesn't. Disable Flash on an Intel Mac running Firefox and you'll see.) And actually that's what I wrote it for, because now OmniWeb crashes trying to run Amazon Music, which is what I used to use on the G5 in the background. I write code to scratch my itches and the priorities for TenFourFox are decided accordingly. If there is a particular feature you want, I strongly urge you to sit down and write it and submit it. Ahem.

Please note that this doesn't really improve MP4 support; the codec glue is quite different and will have to be hacked in separately. I don't have a timeframe for MPEG-4 support and it is not currently a priority for me because the QTE meets my use cases currently. You, of course, can contribute. Ahem, I say.

The target is 31.4.0, though it will ship disabled in that version, so you'll have to turn it on. If it works well, we'll loosen it for 31.5. However, I still need to get 34 working first, and I still want to complete our IonMonkey implementation. I'm determined to get to 38 before concluding parity.

31.2.0 available

31.2.0 is now available (downloads, release notes). It has no changes other than security updates and stability fixes. However, I made a breakthrough on a long requested feature and it may be possible to introduce this into 31.3 or 31.4 -- we'll see, more later. As usual, it will become live Monday night.

Meanwhile, the patches are down for 34 and I'm about 60% through getting a debug build up, but this weekend I'm taking some time off to enter a pinball tournament. Don't wait up.

And the bash is probably done: 4.3.30

I'm not quite sure if the glitches fixed are exploitable with all the other armour, but 4.3.30 is now available, and should conclude the Shellshock chapter at least this time around. The previous post has been updated, since everyone's still linking to it.

And now for something completely different: bad blocks, bad trip

You've already met thule, my recently resurrected Macintosh IIci running NetBSD. The peril of running something old is that things fail. After I got a new recapped motherboard in it, now the hard disk started throwing a couple bad sectors.

Bad sectors happen; magnetic media occasionally gets glitchy. (I do have a backup, but I like running things until they die, so I'm going to keep this drive running until it don't run no more.) Modern drives can often recruit from a pool of sectors and transparently redirect a write to a bad sector to a good sector, but no hard drive can do this on read if the media is bad, and on a drive this geriatric (a 2GB Quantum Fireball from oh-my-gawd-it's-old) even the former is not a given. We want some way to tell the operating system to never use those sectors again.

Some vintage operating systems do this more or less overtly. For example, my Alpha Micro Eagle 300 has an actual bad block file that tells the operating system hands off these sectors (one wonders what would happen if a bad block occurred in the sectors that actually contain the bad block file). Classic Mac OS doesn't really support this, though tools like Norton Disk Doctor can quietly allocate them out of reach. However, Norton Disk Doctor doesn't understand a NetBSD FFS volume. NetBSD does have a tool called badsect(8) that can take a list of sectors and create bogus file descriptors that fsck_ffs will turn into invalid files soaking up those sectors; similar tools exist on other BSDs and even some Linux distributions. This is a little scary and there's not much documentation on this because there aren't many freaks like me running NetBSD on something this old. So here goes.

The console will tell you the bad sector (either on screen or through dmesg). Here's the actual output thule was spitting out:

sd0(ncrscsi0:0:0):
Check Condition on CDB: 0x28 00 00 32 3d 61 00 00 01 00
    SENSE KEY:  Media Error
   INFO FIELD:  3292513
     ASC/ASCQ:  Unrecovered Read Error

sd0(ncrscsi0:0:0):
Check Condition on CDB: 0x28 00 00 32 3d 62 00 00 01 00
    SENSE KEY:  Media Error
   INFO FIELD:  3292514
     ASC/ASCQ:  Unrecovered Read Error

sd0(ncrscsi0:0:0):
Check Condition on CDB: 0x28 00 00 32 3d 63 00 00 01 00
    SENSE KEY:  Media Error
   INFO FIELD:  3292515
     ASC/ASCQ:  Unrecovered Read Error

Eeewww.

What this means is that relative sectors 3292513-5 inclusive are kaput. I noticed this because the periodic full system backup had started failing on certain files, so I knew which files were bad, and I could restore them from the previous backup. But before I could do that, I wanted to make sure the OS didn't try to reuse the bogus sectors.

First, I rebooted it in single user mode. This is very important; you are tinkering with a live filesystem and run not only the risk of kernel panic but serious data loss if other things are writing to the disk while you are. (Yes, I've panicked systems at least once by cheating on this. Learn from my mistakes.) Next, I ran fsck on the disk and allowed it to remove the wrecked files, generating more media errors in the process. It did so, and instructed me to reboot. But we don't want to do that yet; we still have those sectors to account for.

Now we use badsect. We create a directory /BAD and tell badsect to create the placeholder files for those crashed sectors:

badsect /BAD 3292513 3292514 3292515

BE VERY CAREFUL. There is no going back. If you type the sector wrong, you may only waste a perfectly good unallocated sector, or you may destroy a file mid-stream. Check your typing twice, and then check it again. If you did this right, the sectors will be marked and badsect will tell you do run fsck again. Do so.

This time, fsck will notice the bogus files and ask HOLD BAD BLOCK? The answer is yes. It should ask you each time for each sector. If you correctly reserved all the bad sectors, there should be no more media errors on the console. If the bad sectors were part of the file system, you may have some DUPs to resolve, which you should answer yes as well if it asks.

Now the part that threw me initially: when fsck proceeds to the second phase and checks pathnames, it will (correctly) notice that the files in /BAD point to bad blocks ... and offer to delete them! Do not let it!

DUP/BAD I=277769 OWNER=root MODE=100600
SIZE=1024 MTIME=Oct 7 19:58 2014
FILE=/BAD/3292513

REMOVE?

The answer this time, and for anything in /BAD, is NO -- or you'll remove the linkage to the bad sector, and you'll have to create it all over again. This will be true when you fsck this volume again, and you will, because bad sectors will eventually occur somewhere else.

By the end, after you've allowed fsck to complete all the remaining salvage, you shouldn't see any more media errors on the console. Now reboot and restore the files that were lost, if they were important, and tell your backup script to exclude anything in /BAD.

I'm toying with resurrecting thule a second time, but this time running A/UX. That might be fun.

Blog roll

Nothing new to report on TenFourFox right now -- still working on the patches for 34 -- but two blog posts from the retro-Mac community I wanted to highlight:

Riccardo Mori's rebuttal on doing practical work on classic Macs. If you're reading this blog, you're probably already sympathetic to his view, and since Riccardo is very complimentary to TenFourFox and Classilla my linking to his post is totally, unapologetically and shamelessly self-serving, but I think he hits the main points very well (original article for comparison).

Martin Kukač prepares his G5 for another decade, which is his retrofit of an older G5 useful to those of you trying to maintain your air-cooled DP systems. Fortunately, my quad is already ready to go another nine innings.

And the bash goes on again: 4.3.28

bash 4.3.28 is now available, fixing CVE-2014-7186 and CVE-2014-7187, and this should repair all the known outstanding problems. Since everyone is linking to the original post, I have updated it with the new self-tests and instructions.