<div dir="auto">On Sat, 12 Sep 2020 at 01:34, Dave Crossland <<a href="mailto:dcrossland@google.com">dcrossland@google.com</a>> wrote:</div><div dir="auto">> I'm not sure "political reasons" is a good principle. The political reasons have a technical basis, right?</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">But I’m not knowledgeable enough to assess whether or to what extent CFF2 also has potential security problems. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.). </div><div dir="auto"><br></div><div dir="auto">A.</div><div dir="auto"><br></div><div dir="auto">- <a href="https://j00ru.vexillium.org/2016/06/details-on-a-stack-based-buffer-overflow-in-the-adobe-cff-rasterizer-in-freetype2/">https://j00ru.vexillium.org/2016/06/details-on-a-stack-based-buffer-overflow-in-the-adobe-cff-rasterizer-in-freetype2/</a></div><div dir="auto"><br></div><div dir="auto">- <a href="https://j00ru.vexillium.org/2015/09/44con-slides-and-details-about-further-windows-kernel-font-vulnerabilities/">https://j00ru.vexillium.org/2015/09/44con-slides-and-details-about-further-windows-kernel-font-vulnerabilities/</a></div><div dir="auto"><br></div><div dir="auto">- <a href="https://j00ru.vexillium.org/2015/06/results-of-my-recent-postscript-charstring-security-research-unveiled/">https://j00ru.vexillium.org/2015/06/results-of-my-recent-postscript-charstring-security-research-unveiled/</a></div><div dir="auto"><br></div><div dir="auto">- <a href="https://j00ru.vexillium.org/talks/recon-one-font-vulnerability-to-rule-them-all/">https://j00ru.vexillium.org/talks/recon-one-font-vulnerability-to-rule-them-all/</a></div><div dir="auto"><br></div><div dir="auto">- <a href="https://googleprojectzero.blogspot.com/2015/07/one-font-vulnerability-to-rule-them-all.html">https://googleprojectzero.blogspot.com/2015/07/one-font-vulnerability-to-rule-them-all.html</a></div><div dir="auto"><br></div>