Storing glyphs as Pixmaps

[Carsten Haitzler (The Rasterman)]

On Mon, 06 Aug 2007 15:29:28 -0700 Carl Worth <cworth at cworth.org> babbled:

> On Sun, 05 Aug 2007 12:25:50 -0400, James Cloos wrote:
> > >>>>> "Carl" == Carl Worth <cworth at cworth.org> writes:
> >
> > Carl> I've replaced the weak XOR-based hash with a cryptographically strong
> > Carl> hash (SHA1) that will be (probabilistically) collision free. This
> > Carl> does introduce a new dependency of the X server on the openssl
> > Carl> library.
> >
> > If you want to avoid that dependency, there is at least one public domain
> > implementation of sha1 available.
> >
> > Steve Reid's version can be found -- among other sites -- at:
> >
> > http://www.pdcode.org/code/sha1/
> >
> > A small modification could call that when necessary, or use the hardware
> > where available, eg on Via or Niagara2 processors.
> 
> Several people have sent me pointers to various small implementations
> of the SHA1 algorithm.
> 
> Ralph Giles pointed out a public-domain implementation:
> 
> 	http://www.mirrors.wiretapped.net/security/cryptography/hashes/sha1/sha1.c
> 
> for which he used a cleaned-up version in jbig2dec:
> 
> 	http://svn.ghostscript.com/ghostscript/trunk/gs/jbig2dec/sha1.h
> 	http://svn.ghostscript.com/ghostscript/trunk/gs/jbig2dec/sha1.c
> 
> And Peter Stuge sent me the following list:
> 
> 	http://libtom.org/cvs/cvsweb.pl/libtom/libtomcrypt/src/hashes/sha1.c
> 	(LibTomCrypt, public domain)
> 
> 	http://www.ietf.org/rfc/rfc3174.txt
> 	(ISOC reference implementation, almost public domain)
> 
> 	http://www.packetizer.com/security/sha1/
> 	(Modified version of above, "freeware," distributable)
> 
> 	http://xyssl.org/code/source/sha1/
> 	(Optimized, LGPL)
> 
> 	http://www.di-mgt.com.au/src/sha1.c.txt
> 	(Unspecified license)
> 
> Personally, I have no problem with a library dependency. In general,
> library code is greatly preferable over pulling a copy of some code
> directly into the X server. Using a library means less maintenance
> burden, automatically picking up bug fixes and optimizations, and
> allowing the library itself to do things like optimizations to call
> hardware implementations where available.
> 
> I only mentioned the potential concern of a new dependency in case
> some Xorg maintainers/developers would be allergic to it. (For me,
> personally, openssl is universally available on any machine I would
> ever install Xorg on.)

in this case - i think needing all of openssl for just an sha1 routine is
overkill. if we were  using it also for secure comms (eg providing a NATIVE
xlib proto over SSL support in xorg core and xlib/xcb etc. eg on port
7000,70001, etc.) - then let's use it by all means.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)