Re: OpenSSL's MD5?

Stefan Walter <[email protected]> Tue, 3 Jan 2006 11:14:06 +0100
Newsgroups gmane.mail.spam.spamprobe.general
Organization Infinity Approximation Task Force
Message-ID <[email protected]>
Hi,

Brian Burton, 02.01.06, 15:19h CET:

[...Using OpenSSL's MD5 routines...]
> The original FreeBSD port maintainer and I had a discussion about this. 
>   My position is that the MD5 implementation used by SpamProbe is free, 
> small, and guaranteed to be present everywhere because it comes as part 
> of SP.  I want SP to have as few external dependencies as possible. 
> Currently you can build and run SP on a system with just a C++ compiler 
> and no extra third party libararies.  I like that and intend to keep it 
> that way.

OK.

> As far as maintenance goes I would have more coding and maintenance work 
> if I tried to support two MD5 libaries (Aladdin and OpenSSL) vs the one 
> that I have now.  The SP MD5 digest does not need to interact with any 
> other MD5 implementation (i.e. the digests are used internally by SP, 
> not passed on to any other entity) so even if they are wrong (which I 
> don't believe them to be) it would not matter.  The Aladdin 
> implementation runs cleanly in valgrind so I don't believe it to have 
> any memory bugs.

OK.

> So my advice is to simply use the MD5 that comes with SP and be happy. 
> Had the original maintainer done so his port would probably still work 
> trivially with 1.4.  I compile and test SP on a FreeBSD 4.5 VM and it 
> compiles cleanly so the port really shouldn't have to do any patching to 
> SP.  If you find any patches that are necessary to get SP to compile 
> please let me know and I'll correct the problem in an updated release.

I agree that it's not the port(er)'s job to change/extend the program. As
I didn't find any public statement about what you think about using
OpenSSL, I asked here first. I certainly do not intend to make new patches
for replacing spamprobe's routines with OpenSSL's for every release; the
port now compiles and installs the program as it is, which I like.

There aren't any patches required to make it work, but I'd like to ask for
a configure switch to explicitly enable/disable libungif support.
Currently, this is done by (not) adding the include path for gif_lib.h so
that configure either finds it or not. That works, but I consider it a
hack that could be easily avoided with an appropriate switch.

Regards,
Stefan
signature.asc (application/pgp-signature, 650 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iQGVAwUBQ7pOblaRERsSueCzAQIKIgv+NmiqlqLo5GrA9IvHoh90JQhsckec1ma9
HspBvnefJ7al3Oyav2bkbptyU+m8m+FsQ5ONAdhirzSjygjKTWi0hMnbJSR4+7rN
SqEtrb5H+hAjPqQ6jv4DTP96PO+r5SEjymjmNZpNs7VrV9AkEOMPU/vtK9Xcl6ns
940PIi+axYIJfR1ixteAT8Uks+n758wcP5mgtfQSeHdSX0hJmfT3YZP37H6HOOUL
LWWUNVnlK3UGzQfJALTJiOZ2kkzU38OdD+C9nATWwb0jYDcRk2MBa1ECH4TNXbk7
VpR3R6AIRVyRUvL82oLnLSgcFqU3/lBInP0AoSjb1xmgny7Cx+G9bHQ5/78X4RD+
tiXdjJqH98vRdyNRi8fizlhVBY1k+sFnuB1aDRF/NnlJ83tg1R5N9MTwTLdTyH1Q
6j61o+4qz9bfblgN/WmYl8OmLQv0GrXvEJsESWxxTwhKncbqqFta4qweEmOL+7yp
Ka978O9smU8TW19NjC/DXIPQrQz5VOvK
=QMg7
-----END PGP SIGNATURE-----