Comment 7 for bug 238658

Changing this from "defect" to "enhancement", and changing title from "pyopenssl depends on non-Python-packaged thing (OpenSSL)" to "it would be nice if the dependency on OpenSSL could be automatically resolved".

We don't know how to solve this nicely, but I would like to leave this ticket open to reflect the fact that I wish it were better.

On Mac OS X, OpenSSL with development headers is installed by default (if you've installed the Mac OS X developer tools), so it isn't a problem on that platform.

Note that we used to have a similar problem with the Crypto++ library, and I "solved" it by including the Crypto++ source code inside the pycryptopp package and building all of it when pycryptopp is built. I doubt that the pyOpenSSL developers will want to do the same thing. (And indeed, this has raised a different problem for pycryptopp: how to facilitate users linking against their own libcryptopp ''instead'' of the version of Crypto++ which is included by source code inside pycryptopp. This would be required by Debian to include pycryptopp in Debian, for example.)

Another possible solution, if you aren't on a platform that comes with OpenSSL lib and headers, and if pyOpenSSL isn't willing to bundle OpenSSL source code itself, would be to stop using pyOpenSSL! There are three reasons why this might be a valid future direction: 1. Tahoe actually doesn't need confidentiality or authentication from its transport layer, for the most part. (There are some cases where it does, but perhaps in the future those will go away.) 2. Foolscap might start using a different crypto layer than SSL. 3. Foolscap might start using a Pythonic SSL implementation.