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.