[pkg] Layout features inactive on Windows without DSIG table

[Paul Sladen]

Signed .ttf files are based on the hash of the whole font minus 'DSIG' table and with a zeroed checksum. The 'DSIG' table is then added and a PKCS#7 signature stored in this table:

  http://www.microsoft.com/typography/otspec140/dsig.htm

The implementation would probably need to be validated against current tools:

  http://www.microsoft.com/typography/developers/dsig/dsig.htm

[Matthew Paul Thomas (mpt)]

Would this have any tangible benefit? <http://www.microsoft.com/typography/developers/dsig/default.htm> says "The way in which future Microsoft operating systems will deal with signed and unsigned fonts, is still being decided ... this page was last updated 7 November 2001".

Similarly, <http://www.adobe.com/devnet/opentype/afdko/topic_digital_sig_guide.html> lists "Secure identification" and "Guarantee of no tampering" and "it seems probable that future versions of some operating systems will offer users the option of installing only digitally signed, and hence trusted, components", on a page that is undated but tells you to "Put a floppy disk in your Windows system drive A:". Heh.

I do see that "For bad and arbitrary reasons, OT/TTF fonts with layout features are only recognized as such in Windows if they have a DSIG (digital signature) table. Without this table, they behave as normal TTF fonts (i.e., none of the layout features work). This is not true of OT/CFF fonts, which need no DSIG table." <http://typedrawers.com/discussion/192/making-ot-ttf-layout-features-work-in-ms-word-2010> But that page goes on to say that a dummy (signature-less) DSIG table works perfectly well, and provides instructions on how to add it. That is something that could be included in the packaging process.

[Matthew Paul Thomas (mpt)]

Marking as Incomplete until a specific problem is identified that would be solved by signing. If the Ubuntu font is OT/TTF (is it?), and it does not have a DSIG table at all, the Windows issue in my previous comment would be a problem solved by signing ... or by merely adding a dummy DSIG table.

[Paul Sladen (sladen)]

At the moment the .ttfs leave Dalton Maag with a signature—this then (presently) get a certain amount of reproducible patching of the metadata done (the 'midstream' scripts) in order to producible the distributable 'upstream' .ttf source tarball, that is used for Google Web Fonts and .deb package preparation.

Since the DSIG block is needed for identification of advanced features on certain platforms it "needs" to be included. Rather than ship (at 'upstream level') a known non-validating DSIG block, yes it would be better to ship a nullified DSIG block. Even better would be use the signing facility to sign the 'upstream' (distributable) .ttfs.

[Paul Sladen (sladen)]

Reliably patching in zeros (dummy signatures) is probably 1–3 hours work, but once scripted in the build system needs no further work.

Developing a replacement Linux-based signing DSIG font signing tool is probably 1–3 days including the combined QA confirmation work to ensure it works. The blocker here is having a number of MS Windows machines (with various versions) available to confirm that validation works in all cases.

At that point, either a pair of keys need generating and including in the source, or they should be signed with eg. the same keys previously used for signing Java stuff.