I guess the preference using shared library for security issue is
because the upgrading of single shared library can fix the security
holes of various softwares depending the library by single action.
I can upgrade MY software quickly is not valid objection to the
preference. The valid objection should say I can update ALL softwares
in my computer quickly, and, sometimes it should say I can update
ALL softwares in quickly, even if I don't have the source SDKs of
them.
Anyway, such discussion is out of the scope of the people saying
i don't get why I feel as some people asking for a bread
(or fermented paste) in the miller's market.
Regards,
mpsuzuki
Tom Bishop, Wenlin Institute wrote:
On Apr 13, 2012, at 5:41 AM, Alan Coopersmith wrote:
On 04/13/12 07:30 AM, Vinnie wrote:
From: http://rawmaterialsoftware.com/viewtopic.php?f=6t=8654
those amalgamations are pretty convenient imo, i don't get why you got so much
hostility on the freetype dev list
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.
http://www.dwheeler.com/blog/2012/04/03/#insecure-libraries
Amalgamation can be a way to make updating more convenient, thereby increasing
security. This is true for projects that include Freetype source files directly
rather than building a separate library and linking with it. 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.
Here's the difference I'm talking about in one of our makefiles; instead of
this:
vpath ../freetype/src/autohint ../freetype/src/bdf ../freetype/src/cff
../freetype/src/cache \
../freetype/src/gzip ../freetype/src/base ../freetype/src/pcf
../freetype/src/pfr \
../freetype/src/psaux ../freetype/src/pshinter ../freetype/src/psnames
../freetype/src/raster \
../freetype/src/sfnt ../freetype/src/smooth ../freetype/src/truetype
../freetype/src/type1 \
../freetype/src/cid ../freetype/src/type42 ../freetype/src/winfonts
../freetype/src/lzw ../freetype/src/autofit \
...
OBJS_FREETYPE = \
bdf.o cff.o ftbase.o ftcache.o ftglyph.o ftgzip.o ftinit.o \
ftsystem.o pcf.o pfr.o psaux.o pshinter.o psnames.o raster.o \
sfnt.o smooth.o truetype.o type1.o type1cid.o type42.o winfnt.o
fttype1.o \
ftbitmap.o ftlzw.o autofit.o
We can have this:
vpath ../freetype \
...
OBJS_FREETYPE = freetype.o
We have a bunch of makefiles in which the amalgamation enables us to make that
simplification. For some platforms we don't have makefiles, we have project
files (such as for Xcode on Mac OS), and then the amalgamation is even more
valuable, since it saves us from having to use a tedious graphical interface to
add or remove source files when updating Freetype.
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. 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.
Best wishes,
Tom
文林 Wenlin Institute, Inc.Software for Learning Chinese
E-mail: wen...@wenlin.com Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯
___
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
