This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ronaldoussoren
Recipients benjamin.peterson, brian.curtin, eric.araujo, esc24, georg.brandl, larry, loewis, ned.deily, pitrou, ronaldoussoren
Date 2013-02-05.06:53:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1360047230.46.0.986587995402.issue17128@psf.upfronthosting.co.za>
In-reply-to
Content
Replacing openssl by the supported crypto api's is something for 3.4 or even 3.5.

There is a way to keep the current functionality while still shipping a build of openssl: apply the patch that implements the feature to the upstream version when building it (the patch is available on opensource.apple.com, that's how I know that they do this in the first place).

Something that should be tested before this gets merged: what happens when a user installs pyOpenSSL with python 2.7.3 install (linked to system openssl) and then upgrades to 2.7.4 linked to a custom build of openssl without changing pyOpenSSL.  

I wouldn't expect problems when looking at the documentation (there doesn't seem to be a way to transfer SSL state at the C level), and something similar can already happen: python is linked with a fairly old version of OpenSSL, and you get a later version when linking on a newer OSX release (hence a lot of users that download the binary installer and then install pyOpenSSL already have a version mismatch between the two extensions using openssl).
History
Date User Action Args
2013-02-05 06:53:50ronaldoussorensetrecipients: + ronaldoussoren, loewis, georg.brandl, pitrou, larry, benjamin.peterson, ned.deily, eric.araujo, brian.curtin, esc24
2013-02-05 06:53:50ronaldoussorensetmessageid: <1360047230.46.0.986587995402.issue17128@psf.upfronthosting.co.za>
2013-02-05 06:53:50ronaldoussorenlinkissue17128 messages
2013-02-05 06:53:50ronaldoussorencreate