setup.py detects the version of openssl by looking for openssl headers on a deduced search path. That path is not guaranteed to be equal to the real compiler search path, in particular not when building using the OSX 10.4 SDK on MacOSX 10.6: in that situation the compiler will use a header file with the following definition:

#define OPENSSL_VERSION_NUMBER  0x009070cfL

While setup.py reads the header file in /usr/include which contains this definition:

#define OPENSSL_VERSION_NUMBER  0x009080cfL

The actual version is below the sha256 cutoff in setup.py, while setup.py detects a newer version that is above that cutoff. That results in a tree where setup.py tries to build _sha256 using OpenSSL, but fails. That in turn results in a build of hashlib that doesn't work.

Note that this is a specific instance of bpo-7724, but fixing this particular issue is probably easier than fixing the generic issue.

On recent trunk and py3k you can get the real version number:
http://docs.python.org/dev/library/ssl.html#ssl.OPENSSL_VERSION

So perhaps you can first build the _ssl module, then import it to get that information.
Of course it would be much better to build against the proper headers.

I've attached a patch that fixes this issue to bpo-7724.

Looks like you forgot your patch.

The patch is attached to bpo-7724. As that issue notes the current version of setup.py ignores OSX SDKs during builds, the patch in that issue makes sure that setup.py looks in the SDK when looking for files (The patch also modifies distutils.unixccompiler to do the same when looking for library files).

Closing because the patch in bpo-7724 fixes this problem.