Re: [ft-devel] Migrating layout table validation code to a new CVS module

[Werner LEMBERG]

> I apologize that I wrote non-negligibly large code in gxvalid and it
> triggered this issue, maybe.

No need to apologize at all!

> Turner, how do you think of?  We should start from strict and adding
> capability for exceptional cases?  Or, unaligned memory access is
> different issue and should be validated strictly from initial
> revision?

After some thinking I believe that the unaligned memory problem is a
non-issue.  I'm quite sure that *all* font engines have to read
OpenType tables as bytes and not as words or quartets.  There are far
too many buggy fonts out there which don't follow the standard.  And
as Suzuki-san points out, even Apple fonts are buggy w.r.t. alignment.
Given today's fast computers I doubt that there are severe penalty
issues in doing so.  It makes life *much* simpler.


I'll try to modify the building system of FreeType to make it easier
to include and remove modules.  Then, the default will be simply to
exclude both ftvalid and gxvalid.  After this, we have *enough* time
to fix those issues step by step.

> >The problem is that if both the layout library and validation code
> >are written separately, there is the possibility of a mismatch,
> >where what "ftvalid" think is valid might not be appropriate for
> >the layout one.

I don't think so.  We should perhaps document better what the
validation code really checks, and how a higher-level engine is
expected to access the data (namely as bytes).

> >If you find a security bug in the layout library, you need to
> >ensure that it is also fixed in the validation code. And
> >vice-versa... This is a hassle.

Hmmm, please give a real-world example.

> About plugin, it is good idea (although I'm afraid that FreeType is
> very very widely used on platforms without dlopen etc), but it will
> be long way work.  It should be FreeType3, even if the binary
> compatibility is kept.

Indeed, it will take some time to find proper solutions.  No need to
hurry.


> I have no objection against the pointing out: gxvalid is too big as
> a module built/included by default.

Yep.

> I think, otlayout is still very compact in contrast with gxvalid,
> and no problem to include it in freetype.

I'll remove it from the default build too.

> If I rewrite gxvalid to smaller and limited validation (e.g. memory
> alignment, number of members etc) by default, it's acceptable to
> include?

Don't worry about that right now.  The first step is to simply disable
it in the default build.  Then I'll think how to put it into a
separate library.


    Werner