[ft-devel] Amalgamation details
From: Alan Coopersmith alan.coopersm...@oracle.com A pretty convenient way to make your software full of security holes and other bugs if you don't spend the time to update it for every upstream patch, at which point you'll find that it's not all that convenient compared to just using a shared library. *sigh* people assume FreeType is only used for operating systems. How many times do I have to repeat the use-case for embedding both FreeType, and a font, within a desktop or smartphone application? For cases where the user cannot choose the font, there is no security hole. Amalgamation can be a way to make updating more convenient...Replacing old versions of freetype.c and freetype.h with newer versions of those same two files is far more convenient than replacing an old set of Freetype source files with a newer set, especially if files are renamed, removed, or added between versions. Right on! That's exactly what I'm talking about. My only concern about the amalgamated version of Freetype is that I don't know if it will continue to be maintained. For that reason, we haven't yet switched over to using the amalgamated version except experimentally. It will be maintained, and I have plans for improving the amalgamated distribution further. I've already added a feature for reducing the size of the result, to shave about 570kb off the FreeType amalgamation. I would also like to implement a config header file that lets certain portions of FreeType get turned off and on easily with preprocessor directives. And there will be a COMMITLOG file that tracks exactly what's in the amalgamation by quoting the entire commit log from which it was generated, along with proper tags in the git repository to refer to specific releases of FreeType. Currently, if I'm not mistaken, the amalgamation tool itself is not cross-platform. I haven't tried running it to produce the amalgamation myself. I've only tried using versions of freetype.c and freetype.h that Vinnie has made available. I would love to see the amalgamation tool become cross-platform and part of the Freetype project itself. Fully cross platform! The one thing that is not cross platform is the .bat file that drives it but that could be easily ported since its just a lot of command line switches.To get it into FreeType you would need the tool (which is itself just one source file, and one amalgamated multiplatform Juce module), the amalgamation templates, and a script to drive it. These are all open source. Before jumping to include it in the official distribution, I suggest giving it a week or two until I've made all the improvements I can make. Someone needed access to FT_Glyph which if I am not mistaken, is not available from a straight include of freetype.h. So I added the include to the amalgamated headers. If there are any other optional header files that I've forgotten let me know and I will add them. Also, if there is anything I can do to improve the amalgamated distribution I would be more than happy to do so. Thanks ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Amalgamation details
On 04/14/12 06:48 AM, Vinnie wrote: From: Alan Coopersmith alan.coopersm...@oracle.com A pretty convenient way to make your software full of security holes and other bugs if you don't spend the time to update it for every upstream patch, at which point you'll find that it's not all that convenient compared to just using a shared library. *sigh* people assume FreeType is only used for operating systems. How many times do I have to repeat the use-case for embedding both FreeType, and a font, within a desktop or smartphone application? For cases where the user cannot choose the font, there is no security hole. Do you know where most of the FreeType security issues in the past few years has been found? By people trying to hack smartphones via downloads of malicious PDF's or opening webpages with bad webfonts.Quite a few of the jailbreaks for Apple's iOS have resulted in FreeType security patches coming out - you can see credits to both Apple Google for providing fixes in the various advisories. Of course, those smartphone OS'es are providing system font rendering using FreeType so you don't have to shove in another copy there. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Amalgamation details
From: Alan Coopersmith alan.coopersm...@oracle.com Do you know where most of the FreeType security issues in the past few years has been found? By people trying to hack smartphones via downloads of malicious PDF's or opening webpages with bad webfonts. That's only a vulnerability of the application in question allows loading of arbitrary fonts. For the case where an application simply wants hinted output of its own font used in a user interface, with the entire font file embedded in the application as static data or a resource (100% of my users) there is no issue! Of course, those smartphone OS'es are providing system font rendering using FreeType so you don't have to shove in another copy there. I agree and its on my to-do list to refine the amalgamation so that it detects and uses the system provided library on environments where it exists. This behavior will be overridable with a configuration macro, for those people who have built a rich GUI on top of a hinted font and did all their testing with a specific version of FreeType, and don't want to be exposed to a bug in a shared FreeType library making their application look bad (for example, a defect discovered in the auto hinter). The end-game is to build rich open source GUI components on top of the FreeType amalgamation which will seamlessly provide FreeType either through the amalgamated sources or the system provided libraries (at the programmer's option), with the ability to distribute these GUI components without external dependencies (by including the amalgamation in the source distribution). All this, with no Makefiles or platform specific configuration required. In other words, for dummies. Of course it is worth repeating once again this use-case is contemplated ONLY FOR FONTS EMBEDDED IN THE APPLICATION and not for fonts which come from external files! I know this is a difficult concept for a lot of people who have no experience writing shrink-wrapped applications (which seem to be going the way of the Dodo) so here is an example (again): http://m.artician.com/pu/3G665GVDE5WXL3A7SOS6MP4RCOI6MJHB.preview.jpeg This is GUI for an audio plugin. These plugins typically have compact interfaces with small text, which is a great candidate for hinting. A plugin author can choose a good hinted font, embed it in their application (using a command tool that converts a binary file into a giant C-style static array), and then use FreeType to draw the font and get nice output at the small sizes. The benefit of using a statically linked FreeType is that you can design your interface, test it against the specific FreeType version, and then be assured that no matter what the user has on their system in terms of FreeType libraries, the application or plugin appearance will not change. Most audio plugins are built on JUCE (http://rawmaterialsoftware/juce.php) which is specifically tuned for making it easy to write cross platform user interfaces and audio plugins in particular. For this reason, I have built a class that works with the JUCE font rendererer to provide hinted output for embedded fonts: http://vinniefalco.github.com/VFLib/class_free_type_faces.html I hope this rant has helped to provide a broadened view of the variety of ways in which FreeType may be used. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Amalgamation details
Vinnie, I support what you've done. It sounds very useful and as you say is not dangerous if used as intended. My choice in writing a cross-platform mapping library (CartoType) was to use a stable version of FreeType as an integral part of the CartoType library. I don't use any OS version of FreeType, or indeed any OS graphics primitives - to do so would invite trouble and inconsistency. By this means I get identical behaviour on all platforms. So it looks like I have the same constraints and aims as you. This way I keep my users happy and it's easier for me to maintain the code. Best regards, Graham Asher CartoType Ltd. On 14/04/2012 17:19, Vinnie wrote: From: Alan Coopersmithalan.coopersm...@oracle.com Do you know where most of the FreeType security issues in the past few years has been found? By people trying to hack smartphones via downloads of malicious PDF's or opening webpages with bad webfonts. That's only a vulnerability of the application in question allows loading of arbitrary fonts. For the case where an application simply wants hinted output of its own font used in a user interface, with the entire font file embedded in the application as static data or a resource (100% of my users) there is no issue! Of course, those smartphone OS'es are providing system font rendering using FreeType so you don't have to shove in another copy there. I agree and its on my to-do list to refine the amalgamation so that it detects and uses the system provided library on environments where it exists. This behavior will be overridable with a configuration macro, for those people who have built a rich GUI on top of a hinted font and did all their testing with a specific version of FreeType, and don't want to be exposed to a bug in a shared FreeType library making their application look bad (for example, a defect discovered in the auto hinter). The end-game is to build rich open source GUI components on top of the FreeType amalgamation which will seamlessly provide FreeType either through the amalgamated sources or the system provided libraries (at the programmer's option), with the ability to distribute these GUI components without external dependencies (by including the amalgamation in the source distribution). All this, with no Makefiles or platform specific configuration required. In other words, for dummies. Of course it is worth repeating once again this use-case is contemplated ONLY FOR FONTS EMBEDDED IN THE APPLICATION and not for fonts which come from external files! I know this is a difficult concept for a lot of people who have no experience writing shrink-wrapped applications (which seem to be going the way of the Dodo) so here is an example (again): http://m.artician.com/pu/3G665GVDE5WXL3A7SOS6MP4RCOI6MJHB.preview.jpeg This is GUI for an audio plugin. These plugins typically have compact interfaces with small text, which is a great candidate for hinting. A plugin author can choose a good hinted font, embed it in their application (using a command tool that converts a binary file into a giant C-style static array), and then use FreeType to draw the font and get nice output at the small sizes. The benefit of using a statically linked FreeType is that you can design your interface, test it against the specific FreeType version, and then be assured that no matter what the user has on their system in terms of FreeType libraries, the application or plugin appearance will not change. Most audio plugins are built on JUCE (http://rawmaterialsoftware/juce.php) which is specifically tuned for making it easy to write cross platform user interfaces and audio plugins in particular. For this reason, I have built a class that works with the JUCE font rendererer to provide hinted output for embedded fonts: http://vinniefalco.github.com/VFLib/class_free_type_faces.html I hope this rant has helped to provide a broadened view of the variety of ways in which FreeType may be used. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
