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-----