Re: [squid-users] Solaris/OpenSSL/MD5 Issues

>
> The patches to make "MD5" work on Solaris have broken things on
> FreeBSD (at least) which also has a sys/md5.h. Compile fails with
> "error: `MD5_DIGEST_LENGTH' was not declared in this scope"
>
> It seems to me that the original problem was just that Squid's own
> MD5 routines are using names that collide with some system
> libraries/headers. Since we already ship a public domain MD5
> implementaiton with Squid, why not just change our names to be
> unique and then always use them?
>
> Why go through this yucky configure maybe-find-some-libraries-here
> or maybe-find-them-there stuff?
>
> DW

Well, for starters its not as messy as it seems, it replaces a whole bunch
of configure.in if-else clauses with a single pre-compiler #if-else in the
header where it is actually needed anyway. There it produces the 'nice'
defined names/variables squid can use and it reduces the maintenance
workload on all of us keeping that code up to date.
If the OS or another project are doing all the work maintaining it, why
duplicate the problems and fixes ourselves?

As for making squid use unique names. That is the general idea.
I think in most cases squid uses x... and has a lib/*.h which does the use
A or use B, #define whichever to be x... for squid to use.
The small problem here is that this case squid is not yet using xMD5*, but
trying to do it to one of the optional standard naming schemes.

The bigger problem which you have just uncovered is that FreeBSD does
provide a sys/md5.h, but does not define the MD5_DIGEST_CHARS or
MD5_DIGEST_
For the fix of FreeBSD. It should just be a little tweak of the #define for

What I'm thinking to do now (bigger change than I wanted to make) to get
around the FreeBSD case is add that 'x' at the front of these MD5
functions within all squid code. And update the md5.h header to only use
the OS ones if they define MD5_DIGEST_LENGTH properly to the size we
apparently need it.

  src/CacheDigest.cc has an assert(MD5_DIGEST_CHARS==16) with a note about
hash keys.

If anyone can think of a way of picking openssl without the USE_OPENSSL
logics migrating in from configure.in, please mention. Might be worth
getting done for the 3.1 cleanup.

Amos
Received on Tue Nov 13 2007 - 18:36:21 MST