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, that's how I know that they do this in the first place). Replacing openssl by the supported crypto api's is something for 3.4 or even 3.5. Somewhat coincidentally, Issue17129 addresses the topic of certificate management across multiple platforms. Using the CA bundle from the OS sounds great, not only for Macs :)
#Openssl for mac windows#
It would be best to be able to use the system-supplied ones since they are actively managed by Apple and can be by the user.Īlso, it would be good to know how the Python Windows distribution handles openssl and certificates. We should investigate what Apple and third-party distributors of openssl on OS X do. Managing the CA certificates certainly is another issue. The reason why I brought this up now is to try to determine if there are any newer ssl features that may be need to be batteries-included to deal with possible changes to Distutils and/or its users (pip, et al). But moving away from openssl seems out of scope for maintenance releases. Yes, as we've discussed, using the Apple Crypto APIs would be nice longer-term assuming the compatibility issues can be managed: the set of available APIs appear to have been evolving over the past several OS X releases. (Note that a clear disadvantage of the latter is that those APIs are "above" the unix layer and likely cause problems when you use fork(2) without exec(2)). In the longer run I'd like to try if it is possible to implement the SSL module (and other extensions linking with openssl) using Apple's crypto APIs. Not having to maintain such a list manually is very convenient. This means that users that verify certificates (cert_reqs=CERT_REQUIRED in the ssl module) could see a regression when they don't specificy a custom CA list.
Apple does deprecate the use of OpenSSL, but there version does offer a feature that's not in the default tree: it verifies SSL certificates against the CA list in the system keychain.
I'm not sure if it is worthwhile to switch right now. I don't think the release will be for several days at least, so you should have time to test.Īuthor: Ronald Oussoren (ronaldoussoren) * Setting to release blocker for release managers' decision.Īuthor: Benjamin Peterson (benjamin.peterson) *Īs you are the MacOSX expert, I'm going to defer your judgement (and/or Ronald's). With the current discussion around security issues, are there features in openssl 1.x.x that warrant making this a release blocker for 2.7.4 and 3.2.4? I should be able to implement and test this over the next few days if so.
#Openssl for mac how to#
Since apparently the openssl upstream builds do not support OS X universal builds, build-installer.py will need to learn how to build each arch separately and lipo them together. The 32-bit installer links with and dynamically loads 0.9.7 and the 64-/32-bit installer with 0.9.8.īuild-installer.py should be enhanced to build and link with its own universal more up-to-date static libssl, as is done for several other OS X-supplied libraries. "If your app depends on OpenSSL, you should compile OpenSSL yourself and statically link a known version of OpenSSL into your app"Ĭurrently OS X ships with patched versions of libssl 0.9.7 and 0.9.8. Pull RequestsĪpple has deprecated use of openssl in OS X due to its unstable API between versions: Kevin Ollivier, benjamin.peterson, christian.heimes, clupo, dilettant, dstufft, eric.araujo, esc24, georg.brandl, larry, loewis, mlen, ned.deily, orsenthil, piotr.dobrogost, pitrou, python-dev, ronaldoussorenĬreated on 18:31 by ned.deily, last changed 14:57 by admin. OS X system openssl deprecated - installer should build local libssl
0 kommentar(er)
