Re: [PATCH] Removal of SquidMD5* code

On 03/18/2014 11:37 AM, Amos Jeffries wrote:
> 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.

I have not any special preference for openSSL, I am not insisting on
OpenSSL-crypto.
Just currently squid in most systems can be build without the need of
installing any other package. The libnettle will be the first such
dependency.
However this library is small and easy to be build and installed, is not
a huge problem.

Originally squid3 included openSSL md5 support but for a reason this is
dropped, maybe because of the license.
But currently we have many dependencies to openSSL library, which are
not easy to be removed. Is there any problem if we allow openSSL md5 if
the "--enable-ssl" options is used else require the libnettle?

>
> Amos
>
Received on Tue Mar 18 2014 - 18:39:10 MDT