Sunday, January 6, 2013

17.0.2 RC available and that Turkdistrust thing

The build process for 17.0.2 was an unmitigated disaster all the way around, including a serious bug I introduced in one of the local patches and then a flubbed copy around 1am this morning which I discovered later had tanked the G5 and 7450 builds. Usually I have the RCs out on the Saturday prior to the Tuesday release day, but it just didn't work out that way this time around. Anyway, you can now get them from the Downloads tab and check out the release notes. This will go out on time Monday evening as usual.

This version fixes Safari bookmark importing (a Mozilla bug not uplifted to ESR), tracked as issue 194, and also revamps font scanning (issue 195). Previously, users with large numbers of fonts could have a pause of 10-20 seconds or more when the browser's character map cache was invalidated and a page with non-Latin characters was being processed (it was almost instant after the cache was filled, fortunately, but the cache is routinely invalidated in case new fonts have been loaded). Mozilla's old ATS code was actually pulling a whole font table off disk every time just to see if that table even existed (and then throwing it away!); they've moved on to CoreText-only support now that they only support 10.6 and ATS is deprecated, so they never fixed the inefficiency. So, this version loads the font table directory only and caches it, so that queries hit the directory cached in memory and this change speeds up font enumeration by about four times. Large font systems will still have a delay, but it will be much less. There is also a wallpaper fix in for malware URL validation, another Mozilla bug (tracked as issue 197).

Among the security updates in this release, it is worth mentioning the Turktrust intermediate certificate issue, which is also fixed for Classilla users as part of 9.3.2 which I released today. Intermediate and subordinate certificates have been at the heart of some of our worst SSL certificate debacles in recent memory because they explicitly delegate signing authority from a root CA to a third party that may be entirely untrustworthy. Worse, you will never be warned certificates signed by such an intermediate were not issued by a root because their trust chain directly connects them to the root from which the intermediate comes. After the DigiNotar and Comodo disasters, we've already made it clear what to do with certificate authorities who maintain inadequate security and let attackers freely generate these malicious subordinates: kill them with fire, castrate them, and subject them to Vogon poetry (oh yes, and forever tar those intermediates and the ultimately tainted root certificates as untrusted). However, Turktrust is different: the intermediate certificates seem to have been released out of what looks like sheer incompetency, and one of those intermediates was already used to construct a man-in-the-middle certificate for Google for an internal firewall in a Turkish governmental agency.

The argument is whether this merits the same kind of punishment that technical and security failure does, and my assertion is, unequivocally, yes. Administrative incompetence has the same damaging outcome as technical incompetence, viz., the further erosion of trust in the security of SSL and the risk of impersonation, and CAs with faulty internal practice should be just as subject to browser revocation and removal of their root as those who screw up technically. There can be no room for error when people's banking, money, identity and livelihoods are at stake, and the only way to make CAs participate in quality improvement is to make the penalty of failure severe, particularly if the CA already does not have a QI process (in fairness to Turktrust, they did self report the issue when it was internally discovered). Unfortunately, this won't happen that time either. Google, Mozilla and Microsoft have only rejected the particular root used to sign the intermediates, though Google also removed Turktrust from their EV certificates as an additional punishment, but as far as I'm concerned they should be completely excised. To maintain parity with Firefox, however, I have grudgingly decided to keep their other roots in for the moment while discussion about the larger problem of rogue intermediates goes on in the background.

Once 19 migrates to beta, I will apply the 19 changesets there and there will be a 19 beta. There will also need to be a new QTE based on a different jetpack due to internal changes between 17 and 19, though I will try to keep one QTE that works on both versions if possible. Hopefully I should release 19b1 sometime next week.

12 comments:

  1. It's off-topic to your post, but I wanted to stop by and say "thank you."

    TenFourFox is very appreciated. It allows me to use my iMac G5 as my daily computer, with no impact on productivity. Especially as my work moves more and more online, I spend 80% of my time in EverNote and WordPress. With TenFourFox, this is reliable and speedy.

    You are doing a great service, and that deserves to be recognized.

    ReplyDelete
  2. Seconded! (Different apps/sites, same impact.)

    ReplyDelete
  3. Is TFF 19 beta much faster than 17? Will it be worth upgrading?

    ReplyDelete
  4. Thanks, Dave and Raven!

    niu, it's not so much "faster" as it is "smoother." I'll talk about that when the beta is available. However, I do definitely think it is an improvement on 17.

    ReplyDelete
  5. "Once 19 migrates to beta, I will apply the 19 changesets there and there will be a 19 beta."

    PC World, 1/11/2013: Firefox 19 enters beta with a native PDF viewer and extra ARMv6 support

    (...holding...breath...painfully...)

    ReplyDelete
  6. The builds are mostly done, the G3 one is building now, and I'm trying to fix the QTE while that grinds away in the background. Hopefully up tomorrow or Monday.

    However, since you asked, I turned off the PDF viewer -- on the G5 it is tolerable (usually), but it chugs on the G4s. You can turn it back on if you want, but I bet you'll turn it back off.

    ReplyDelete
  7. While I can already live with the slower speed in pdf.js (which should be improved in 19) on my G4 1.33 GHz, the font handling leaves to be desired. If the pdf uses a special font that's not installed locally, it should be embedded, but if it isn't, pdf.js shows garbage or colliding letters. Acrobat Reader or Preview use substitute fonts in these cases that have flexible spacing so the letters don't run into each other. I'm sure however, now that pdf.js is officially enabled in FF19, it will receive more feedback and attention so that speed and font issues will improve in future versions.

    ReplyDelete
  8. Can't pdf.js be taught the same substitute-font trick as Preview?

    (I ask, ignorantly.)

    QTE is a null issue for me at the moment. For reasons unknown, neither QuickTime nor iTunes have been functioning on my G4 7400 400-MHz 1-GB-SDRAM Powerbook; I'll have to take it in to a pro, because I've done reinstalls without effect, and I'm out of ideas. For all I can guess, something else I installed or upgraded undercut them.

    ReplyDelete
  9. Thanks for your hard work guys....I've just updated my G3 iMac from 10ESR to 17.0.2 and it's noticeably faster.

    I was worried back when I upgraded from version 8 to 9 because there was a slowdown and I wondered how long it would be before I would have to throw in the towel and accept this old machine couldn't cut it anymore. But things have taken a pleasant turn for the better :-)

    ReplyDelete
  10. 17 is a lot faster than 10, but 19 is shaping up to be faster still though there are still some lurking bugs in it due to the DLBI switch (see most recent blog entry). Once these are fixed, I expect the next ESR to be even better than 17, assuming there is one.

    ReplyDelete
  11. 17.0.2 has been running fine on a dual core 2Ghz G5 w/10.5.8 since Jan 6. In the last few days I've been getting the update pop-up window that I should upgrade to 17.0.2 ??
    When manually checking for updates I get the No Updates Found message. Other than that, every thing seems to be fine.

    ReplyDelete
    Replies
    1. I haven't received any other complaints, but it's easy enough to check. The build ID for G5 17.0.2 should be 20130106013549 (you can see the build ID by going to about:config and typing buildid {no spaces} into the search box). If you see something else, please advise.

      Delete

Due to an increased frequency of spam, comments are now subject to moderation.