Open HinTak opened 8 years ago
HinTak
commented
8 years ago Oh, and the tool currently mis-calculates hashes of TTC's older than about 15 years. I only have 4 such font files. The issue is well-understood, just haven't got round to it. A TODO.
HinTak
commented
8 years ago The 4 YuGoth* TTC fonts on windows 10 also gets their hashes mis-calculated. It is the same issue with my mis-calculation of very old TTCs. The issue is well-understood, just haven't got time to work on it. I probably should throw an error, rather than let it continue to mis-calculate meanwhile.
Pomax
commented
8 years ago probably warn, rather than error, since bad hashes don't necessarily mean bad internal data for validation purposes: a table with length X and a bad hash might still have perfectly valud data that exactly fills the table's indicated length, so that while there is a bad hash, the fault was in the font's generator, not the font's table data.
HinTak
commented
8 years ago No, a bad hash is a bad hash - it means that the font was modified after signing - even for very legitimate tasks like adding glyphs, etc, which are perfectly valid fonts. The correct way to deal with this is to re-sign the font after modifying it.
As for whether this is an error or warning, you should file this with upstream and let the Microsoft folk decide. They put it as error, so it is up to them to change it.
Pomax
commented
8 years ago fair enough
HinTak
commented
8 years ago The digital signature is for the author to certify "this is exactly how I release it". There are many good reasons for others to modify the font without consulting the original author, and even release a new version - where the license allows - but the new version should be re-signed by the modifying person. DSIG is about authenticity of who-owns-it, not correctness of font structures.
Pomax
commented
8 years ago yeah, forgot this was DSIG-exclusive behaviour for a moment.
HinTak
commented
8 years ago Just note to myself: the TTC issue with very old TTC's and the 4 YuGoth* TTC fonts is that the current get_TTC_digest() ( line 539 to 638 -ish in https://github.com/HinTak/Font-Validator/blob/master/DSIGInfo/DSIGInfo.cs as of now) can only cope with either directory-contiguous or member-font-contiguous TTC's.
i.e. it can only cope with the ttc layout directory1-directory2-directory3...directoryN -font1-font2-font3...fontN or directory1-font1-directory2-font2...directoryN-fontN . Those exceptions don't belong to either - they have tables between member fonts interlaced.
Essentially all TTC in the last 15 years are in either category, or in any case, those I have.
HinTak
commented
7 years ago v2.1 will say it cannot cope with very old TTCs and the 4 YuGoth TTC fonts, insead of saying the hash does not match. It is currently a bit ugly - throwing an UnImplemented Exception. I'll see if I can make it a bit better
Besides verifying the data against the signed hash, I can now also:
There is a bit more work to do to check timestamp is within certificates' validity period etc. Just tedious but straightforward. These are considerable more informative than the official MS tool check, and covers older fonts already.
However, the signing timestamp code is windows-only ( mono bug: https://bugzilla.xamarin.com/show_bug.cgi?id=36295 ), the trusted chain codes uses a lot of Mono-specific certificate manipulation code and is non-windows-only; and to establish trust of the older 40% of signed fonts I need to include more trusted thumb prints, or at worst, maybe even the (older) root certificates themselves.
So between windows-only, non-windows-only, and more bundled certificates - all 3 means importing lots of non-mine code or data (the windows-only problem means fix the bug and bundle the fixed Mono code, the non-windows-only problem means bundling the non-windows part of Mono code...).
To build the non-windows trusted chain code, do 'make USE_MONO_SECURITY=true' instead of plain make.