[MPEG-OTSPEC] Co-existence of glyph rendering source types

[Adam Twardoch (Lists)]

On Sat, 12 Sep 2020 at 01:34, Dave Crossland <dcrossland at google.com> wrote:
> I'm not sure "political reasons" is a good principle. The political
reasons have a technical basis, right?

Well, I'm not qualified enough to speak about whether CFF2 is technically a
“good thing” or not. I know some people dislike it, and I personally always
had problems with CFF, because it felt like a Finnish-speaking person was
dropped into a room full of Slavic people.

I know that one group of people loved CFF: hackers. When the Google
Security researcher Mateusz “j00ru” Jurczyk (the real Polish font hacker)
unveiled his research results 5 years ago, I know this annoyed quite a few
people because thanks to his research, their “favorite holes” got closed.

See below for the hair-raising number of exploits that were associated with
CFF support in both Windows and FreeType. Note that this was about CFF v1.

But I’m not knowledgeable enough to assess whether or to what extent CFF2
also has potential security problems.

I still think it’s a Finnish-speaking person in a room full of Slavic
people. It’s from a different world, so parsing/building it requires a
completely separate code path from the rest.

But it’s likely that it has some advantages. Also, a fully-separate code
paradigm is required to deal with SVG inside OT (something I myself
endorsed), so I cannot say that today CFF(2) is the only “non-SFNTy” part
of OT.

So *in my world*, I can see that there are stakeholders who invested into
CFF2, so I don’t feel I’m equipped to list arguments why it shouldn’t be
part of OFF2. I’m leaving it up to others to come up with pros and cons.

For EBDT, CBDT and CFF, I think I can provide such arguments. sbix is a
functional superset of EBDT and CBDT, and should be the only bitmap flavor.
For CFF, there are several: the fact that a direct follow-up exists (CFF2),
the notorious security past (see links below), the overall redundancy that
is built into CFF (a-font-within-a-font), and the multitude of sub-flavors
(CID, non-CID etc.).

A.

-
https://j00ru.vexillium.org/2016/06/details-on-a-stack-based-buffer-overflow-in-the-adobe-cff-rasterizer-in-freetype2/

-
https://j00ru.vexillium.org/2015/09/44con-slides-and-details-about-further-windows-kernel-font-vulnerabilities/

-
https://j00ru.vexillium.org/2015/06/results-of-my-recent-postscript-charstring-security-research-unveiled/

-
https://j00ru.vexillium.org/talks/recon-one-font-vulnerability-to-rule-them-all/

-
https://googleprojectzero.blogspot.com/2015/07/one-font-vulnerability-to-rule-them-all.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200912/841dbbd0/attachment.html>