[Python-Dev] SSL support in _socket

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/