Re: [PATCH] Removal of SquidMD5* code

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 18 Mar 2014 22:37:34 +1300

On 18/03/2014 9:32 p.m., Tsantilas Christos wrote:
> On 03/17/2014 11:11 AM, Amos Jeffries wrote:
>> This is the patch making libnettle mandatory dependency and dropping
>> completely the bundled MD5 implementation.
>
> Why the bundled MD5 implementation should removed? Is there any reason?
> Adding (mandatory) depedencies to external libraries, which are not
> required, I believe is not in right direction.

That part of it is to make it easier to get Squid installed and for
upgrading on secure networks. At a certain security level each software
unit that contains crypto code needs to be specially audited by experts
and verified as correct and invulnerable. Squid bundling this code
itself means sysadmin have to get each and every upgrade of Squid audited.
 By offloading it to a library means only that library needs auditing
and Squid can be easily upgraded separately.

At least one of my clients can only do that audit once every couple of
years. Which is a huge amount of lag on Squid progress. I've had several
requests for patches doing this with various libraries as the
replacement. Nettle is the first I've seen that actually met the
criteria of compatible licensing, simple API and wide availability.

I know OpenSSL-crypto comes very close but the license issues are still
there.

>
> A such library maybe is required for a software uses a number of
> cryptographic algorithms, but I am not seeing any reason for squid,
> which uses only an md5.

Squid needs MD5, MD4, Blowfish, SHA1 and maybe some of the other SHA*.
I've been contemplating AES as well long-term for the NCSA helper, but
that would be new grounds there across the whole NCSA software ecosystem
and its still a bit slow, so maybe premature rigth now.

>
> The only reason is a little faster md5 implementation, but for the users
> this is required, the libnettle (and openssl if we copy md5.c from
> squid2.6) can be an alternate.

What we are getting with MD5 is the same Ron Rivest implementation in a
separate library we don't need to maintain or go through any of the
above loop jumping for. I've not mentioned algorithm speed as a factor IIRC.

If you are insisting on OpenSSL-crypto we can keep include/md5.h (as
compat/md5.h I think) with wrapper #if-#endif conditions for OpenSSL
mapping alongside a Nettle mapping. I will not put it as primary library
choice though due to those license hurdles already mentioned.

That would give us both libraries as alternative dependencies with some
additional possibility of adding the NSS, Solaris or MacOS native APIs
at some later point. Which was the original goal way back when the
OpenSSL-crypto usage got dropped from Squid-3 usage.

Amos
Received on Tue Mar 18 2014 - 09:37:43 MDT

This archive was generated by hypermail 2.2.0 : Wed Mar 19 2014 - 12:00:13 MDT