freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ft-devel] Migrating layout table validation code to a new CVSmodule


From: Turner, David
Subject: RE: [ft-devel] Migrating layout table validation code to a new CVSmodule
Date: Mon, 21 Nov 2005 10:39:32 +0100

> 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?
> 
It depends on what your client wants. Some processing engines
are capable of dealing with unaligned data, so they won't
need the alignment requirement. So either do all checks,
or make them configurable (e.g. with a validation level
provided by the client).

> Umm, do you mean something like: if gxvalid returns false
> "conforming" result to ICU, it can cause security bug in
> ICU, so ICU won't believe the result of gxvalid and ICU
> will have their own validator...?
>
What I mean is that if ICU completely trusts a broken validator,
it might end up processing garbage, which will cause bad rendering,
or even crashes and security bugs.

> 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.
>
There is no need for dlopen() or equivalent. We have FT_Add_Module
which can be called just after FT_Init_FreeType to add modules to
the font engine.

That's what I use on my company's embedded software, to register
custom font drivers for some proprietary bitmap formats we need
to support. All is done statically.

> I have no objection against the pointing out: gxvalid
> is too big as a module built/included by default.
> I think, otlayout is still very compact in contrast
> with gxvalid, and no problem to include it in freetype.
> If I rewrite gxvalid to smaller and limited validation
> (e.g. memory alignment, number of members etc) by
> default, it's acceptable to include?
>

I think that wouldn't solve the issue:

- it's not really part of the font engine's work, since
  we don't provide APIs to process the tables.

- it ties the releases of the validation and FT2 code,
  when these could be independent.

Hope this helps,

- David

> mpsuzuki
>
>
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype-devel
>
***********************************************************************************
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the address@hidden and destroy the original 
message.
***********************************************************************************





reply via email to

[Prev in Thread] Current Thread [Next in Thread]