Message181420
| 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:50 | ronaldoussoren | set | recipients: + ronaldoussoren, loewis, georg.brandl, pitrou, larry, benjamin.peterson, ned.deily, eric.araujo, brian.curtin, esc24 |
| 2013-02-05 06:53:50 | ronaldoussoren | set | messageid: <1360047230.46.0.986587995402.issue17128@psf.upfronthosting.co.za> |
| 2013-02-05 06:53:50 | ronaldoussoren | link | issue17128 messages |
| 2013-02-05 06:53:50 | ronaldoussoren | create | |