<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Yes, this is a serious issue -- we are totally dependent on openssl<br>for computing MD5 checksums. Several modules use MD5 checksums
<br>casually, and it&#39;s not good that these fail when openssl isn&#39;t<br>available (or if it&#39;s too old, like what happened on an ancient Red<br>Hat 7.3 system I have at home). I&#39;m tempted to put the old<br>RSA-copyrighted 
md5.c back in as a fallback, even though its license<br>is impopular. Or perhaps we could make a copy of a small fraction of<br>openssl and use that? I think MD5 is the only one that&#39;s popular<br>enough to warrant this treatment; I think SHA1 is a distant second.
</blockquote><div><br>Every OS I use has openssl installed so i figured someone else had made the same decision and removed the non-openssl variants.&nbsp; Are there really non-linux/bsd/osx installations out there where anyone intends to build and install python that do -not- have openssl installed somewhere?&nbsp; That&#39;d be sad but in that case we shouldn&#39;t abandon them.&nbsp; Modifying 
setup.py to find it installed in a different place should be easy if thats all it takes.<br><br>Rather than resurrecting the old RSA-copyright md5.c I can easily make new ones out of the libtomcrypt md5 and sha1 sources the same way i created the non-openssl sha256 and sha512 modules.
<br><br>We should not limit ourselves to only md5 if we do that, lets guarantee that md5, sha1 - sha512 are available on all future python installs; its not difficult.&nbsp; I&#39;ll do the work if we need it.<br><br>-gps<br><br>
</div></div>