[Python-Dev] SSL support in _socket (original) (raw)

M.-A. Lemburg mal@lemburg.com
Wed, 13 Feb 2002 10:22:05 +0100

"Martin v. Loewis" wrote:

"M.-A. Lemburg" <mal@lemburg.com> writes: > What can we do about this ? The standard solution is to modify Modules/Setup at installation time, to suit your local needs.

I thought that Modules/Setup is deprecated and replaced by the auto setup tests in setup.py ? In any case, setup.py will simply remove _socket if it doesn't import correctly and so a casual sys admin or user will lose big if his OpenSSL installation happens to be out of sync with whatever we provide in _socket.

> Perhaps we should simply let setup.py build two extensions: socket > (without SSL) and socketssl (with SSL) ?! If the socketssl build > or import fails for some reason, Python could still pick up the > socket extension in socket.py.

-1: Instead of avoiding to use an existing OpenSSL installation, it would be much better if the socket module was fixed to work with all existing versions. Of course, without a precise bug report, we cannot know whether this was possible.

Some symbols starting with 'RAND_*' are aparently missing from OpenSSL on my notebook. On other occasions (i.e. on RedHat) I found that the system vendor had forgotten to provide a link to the 0.9 version of OpenSSL and instead used 1.0 as version number (which is completely wrong since there is no 1.0 version of OpenSSL). As a result, _socket built on a system with correctly setup libs wouldn't run on this particular RedHat installation.

In summary: _socket is just too important to lose if something in the OpenSSL support goes wrong. The two build model I suggested fixes this problem elegantly and doesn't cost anything in terms of adding tons of code -- all we need is an #ifdef for the module name in _socketmodule.c

-- Marc-Andre Lemburg CEO eGenix.com Software GmbH

Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/