From barry at barrys-emacs.org Tue Jan 3 15:14:17 2017 From: barry at barrys-emacs.org (Barry Scott) Date: Tue, 3 Jan 2017 20:14:17 +0000 Subject: [Pythonmac-SIG] [Pyobjc-dev] py2app release delayed In-Reply-To: References: <8B2FEB8F-8C8F-49B0-B9FF-0472854B9671@mac.com> <0398E4C1-503B-49C5-86D7-0A1D69857EBD@barrys-emacs.org> Message-ID: <0579772A-2D60-4B5E-8B60-407C5D9ABCEE@barrys-emacs.org> Ronald, I have been testing against your hg repo for py2app d3f3d531abc1324b71b3b8c289877b28bed1d7c0. I have removed my PyQt5 and the pkg_resources hack for putz and tzlocal and every thing looks to be working well. This is looking very good. However I did notice some problems in the summary at the end. In the following list are the a number of false positives. PyQt5.uic.port_v2 is a conditional import and only syntaxically valid on python2. /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/PyQt5/uic/__init__.py:192 if sys.hexversion >= 0x03000000: from .port_v3.string_io import StringIO else: from .port_v2.string_io import StringIO susbproces.py: condictionally import _winapi Line 360: _mswindows = (sys.platform == "win32") Line 426: if _mswindows: import threading import msvcrt import _winapi And the os module conditionally inports nt. What I did with my PythonWinAppPackager https://github.com/barry-scott/PythonWinAppPackager is have a list of false positives and I eliminate them from the summary. The errors shown for six look odd as well but I have not investigated deeply. The mimetypes import of winreg is a convoluted conditional as well, listing as a false positive works for this one as well. Barry Scott Modules not found (unconditional imports): * StringIO (PyQt5.uic.port_v2.string_io) * StringIO.StringIO (pkg_resources._vendor.six) * __main__.__requires__ (bdb, pdb) * _frozen_importlib_external (importlib, importlib.abc) [module alias] * _winapi.INFINITE (subprocess) * _winapi.WAIT_ABANDONED_0 (subprocess) * _winapi.WAIT_OBJECT_0 (subprocess) * _winapi.WAIT_TIMEOUT (subprocess) * cStringIO (PyQt5.uic.port_v2.string_io) * copy_reg (PyQt5.uic.port_v2.string_io) * java (xml.sax._exceptions) * java.System (java.lang) * java.lang.Exception (platform) * nt._getfinalpathname (os) * nt._getfullpathname (os) * nt._getvolumepathname (os) * nt._isdir (os) * org (copy, org.python.core) * org.PyStringMap (org.python) * org.python (copy, pickle, xml.sax) * org.python.core (pickle) * org.python.core.PyStringMap (copy, xml.sax) * org.python.core.imp (copy, pickle) * pkg_resources._vendor.appdirs (pkg_resources) * pkg_resources.extern.pyparsing (pkg_resources._vendor.packaging.markers, pkg_resources._vendor.packaging.requirements) [module alias] * pkg_resources.extern.six (pkg_resources.extern.six.moves.urllib) [module alias] * pkg_resources.extern.six.moves (pkg_resources, pkg_resources._vendor.packaging.requirements, pkg_resources.extern.six.moves) [module alias] * pkg_resources.extern.six.moves.urllib (pkg_resources._vendor.packaging.requirements, pkg_resources.extern.six.moves.urllib) [module alias] * pkg_resources.extern.six.moves.urllib.parse (pkg_resources, pkg_resources.extern.six.moves) [module alias] * sys.getwindowsversion (re) * winreg.CloseKey (mimetypes) * winreg.HKEY_LOCAL_MACHINE (mimetypes) * winreg.OpenKeyEx (mimetypes) * winreg.QueryValueEx (mimetypes) Modules not found (conditional imports): * StringIO (pkg_resources._vendor.six) * __builtin__ (pkg_resources._vendor.pyparsing) * _frozen_importlib_external (importlib, importlib.abc) [module alias] * java (platform) * java.lang (platform, xml.sax._exceptions) * org.python.core (xml.sax) Modules with syntax errors: * PyQt5.uic.port_v2.invoke * PyQt5.uic.port_v2.load_plugin From Jack.Jansen at cwi.nl Tue Jan 10 11:05:38 2017 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue, 10 Jan 2017 17:05:38 +0100 Subject: [Pythonmac-SIG] apple-Python and TLS 1.0 Message-ID: I have completely ignored this whole TLS 1.0 versus TLS 1.2 security debate until know, but just now the following post came in on python-announce, which seems to suggest that TLS 1.0 is really about to be phased out: https://mail.python.org/pipermail/python-announce-list/2017-January/011437.html I think Python 2.7 older that 2.7.13 (i.e. including the apple-shipped Pythons) don?t support TLS 1.2 by default, which would seem to suggest that things like pip will stop working as of this summer. Or am I overreacting? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From barry at barrys-emacs.org Tue Jan 10 11:00:17 2017 From: barry at barrys-emacs.org (Barry Scott) Date: Tue, 10 Jan 2017 16:00:17 +0000 Subject: [Pythonmac-SIG] [Pyobjc-dev] py2app release delayed In-Reply-To: <0579772A-2D60-4B5E-8B60-407C5D9ABCEE@barrys-emacs.org> References: <8B2FEB8F-8C8F-49B0-B9FF-0472854B9671@mac.com> <0398E4C1-503B-49C5-86D7-0A1D69857EBD@barrys-emacs.org> <0579772A-2D60-4B5E-8B60-407C5D9ABCEE@barrys-emacs.org> Message-ID: <0875AB13-EE8E-499E-83C6-377A9083A9BA@barrys-emacs.org> Ronald, Attached is a patch that cleans up the false positives by allows the recipes to tell build_app what is expected to be missing. I can turn into a pull request if you like the direction of this patch. Oh and the syntax errors in PyQt5 have been fixes for the 5.7.1 version. Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: py2app_expected_missing_imports.patch Type: application/octet-stream Size: 7156 bytes Desc: not available URL: From ronaldoussoren at mac.com Tue Jan 10 14:20:58 2017 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 10 Jan 2017 20:20:58 +0100 Subject: [Pythonmac-SIG] [Pyobjc-dev] py2app release delayed In-Reply-To: <0875AB13-EE8E-499E-83C6-377A9083A9BA@barrys-emacs.org> References: <8B2FEB8F-8C8F-49B0-B9FF-0472854B9671@mac.com> <0398E4C1-503B-49C5-86D7-0A1D69857EBD@barrys-emacs.org> <0579772A-2D60-4B5E-8B60-407C5D9ABCEE@barrys-emacs.org> <0875AB13-EE8E-499E-83C6-377A9083A9BA@barrys-emacs.org> Message-ID: <40918325-4A89-4485-9E3C-ABC176624AAA@mac.com> > On 10 Jan 2017, at 17:00, Barry Scott wrote: > > Ronald, > > Attached is a patch that cleans up the false positives by allows the recipes to tell build_app what is expected to be missing. > > I can turn into a pull request if you like the direction of this patch. I like the idea.. A pull request for this would be nice. Ronald From ronaldoussoren at mac.com Tue Jan 10 14:43:30 2017 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 10 Jan 2017 20:43:30 +0100 Subject: [Pythonmac-SIG] apple-Python and TLS 1.0 In-Reply-To: References: Message-ID: <28C41778-AEC7-4B07-9C26-822B19709B35@mac.com> > On 10 Jan 2017, at 17:05, Jack Jansen wrote: > > I have completely ignored this whole TLS 1.0 versus TLS 1.2 security debate until know, but just now the following post came in on python-announce, which seems to suggest that TLS 1.0 is really about to be phased out: https://mail.python.org/pipermail/python-announce-list/2017-January/011437.html > > I think Python 2.7 older that 2.7.13 (i.e. including the apple-shipped Pythons) don?t support TLS 1.2 by default, which would seem to suggest that things like pip will stop working as of this summer. > > Or am I overreacting? You are not. Annoyingly Donald Stufft already noticed that Apple?s Python is problematic, but breaking for users on a major OS is apparently not a problem :-( This shouldn?t be a problem for most serious development as those users likely use a separate python installation anyway, but this will affect casual users including at least some new users. Ronald > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma Goldman > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG From ronaldoussoren at mac.com Tue Jan 10 14:54:08 2017 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 10 Jan 2017 20:54:08 +0100 Subject: [Pythonmac-SIG] apple-Python and TLS 1.0 In-Reply-To: <28C41778-AEC7-4B07-9C26-822B19709B35@mac.com> References: <28C41778-AEC7-4B07-9C26-822B19709B35@mac.com> Message-ID: <16640175-81DE-4586-8153-ADF8ECA946BE@mac.com> > On 10 Jan 2017, at 20:43, Ronald Oussoren wrote: > > >> On 10 Jan 2017, at 17:05, Jack Jansen wrote: >> >> I have completely ignored this whole TLS 1.0 versus TLS 1.2 security debate until know, but just now the following post came in on python-announce, which seems to suggest that TLS 1.0 is really about to be phased out: https://mail.python.org/pipermail/python-announce-list/2017-January/011437.html >> >> I think Python 2.7 older that 2.7.13 (i.e. including the apple-shipped Pythons) don?t support TLS 1.2 by default, which would seem to suggest that things like pip will stop working as of this summer. >> >> Or am I overreacting? > > You are not. Annoyingly Donald Stufft already noticed that Apple?s Python is problematic, but breaking for users on a major OS is apparently not a problem :-( Breaking Python tools is probably not really on Fastly?s radar and not something that the PyPI folks can easily avoid. > > This shouldn?t be a problem for most serious development as those users likely use a separate python installation anyway, but this will affect casual users including at least some new users. BTW. This doesn?t just break /usr/bin/python but also the Python.org installation of 2.7 (including 2.7.13), and likely any Python.org install exception 3.6 as all installers upto 3.6 use the system OpenSSL that doesn?t support anything beyond TLS 1.0. Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at barrys-emacs.org Wed Jan 11 14:46:13 2017 From: barry at barrys-emacs.org (Barry Scott) Date: Wed, 11 Jan 2017 19:46:13 +0000 Subject: [Pythonmac-SIG] [Pyobjc-dev] py2app release delayed In-Reply-To: <40918325-4A89-4485-9E3C-ABC176624AAA@mac.com> References: <8B2FEB8F-8C8F-49B0-B9FF-0472854B9671@mac.com> <0398E4C1-503B-49C5-86D7-0A1D69857EBD@barrys-emacs.org> <0579772A-2D60-4B5E-8B60-407C5D9ABCEE@barrys-emacs.org> <0875AB13-EE8E-499E-83C6-377A9083A9BA@barrys-emacs.org> <40918325-4A89-4485-9E3C-ABC176624AAA@mac.com> Message-ID: <637133ED-E890-4592-AC73-039902B8CF5A@barrys-emacs.org> > On 10 Jan 2017, at 19:20, Ronald Oussoren wrote: > > >> On 10 Jan 2017, at 17:00, Barry Scott wrote: >> >> Ronald, >> >> Attached is a patch that cleans up the false positives by allows the recipes to tell build_app what is expected to be missing. >> >> I can turn into a pull request if you like the direction of this patch. > > I like the idea.. A pull request for this would be nice. > > Ronald > Done. The pull request submitted has further work then the patch I posted. Tested on python3.5 against my two PyQt5 projects: Barry?s Emacs SCM Workbench Barry From kevino at theolliviers.com Tue Jan 10 12:21:47 2017 From: kevino at theolliviers.com (Kevin Ollivier) Date: Tue, 10 Jan 2017 09:21:47 -0800 Subject: [Pythonmac-SIG] apple-Python and TLS 1.0 In-Reply-To: References: Message-ID: <293B7DCC-A652-4445-8B22-ECD16F7B9370@theolliviers.com> Hi Jack, No, I think you're spot on, this is a big problem. Actually, 2.7.9-2.7.12, even the Python.org ones, are already somewhat broken because they use Apple's ancient OpenSSL version. All the ciphers supported by that version of OpenSSL are ones that are regarded as insecure now, so most modern servers, including big ones like AWS, don't allow them anymore. Because of this you can't even download a newer OpenSSL from the OpenSSL web site using Python. :( It surprised me to find that the Python community wasn't really aware of this problem. For one project I worked on we actually re-coded all our download code to use the Cocoa HTTPS classes via PyObjC, and this was a couple years back. Don't know how many others out there have been fighting with it. Kevin On 1/10/17, 8:05 AM, "Pythonmac-SIG on behalf of Jack Jansen" wrote: I have completely ignored this whole TLS 1.0 versus TLS 1.2 security debate until know, but just now the following post came in on python-announce, which seems to suggest that TLS 1.0 is really about to be phased out: https://mail.python.org/pipermail/python-announce-list/2017-January/011437.html I think Python 2.7 older that 2.7.13 (i.e. including the apple-shipped Pythons) don?t support TLS 1.2 by default, which would seem to suggest that things like pip will stop working as of this summer. Or am I overreacting? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG at python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG From Jack.Jansen at cwi.nl Thu Jan 12 09:10:22 2017 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu, 12 Jan 2017 15:10:22 +0100 Subject: [Pythonmac-SIG] apple-Python and TLS 1.0 In-Reply-To: <16640175-81DE-4586-8153-ADF8ECA946BE@mac.com> References: <28C41778-AEC7-4B07-9C26-822B19709B35@mac.com> <16640175-81DE-4586-8153-ADF8ECA946BE@mac.com> Message-ID: <80FA2776-7B3B-4444-BA09-20E330FB5358@cwi.nl> Ok, so this is a real problem:-( Again, I?m not deep enough into the SSL stuff to really understand this (and specifically whether it needs a new openssl module, a new libssl, both, something else, ?.), but I?d like to think of ways to fix this before the shit hits the fan for all poor mac Python users out there, if possible. And that includes people who aren?t even aware they?re macPython users because they use some app that uses Python under the hood?.. So a couple of questions: 1. Is this fixable by Apple, by providing a security update to various OSX versions that would include a newer python/libssl/whatever? 1a. Would this still fall under Apple?s idea of ?security update?? 1b. Do we have any chance of making Apple interested in fixing this? 2. Is this fixable with an installer that would somehow override the openssl module, so that installing this one thing would make the whole Apple-Python installation work again? 3. Failing that, I assume its the end of the line for Apple-Python, and we?ll have to steer end users towards installing a python.org version. Right? 3a. If that?s the case, is there something we could ask of the pip developers, the PyPi maintainers, whoever else to help the poor end users? I.e. get them to release a version that would not say ?ssl v1 invalid foobar get lost? but in stead ?you appear to be using Apple Python which does not support current security measures, please see www.example.com for more information?. Actually, question 3a to some extent also is 2a. Regards, Jack > On 10 Jan 2017, at 20:54, Ronald Oussoren wrote: > > >> On 10 Jan 2017, at 20:43, Ronald Oussoren wrote: >> >> >>> On 10 Jan 2017, at 17:05, Jack Jansen wrote: >>> >>> I have completely ignored this whole TLS 1.0 versus TLS 1.2 security debate until know, but just now the following post came in on python-announce, which seems to suggest that TLS 1.0 is really about to be phased out: https://mail.python.org/pipermail/python-announce-list/2017-January/011437.html >>> >>> I think Python 2.7 older that 2.7.13 (i.e. including the apple-shipped Pythons) don?t support TLS 1.2 by default, which would seem to suggest that things like pip will stop working as of this summer. >>> >>> Or am I overreacting? >> >> You are not. Annoyingly Donald Stufft already noticed that Apple?s Python is problematic, but breaking for users on a major OS is apparently not a problem :-( > > Breaking Python tools is probably not really on Fastly?s radar and not something that the PyPI folks can easily avoid. > >> >> This shouldn?t be a problem for most serious development as those users likely use a separate python installation anyway, but this will affect casual users including at least some new users. > > BTW. This doesn?t just break /usr/bin/python but also the Python.org installation of 2.7 (including 2.7.13), and likely any Python.org install exception 3.6 as all installers upto 3.6 use the system OpenSSL that doesn?t support anything beyond TLS 1.0. > > Ronald > -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From kevino at theolliviers.com Thu Jan 12 13:39:31 2017 From: kevino at theolliviers.com (Kevin Ollivier) Date: Thu, 12 Jan 2017 10:39:31 -0800 Subject: [Pythonmac-SIG] apple-Python and TLS 1.0 In-Reply-To: <80FA2776-7B3B-4444-BA09-20E330FB5358@cwi.nl> References: <28C41778-AEC7-4B07-9C26-822B19709B35@mac.com> <16640175-81DE-4586-8153-ADF8ECA946BE@mac.com> <80FA2776-7B3B-4444-BA09-20E330FB5358@cwi.nl> Message-ID: On Thu, Jan 12, 2017 at 6:10 AM, Jack Jansen wrote: > Ok, so this is a real problem:-( > > Again, I?m not deep enough into the SSL stuff to really understand this > (and specifically whether it needs a new openssl module, a new libssl, > both, something else, ?.), but I?d like to think of ways to fix this before > the shit hits the fan for all poor mac Python users out there, if possible. > And that includes people who aren?t even aware they?re macPython users > because they use some app that uses Python under the hood?.. > > So a couple of questions: > > 1. Is this fixable by Apple, by providing a security update to various OSX > versions that would include a newer python/libssl/whatever? > They stopped updating OpenSSL around Lion, and that's the real reason Python's ssl module is so behind. They recommend against using OpenSSL, and steer people towards using their Cocoa equivalents instead. > 1a. Would this still fall under Apple?s idea of ?security update?? > 1b. Do we have any chance of making Apple interested in fixing this? > So long as Python for Mac uses OpenSSL, the answer is likely to be no. ANY software on a Mac that relies on the system OpenSSL has the same problem, and Apple clearly has shown no intention of providing an updated OpenSSL. The one thing that I think might make them consider it is if the Python ssl problem causes them problems internally. > 2. Is this fixable with an installer that would somehow override the > openssl module, so that installing this one thing would make the whole > Apple-Python installation work again? > Not sure about this one, but it seems like this would be problematic (e.g. system updates may undo it) and may make things even more confusing for people. Might as well just suggest they get the Python from python.org and leave it at that. > 3. Failing that, I assume its the end of the line for Apple-Python, and > we?ll have to steer end users towards installing a python.org version. > Right? > Short term, probably so, assuming the 2.7 installers start bundling their own OpenSSL like 3.x does. The only solution Apple themselves would probably accept would be for Python to have a Mac version of the SSL library that uses Cocoa instead of OpenSSL. It's probably what Python will have to do if it wants to ensure Apple isn't shipping a Python with a broken ssl module. > 3a. If that?s the case, is there something we could ask of the pip > developers, the PyPi maintainers, whoever else to help the poor end users? > I.e. get them to release a version that would not say ?ssl v1 invalid > foobar get lost? but in stead ?you appear to be using Apple Python which > does not support current security measures, please see www.example.com > for more information?. > > That is probably a question for Donald. Thanks, Kevin > Actually, question 3a to some extent also is 2a. > > Regards, > Jack > > > > On 10 Jan 2017, at 20:54, Ronald Oussoren > wrote: > > > > > >> On 10 Jan 2017, at 20:43, Ronald Oussoren > wrote: > >> > >> > >>> On 10 Jan 2017, at 17:05, Jack Jansen wrote: > >>> > >>> I have completely ignored this whole TLS 1.0 versus TLS 1.2 security > debate until know, but just now the following post came in on > python-announce, which seems to suggest that TLS 1.0 is really about to be > phased out: https://mail.python.org/pipermail/python-announce- > list/2017-January/011437.html > >>> > >>> I think Python 2.7 older that 2.7.13 (i.e. including the apple-shipped > Pythons) don?t support TLS 1.2 by default, which would seem to suggest that > things like pip will stop working as of this summer. > >>> > >>> Or am I overreacting? > >> > >> You are not. Annoyingly Donald Stufft already noticed that Apple?s > Python is problematic, but breaking for users on a major OS is apparently > not a problem :-( > > > > Breaking Python tools is probably not really on Fastly?s radar and not > something that the PyPI folks can easily avoid. > > > >> > >> This shouldn?t be a problem for most serious development as those users > likely use a separate python installation anyway, but this will affect > casual users including at least some new users. > > > > BTW. This doesn?t just break /usr/bin/python but also the Python.org > installation of 2.7 (including 2.7.13), and likely any Python.org install > exception 3.6 as all installers upto 3.6 use the system OpenSSL that > doesn?t support anything beyond TLS 1.0. > > > > Ronald > > > > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma Goldman > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG > -------------- next part -------------- An HTML attachment was scrubbed... URL: From glyph at twistedmatrix.com Fri Jan 13 20:58:53 2017 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Fri, 13 Jan 2017 17:58:53 -0800 Subject: [Pythonmac-SIG] apple-Python and TLS 1.0 In-Reply-To: <293B7DCC-A652-4445-8B22-ECD16F7B9370@theolliviers.com> References: <293B7DCC-A652-4445-8B22-ECD16F7B9370@theolliviers.com> Message-ID: <3688ED2B-3DD4-44EC-87EF-DF4633F62BEC@twistedmatrix.com> > On Jan 10, 2017, at 9:21 AM, Kevin Ollivier wrote: > > Hi Jack, > > No, I think you're spot on, this is a big problem. Actually, 2.7.9-2.7.12, even the Python.org ones, are already somewhat broken because they use Apple's ancient OpenSSL version. All the ciphers supported by that version of OpenSSL are ones that are regarded as insecure now, so most modern servers, including big ones like AWS, don't allow them anymore. Because of this you can't even download a newer OpenSSL from the OpenSSL web site using Python. :( Let's remember that the actual end-of-life here is 18 months out. It would not be desirable to "fix" this problem by clinging to TLS 1.0 even longer; Fastly is shutting it off for a lot of very good reasons. In between here and there are a variety of events, including a new OS release from apple. When it enters beta we can loudly encourage Apple to include new and better crypto with Python - that probably does not mean a new 'ssl' module, but something more like the new 'tls' module PEP that Cory Benfield has been championing (in large part as a response to this). You can see that discussion here: https://mail.python.org/pipermail/security-sig/2017-January/000126.html . Finally, system Python has a lot of issues (unrelated to this, for example, it can't be 'dtrace'd, which eliminates a ton of super-useful debugging tools, including the OS X equivalent of 'strace'), and I've been gently discouraging users from using it for years. (I say this as an ex-? myself.) Tell users to install Python (and PyPy!) from Homebrew, and they will generally have a much better time. If we do nothing, this is going to be a huge disaster. But the responsible people are highly motivated and are quite actively doing things. If you want to make sure users have a good experience, helping them out would definitely be advised :). > It surprised me to find that the Python community wasn't really aware of this problem. For one project I worked on we actually re-coded all our download code to use the Cocoa HTTPS classes via PyObjC, and this was a couple years back. Don't know how many others out there have been fighting with it. Cryptography ships with its own OpenSSL, which means you can side-step a lot of these issues; install requests[security] and you get better HTTPS. Or install from Homebrew, or python.org , or Anaconda. -glyph -------------- next part -------------- An HTML attachment was scrubbed... URL: From glyph at twistedmatrix.com Fri Jan 13 21:03:36 2017 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Fri, 13 Jan 2017 18:03:36 -0800 Subject: [Pythonmac-SIG] apple-Python and TLS 1.0 In-Reply-To: <80FA2776-7B3B-4444-BA09-20E330FB5358@cwi.nl> References: <28C41778-AEC7-4B07-9C26-822B19709B35@mac.com> <16640175-81DE-4586-8153-ADF8ECA946BE@mac.com> <80FA2776-7B3B-4444-BA09-20E330FB5358@cwi.nl> Message-ID: <52F57805-F248-4F59-88E8-696C6049143C@twistedmatrix.com> > On Jan 12, 2017, at 6:10 AM, Jack Jansen wrote: > > Ok, so this is a real problem:-( > > Again, I?m not deep enough into the SSL stuff to really understand this (and specifically whether it needs a new openssl module, a new libssl, both, something else, ?.), but I?d like to think of ways to fix this before the shit hits the fan for all poor mac Python users out there, if possible. And that includes people who aren?t even aware they?re macPython users because they use some app that uses Python under the hood?.. > > So a couple of questions: > > 1. Is this fixable by Apple, by providing a security update to various OSX versions that would include a newer python/libssl/whatever? Yes. Apple should really be including a private OpenSSL with Python. But they probably won't do that. > 1a. Would this still fall under Apple?s idea of ?security update?? No, it would probably be a Major-OS sort of thing. > 1b. Do we have any chance of making Apple interested in fixing this? It's doubtful that they will update OpenSSL directly. But they might include a new version of Python with a different approach to basic TLS (see the 'tls' module in my other response) > 2. Is this fixable with an installer that would somehow override the openssl module, so that installing this one thing would make the whole Apple-Python installation work again? Yes and no. You could fix this by replacing the 'ssl' module with a wrapper that replicates it based on 'pyOpenSSL', which is a layer over 'cryptography', but this doesn't help users bootstrap via Pip; it would be easier to just tell them to get a different Python. > > 3. Failing that, I assume its the end of the line for Apple-Python, and we?ll have to steer end users towards installing a python.org version. Right? Homebrew is by far my most preferred option (easier to get updates, easier to get PyPy, easier to make multiple versions play nicely, more tuned for developers, etc etc etc). But python.org is a reasonable option as well. And there are lots of other reasons not to tell users to use the system-provided Python. > 3a. If that?s the case, is there something we could ask of the pip developers, the PyPi maintainers, whoever else to help the poor end users? I.e. get them to release a version that would not say ?ssl v1 invalid foobar get lost? but in stead ?you appear to be using Apple Python which does not support current security measures, please see www.example.com for more information?. There's no way to do this purely from PyPI's side, but with a little help from Apple it's doable. Another option here is to build the mac Python installers differently so they're more user-friendly, and rather than a .pkg make a .app, so that users who have sufficiently little command-line expertise to be able to get something like Homebrew to behave properly would be able to get on-screen instructions and prompts that would help them get set up with a correct command linee. -glyph -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.oberndoerfer at urheberrecht.org Sun Jan 22 18:13:48 2017 From: p.oberndoerfer at urheberrecht.org (=?UTF-8?Q?Pascal_Obernd=c3=b6rfer?=) Date: Mon, 23 Jan 2017 00:13:48 +0100 Subject: [Pythonmac-SIG] Build Applet with 2.7.13 (64-bit) on 10.10.5 (and 10.6.x) Message-ID: <2f607ae2-c32a-0c0e-7572-fd1d16df45ba@urheberrecht.org> Hello, I have been using Build Applet quite extensively in the past. I now wanted to use them with 2.7.13, but if I actually build the Applet -- even for the simplest script -- the resulting Applet will not start. All I see is an entry in the system.log saying: "