Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DSIG remaining issues. #4

Open
HinTak opened this issue Dec 1, 2015 · 9 comments
Open

DSIG remaining issues. #4

HinTak opened this issue Dec 1, 2015 · 9 comments

Comments

@HinTak
Copy link
Owner

@HinTak HinTak commented Dec 1, 2015

Besides verifying the data against the signed hash, I can now also:

  • read the signing time stamp
  • joining the trusted chain.
  • establish about 60% of the fonts being signed by a certificate issued by a root authority, or a proxy of one; using just the thumb prints (i.e. digest) of the 19 certificates shipped by win 8.1. In fact I think I only need about 5. This covers most recent fonts from Vista onwards.

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.

@HinTak
Copy link
Owner Author

@HinTak HinTak commented Dec 2, 2015

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
Copy link
Owner Author

@HinTak HinTak commented Mar 8, 2016

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
Copy link

@Pomax Pomax commented Mar 8, 2016

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
Copy link
Owner Author

@HinTak HinTak commented Mar 8, 2016

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
Copy link

@Pomax Pomax commented Mar 8, 2016

fair enough

@HinTak
Copy link
Owner Author

@HinTak HinTak commented Mar 8, 2016

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
Copy link

@Pomax Pomax commented Mar 8, 2016

yeah, forgot this was DSIG-exclusive behaviour for a moment.

@HinTak
Copy link
Owner Author

@HinTak HinTak commented Apr 27, 2016

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
Copy link
Owner Author

@HinTak HinTak commented Jul 16, 2017

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

HinTak added a commit that referenced this issue Jul 20, 2017
throw NotImplementedException

Conflicts:
	DSIGInfo/DSIGInfo.cs

Part of the ttc hash problems mentioned in
#4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants