Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects
Nick Coghlan schrieb am 31.08.2016 um 06:30:
> On 31 August 2016 at 04:55, Serhiy Storchaka wrote:
>> On 30.08.16 21:20, Antoine Pitrou wrote:
>>> But the performance overhead of iterating over a 1-element list
>>> is small enough (it's just an array access after a pointer dereference)
>>> that it may not be larger than the overhead of the multiple tests and
>>> conditional branches your example shows.
>>
>> Iterating over a tuple is even faster. It needs one pointer dereference
>> less.
>
> That comes at the cost of making metadata additions a bit more
> complicated though - you'd have to replace the existing tuple with a
> new one that adds your own metadata, rather than just appending to a
> list.
>
> I do think there are enough subtleties here (going from no metadata ->
> some metadata, and some metadata -> more metadata) that it makes sense
> to provide a standard API for it (excluded from the stable ABI),
> rather than expecting plugin developers to roll their own.
>
> Strawman:
>
> PyObject * PyCode_GetExtra(PyCodeObject *code, PyTypeObject *extra_type);
> int PyCode_SetExtra(PyCodeObject *code, PyObject *extra);
> int PyCode_DelExtra(PyCodeObject *code, PyTypeObject *extra_type);
>
> Then Brett's example code would become:
>
> pyjion_cache = PyCode_GetExtra(code_obj, &PyPyjion_Type);
> if (pyjion_cache == NULL) {
> pyjion_cache = PyPyjion_New();
> if (PyCode_SetExtra(code_obj, pyjion_cache) < 0) {
> /* Something went wrong, report that somehow */}
> }
> /* pyjion_cache is valid here */
>
> Making those APIs fast (for an assumed small number of simultaneously
> active interpreter plugins) and thread-safe is then an internal
> CPython implementation detail, rather than being something plugin
> writers need to concern themselves with.
Looks like a good idea. New non-trivial field, new API.
GetExtra() can be a macro that implements the "only one entry and type
pointer matches" case for speed, then call back into the list lookup for
the less common cases.
Stefan
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supported versions of OpenSSL
On 31.08.2016 01:55, Gregory P. Smith wrote: > On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburg wrote: >>> On 29.08.2016 22:16, Christian Heimes wrote: >>> In my >>> opinion it is more than reasonable to ditch 1.0.1 and earlier. >> >> I want you to consider the consequences of doing this carefully. >> > > We have. The proposal now stands at: We're free to ditch 1.0.1 and earlier > support in 3.7 as soon as we have a need for a 1.0.2 specific API. > > There don't seem to be any important negative consequences of doing so. Uhm, what about not being able to run Python unless you are willing to stop taking benefit of OS vendor supplied OpenSSL security fixes ? In all this discussion I have yet to find a compelling security relevant argument for using an 1.0.2 API which is so important that we cannot make this optional at runtime. The only argument Christian reported was this one: """ > BTW: Are there any features in 1.0.2 that we need and would warrant > dropping support for 1.0.1 earlier than Ubuntu 14.04 LTS ? Yes, there are features I want to use, e.g. proper hostname verification. Python's post-handshake verification is a hack and leads to information disclosure. """ Regarding that argument: hostname validation can be done in 1.0.1 by providing a verification hook handler. That's intended and by design, not a hack. 1.0.2 comes with support for hostname validation making this a little easier (you still have to set this up, though). So essentially, the only argument so far has been that we can remove some support code and let 1.0.2 take care of this. That's a maintenance argument, not a security one. And the code in question has been rather stable, so it doesn't add much maintenance overhead: https://hg.python.org/cpython/annotate/default/Lib/ssl.py#l195 For dropping Python support on older platforms, I'd expect to at least see an argument such as: 1.0.1 has a security flaw which cannot be addressed by design (e.g. a missing crypto feature which is essential for working with modern SSL servers). >> Crypto is important to have, but at the same time it's not >> essentially for everything you do in Python, e.g. you can >> easily run data analysis scripts or applications without ever >> touching the ssl module. > > While technically true, the ssl module is required to fetch and install > software via pip which for casual users means it is essential. People can > always operate without it if they are willing to download and build the > libraries they need manually. > >> Yet, a move to require OpenSSL 1.0.2 for Python 3.7 will make >> it impossible to run such apps on systems that still use OpenSSL >> 1.0.1, e.g. Ubuntu 14.04 or CentOS 7. >> > > Not important. That isn't something we need to worry about. Compiling a new > libssl is easy. People using systems that are 4+ years old by the time 3.7 > comes out who expect new software to compile and just work are expecting > too much. Perhaps, but industry OSes are not upgraded that often, so it's not unusual to run into a system where you'd like to get Python working on an LTS OS version which is still maintained but doesn't use the latest and greatest software versions. > I find that users of such systems either use only what their distro itself > supplies (ie: ancient versions at that point) or are fully comfortable > building any dependencies their own software needs. If they are comfortable > building a CPython runtime in the first place, they should be comfortable > building required libraries. Nothing new there. Why do you assume that people will compile their own CPython on such systems ? It's well possible, and probably more likely, that they want to run a binary version of the application on such a platform, only to find that it doesn't run because of a missing OpenSSL 1.0.2 API (the libssl.so.1.0 will still be available, but not expose the requested API - the lib version of OpenSSL did not change between 1.0.1 and 1.0.2). >> Why not make the 1.0.2 and 1.1.0 support optional as we do >> in so many other situations for various systems and libs ? >> > > In general, conditional compilation complicates code and adds a maintenance > burden. The sooner we can ditch older versions, the cleaner and easier to > maintain our code is. I think we need to find the right balance here. A few lines of conditional code vs. Python not running on a system at all. And just to be clear, since some people appear to think that I want to make them work for me for free (something I find a bit bizarre given how much time I have invested in Python development - you are benefiting from the code I've written just as much as I am from the code you have written): We are using our own egenix-pyopenssl package which comes with OpenSSL 1.0.2 and we do take on the challenge to support this on multiple platforms, including older ones. So the argument is somewhat pointless. I am thinking of Python users out there who are running on LTS OS releases simply because their IT
Re: [Python-Dev] Supported versions of OpenSSL
On 2016-08-30 22:07, M.-A. Lemburg wrote: > That was not my point. It's unfortunate that Python depends on > a library which is inevitably going to need updates frequently, > and which then may have the implication that Python won't compile on > systems which don't ship with more recent OpenSSL libs - even > if your application doesn't even need ssl at all. That's wrong. ssl support is optional. hashlib builds without OpenSSL, too. > Please reread what I suggested: to postpone the switch to require > OpenSSL 1.0.2 by one Python release version. And in my reply I then > put this into more context, saying that your schedule will likely > work out. OpenSSL 1.0.2 requirement is already postponed to 3.7. > Postponing this should not introduce more work for anyone; if you'd > like to add support for 1.0.2 feature early this can also easily be > done by making such support optional depending on which OpenSSL > lib Python is compiled against. This takes a few #ifdefs, nothing > more. No, the SSL module will require features that are OpenSSL 1.0.2 only. >>> This doesn't sound like a feature worth breaking compatibility >>> to me. >> >> It does. > > Why not make the 1.0.2 and 1.1.0 support optional as we do > in so many other situations for various systems and libs ? Please read my mails. I gave you two reasons. First it's going to make my work harder and I'm not willing to invest extra work to supported deprecated, unsupported and insecure versions. Second I'm going to require features that are 1.0.2 only. Christian ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supported versions of OpenSSL
On Wed, 31 Aug 2016 10:31:12 +0200 "M.-A. Lemburg" wrote: > > I am thinking of Python users out there who are running on LTS > OS releases simply because their IT doesn't let them run anything > else. There is a solution nowadays, which is to use Anaconda (or Miniconda). Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supported versions of OpenSSL
On 2016-08-31 10:31, M.-A. Lemburg wrote: > In all this discussion I have yet to find a compelling security > relevant argument for using an 1.0.2 API which is so important > that we cannot make this optional at runtime. > > The only argument Christian reported was this one: > > """ >> BTW: Are there any features in 1.0.2 that we need and would warrant >> dropping support for 1.0.1 earlier than Ubuntu 14.04 LTS ? > > Yes, there are features I want to use, e.g. proper hostname > verification. Python's post-handshake verification is a hack and leads > to information disclosure. > """ > > Regarding that argument: hostname validation can be done > in 1.0.1 by providing a verification hook handler. That's > intended and by design, not a hack. 1.0.2 comes with > support for hostname validation making this a little easier > (you still have to set this up, though). Are you willing to do implement and maintain this callback? Are you willing to do all work? Are you aware how many security bugs we had in our own verification code? I'm aware of at least two critical bugs. Christian ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supported versions of OpenSSL
On 31.08.2016 10:50, Christian Heimes wrote: > On 2016-08-31 10:31, M.-A. Lemburg wrote: >> In all this discussion I have yet to find a compelling security >> relevant argument for using an 1.0.2 API which is so important >> that we cannot make this optional at runtime. >> >> The only argument Christian reported was this one: >> >> """ >>> BTW: Are there any features in 1.0.2 that we need and would warrant >>> dropping support for 1.0.1 earlier than Ubuntu 14.04 LTS ? >> >> Yes, there are features I want to use, e.g. proper hostname >> verification. Python's post-handshake verification is a hack and leads >> to information disclosure. >> """ >> >> Regarding that argument: hostname validation can be done >> in 1.0.1 by providing a verification hook handler. That's >> intended and by design, not a hack. 1.0.2 comes with >> support for hostname validation making this a little easier >> (you still have to set this up, though). > > Are you willing to do implement and maintain this callback? Are you > willing to do all work? Maintain: yes, if needed. It is already implemented, so that part isn't hard :-) > Are you aware how many security bugs we had in our own verification > code? I'm aware of at least two critical bugs. Not that many, given that the host name validation is more a best practices art rather than one where all participants implement the standards: http://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid&ignore=file%3Acontent&%40search_text=match_hostname&submit=search&status=-1%2C1%2C2%2C3 The only critical bug I could find was this one (NUL bytes in subjectAltName): http://bugs.python.org/issue18709 but as I understand, the true origin of the bug was an OpenSSL function, not the host name matching code in Python. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Aug 31 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supported versions of OpenSSL
On 31.08.2016 10:43, Antoine Pitrou wrote: > On Wed, 31 Aug 2016 10:31:12 +0200 > "M.-A. Lemburg" wrote: >> >> I am thinking of Python users out there who are running on LTS >> OS releases simply because their IT doesn't let them run anything >> else. > > There is a solution nowadays, which is to use Anaconda (or Miniconda). Sure, or use ActivePython or eGenix PyRun :-) But is that really what we want to tell people ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Aug 31 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supported versions of OpenSSL
Le 31/08/2016 à 11:33, M.-A. Lemburg a écrit : > On 31.08.2016 10:43, Antoine Pitrou wrote: >> On Wed, 31 Aug 2016 10:31:12 +0200 >> "M.-A. Lemburg" wrote: >>> >>> I am thinking of Python users out there who are running on LTS >>> OS releases simply because their IT doesn't let them run anything >>> else. >> >> There is a solution nowadays, which is to use Anaconda (or Miniconda). > > Sure, or use ActivePython or eGenix PyRun :-) Uh, right, I was being employer-biased here, sorry. > But is that really what we want to tell people ? Why not? python.org does not provide official binaries for Linux or Unix systems (except OS X), and most people don't like compile their infrastructure themselves. People who want an up-to-date Python can either use: - use the python.org binaries on OS X and Windows - use a recent OS providing a recent Python version (for Linux and Unix variants) - use a vendor-supported backport on old OSes (if so provided, for example on RedHat with Software Collections?) - use a third party-supported backport on old OSes (ActivePython, eGenix PyRun, etc.) - as a last resort, hand-compile their Python, in which case they have to be careful to gather the required dependencies Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supported versions of OpenSSL
On 2016-08-31 11:33, M.-A. Lemburg wrote: > On 31.08.2016 10:50, Christian Heimes wrote: >> On 2016-08-31 10:31, M.-A. Lemburg wrote: >>> In all this discussion I have yet to find a compelling security >>> relevant argument for using an 1.0.2 API which is so important >>> that we cannot make this optional at runtime. >>> >>> The only argument Christian reported was this one: >>> >>> """ BTW: Are there any features in 1.0.2 that we need and would warrant dropping support for 1.0.1 earlier than Ubuntu 14.04 LTS ? >>> >>> Yes, there are features I want to use, e.g. proper hostname >>> verification. Python's post-handshake verification is a hack and leads >>> to information disclosure. >>> """ >>> >>> Regarding that argument: hostname validation can be done >>> in 1.0.1 by providing a verification hook handler. That's >>> intended and by design, not a hack. 1.0.2 comes with >>> support for hostname validation making this a little easier >>> (you still have to set this up, though). >> >> Are you willing to do implement and maintain this callback? Are you >> willing to do all work? > > Maintain: yes, if needed. > > It is already implemented, so that part isn't hard :-) No, it is not implemented as callback. It is implemented as post verification step, which is wrong. >> Are you aware how many security bugs we had in our own verification >> code? I'm aware of at least two critical bugs. > > Not that many, given that the host name validation is more > a best practices art rather than one where all participants > implement the standards: > > http://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid&ignore=file%3Acontent&%40search_text=match_hostname&submit=search&status=-1%2C1%2C2%2C3 > > The only critical bug I could find was this one (NUL bytes > in subjectAltName): > > http://bugs.python.org/issue18709 > > but as I understand, the true origin of the bug was an OpenSSL > function, not the host name matching code in Python. Ah, I forgot about the NULL bytes issue. The bug is not caused by a problem in OpenSSL. We just the wrong function to convert General Name ASN.1 strings to unicode. Then there are four critical bugs: * NULL bytes in SAN * wrong, insecure RFC for wildcard matching * DoS caused excessive regular expression matching for wildcards * invalid handling of IDNA for wildcard matching IP address verification is still wrong, too. This was my last reply to your mails on this topic. It's clear to me that you are not open to Cory's, Nick's or my arguments and that you won't change your position. More replies are just a waste of my limited time. Instead I'm going to focus on a PEP to define OpenSSL support and to auto-deprecate unsupported OpenSSL versions. The PEP is a very high chance to get accepted. Everybody except you support the plan. Christian ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations
On 31 August 2016 at 15:40, Guido van Rossum wrote: > On Tuesday, August 30, 2016, Nick Coghlan wrote: >> What if we included local variable annotations in func.__annotations__ >> as cells, like the entries in func.__closure__? >> >> We could also use that as a micro-optimisation technique: once the >> type annotation cell is populated, CPython would just use it, rather >> than re-evaluating the local variable type annotation expression every >> time the function is called. > > But what runtime use have the annotations on locals? They are not part of > any inspectable interface. I don't want to spend any effort on them at > runtime. (Just the bit that they are treated as locals.) I guess as long as they're included somewhere in the AST for the function body, I don't mind if the translation to bytecode throws them away - that's essentially saying that a function level type annotation is effectively interpreted as if it was: if False: __annotations__[] = So the code generator will pick up syntax errors during normal execution, but not runtime errors (since the expression never actually gets evaluated). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supported versions of OpenSSL
On 2016-08-30 18:00, Antoine Pitrou wrote: > On Sun, 28 Aug 2016 22:40:11 +0200 > Christian Heimes wrote: >> >> Here is the deal for 2.7 to 3.5: >> >> 1) All versions older than 0.9.8 are completely out-of-scope and no >> longer supported. >> >> 2) 0.9.8 is semi-support. Python will still compile and work with 0.9.8. >> However we do NOT promise that is secure to run 0.9.8. We also require a >> recent version. Patch level 0.9.8zc from October 2014 is reasonable >> because it comes with SCSV fallback (CVE-2014-3566). >> >> 3) 1.0.0 is irrelevant. Users are either stuck on 0.9.8 or are able to >> upgrade to 1.0.1+. Let's not support it. >> >> 4) 1.0.1 is discouraged but still supported until its EOL. >> >> 5) 1.0.2 is the recommend version. >> >> 6) 1.1 support will be added by #26470 soon. >> >> 7) LibreSSL 2.3 is supported but with a slightly limited feature set. > > Can you expand briefly how "limited" the feature set is? Does it only > disable some arcane features, so that e.g. asyncio + TLS supports works > fine? > > Other than that, it all sounds good to me. I honestly don't know because I lack the expertise and knowledge. LibreSSL has removed some features (env vars like SSL_CERT_FILE, ENGINE support) and added some other features. I cannot tell if stdlib ssl + LibreSSL is even secure. It probably is *if and only if* LibreSSL is 100% compatible to OpenSSL. Christian ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supported versions of OpenSSL
On 31.08.2016 12:05, Christian Heimes wrote: > This was my last reply to your mails on this topic. It's clear to me > that you are not open to Cory's, Nick's or my arguments and that you > won't change your position. More replies are just a waste of my limited > time. I *am* open to arguments, but so far I have not seen a compelling one which strikes the right balance. And if you have read my replies, I'm only suggesting to postpone the switch to 1.0.2 by one release and even there I said that it's not all that dramatic if this doesn't happen due to the way the timelines for 3.6 and 3.7 work. What I am seriously worried about, is the next step ... > Instead I'm going to focus on a PEP to define OpenSSL support and to > auto-deprecate unsupported OpenSSL versions. The PEP is a very high > chance to get accepted. Everybody except you support the plan. ... which would then mean: Python's compatibility roadmap will be dictated by OpenSSL. I won't buy into that, sorry. Crypto is a helper in certain situations, it's not what Python is all about. We should not let OpenSSL dictate how and when we deprecate platforms or OS versions. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Aug 31 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations
On Tue, Aug 30, 2016 at 07:15:55PM -0700, Guido van Rossum wrote: > On Tue, Aug 30, 2016 at 6:00 PM, Steven D'Aprano wrote: > > On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote: > >> I'm happy to present PEP 526 for your collective review: > > > > Are you hoping to get this in before 3.6 beta? Because I'm not sure I > > can give this much attention before then, but I really want to. > > Yes I am hoping for that. Unlike PEP 484, this PEP is forward-looking > (more like PEP 492, async/await), and the sooner we can get it in the > sooner people who want to use it won't have to worry about supporting > older Python versions. (And am I ever looking forward to the day when > Python 3.5 counts as "older". :-) Indeed :-) Okay, I'll bump it up my list of priorities. (Sleep? Who needs that? :-) -- Steve ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supported versions of OpenSSL
On 31 August 2016 at 19:33, M.-A. Lemburg wrote: > On 31.08.2016 10:43, Antoine Pitrou wrote: >> On Wed, 31 Aug 2016 10:31:12 +0200 >> "M.-A. Lemburg" wrote: >>> >>> I am thinking of Python users out there who are running on LTS >>> OS releases simply because their IT doesn't let them run anything >>> else. >> >> There is a solution nowadays, which is to use Anaconda (or Miniconda). > > Sure, or use ActivePython or eGenix PyRun :-) > > But is that really what we want to tell people ? I'm personally entirely comfortable with it, as large organisations running community supported code without investing back into the upstream community accordingly is currently a major problem in the Python ecosystem - many technical folks find it easier to reach out to the open source community for better support than they do to go into battle with their own Finance departments to argue for appropriate investment in managing their supply chain. Unfortunately, while that's an entirely understandable reaction to an all too common form of organisational dysfunction, it's also a major contributor to community volunteer burnout. Accordingly, we need more of these organisations to either fund paid upstream development directly (e.g. by assigning their own staff to do it or hiring existing core developers), or else for them to start paying commercial redistributors, and making it clear that they expect those redistributors to fund ongoing upstream development and maintenance activities on their behalf. For folks that are already paying commercial redistributors, we need them to be asking pointed questions of their support managers, like "We're paying you for commercial CPython support, so why don't you have anyone assigned to work on it full time?" Adopting that strategy isn't without its risks - some organisations may react by banning the use of Python entirely and go looking for a less assertive community (or one with better established funding sources), rather than finding ways to pay for suitable infrastructure support arrangements. However, hopefully folks within such organisations will understand their political environment well enough to know whether or not they need to stay under the executive radar. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supported versions of OpenSSL
On 31 August 2016 at 20:20, M.-A. Lemburg wrote: > ... which would then mean: Python's compatibility roadmap will > be dictated by OpenSSL. > > I won't buy into that, sorry. Crypto is a helper in certain > situations, it's not what Python is all about. We should not > let OpenSSL dictate how and when we deprecate platforms or > OS versions. It won't dictate general support for those platforms, it will dictate support for the *ssl module* on those platforms. If someone isn't making secure network connections from Python, things will work fine. If a redistributor is stepping in to provide the assertion that the network connection is secure despite our upstream misgivings, things will work fine. Connections will only fail in cases where neither we nor a redistributor are prepared to make the assertion that a requested secure network connection will actually be secure. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations
On 31 August 2016 at 13:09, Nick Coghlan wrote: > I guess as long as they're included somewhere in the AST for the > function body, I don't mind if the translation to bytecode throws them > away - that's essentially saying that a function level type annotation > is effectively interpreted as if it was: > > if False: > __annotations__[] = > > So the code generator will pick up syntax errors during normal > execution, but not runtime errors (since the expression never actually > gets evaluated). > Nick, you are right, in current implementation they are included in AST in exactly the same way as in classes and modules, but compiler throws them away. -- Ivan ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supported versions of OpenSSL
On 31.08.2016 14:02, Nick Coghlan wrote: > On 31 August 2016 at 20:20, M.-A. Lemburg wrote: >> ... which would then mean: Python's compatibility roadmap will >> be dictated by OpenSSL. >> >> I won't buy into that, sorry. Crypto is a helper in certain >> situations, it's not what Python is all about. We should not >> let OpenSSL dictate how and when we deprecate platforms or >> OS versions. > > It won't dictate general support for those platforms, it will dictate > support for the *ssl module* on those platforms. If someone isn't > making secure network connections from Python, things will work fine. > If a redistributor is stepping in to provide the assertion that the > network connection is secure despite our upstream misgivings, things > will work fine. > > Connections will only fail in cases where neither we nor a > redistributor are prepared to make the assertion that a requested > secure network connection will actually be secure. Yes, you can view it that way. Your car works, but access to fuel is severely limited ;-) The way things are developing around Python, if pip doesn't work, your Python installation cannot be considered working. Hmm, perhaps pip ought to fallback to curl or wget if there's no ssl module. Or we move away entirely from HTTPS and use properly signed Python packages - ah, nevermind, it's not the first time that have different views than many other core devs. That's fine. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Aug 31 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supported versions of OpenSSL
I think it's time for this thread to stop as everyone seems to be talking in circles. Christian said he's going to write a PEP so let's wait for that before discussing this any further so we have a concrete proposal to focus around. On Wed, 31 Aug 2016 at 05:04 Nick Coghlan wrote: > On 31 August 2016 at 20:20, M.-A. Lemburg wrote: > > ... which would then mean: Python's compatibility roadmap will > > be dictated by OpenSSL. > > > > I won't buy into that, sorry. Crypto is a helper in certain > > situations, it's not what Python is all about. We should not > > let OpenSSL dictate how and when we deprecate platforms or > > OS versions. > > It won't dictate general support for those platforms, it will dictate > support for the *ssl module* on those platforms. If someone isn't > making secure network connections from Python, things will work fine. > If a redistributor is stepping in to provide the assertion that the > network connection is secure despite our upstream misgivings, things > will work fine. > > Connections will only fail in cases where neither we nor a > redistributor are prepared to make the assertion that a requested > secure network connection will actually be secure. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Patch reviews
Hi, I have 7 patches for 3.6 ready for merging. The new features were discussed on Security-SIG and reviewed by Victor or GPS. The patches just need one final review and an ACK. The first three patches should land in 2.7, 3.4 and 3.5, too. http://bugs.python.org/issue26470 Make OpenSSL module compatible with OpenSSL 1.1.0 https://bugs.python.org/issue27850 Remove 3DES from cipher list (sweet32 CVE-2016-2183) Also adds ChaCha20 Poly1305 http://bugs.python.org/issue27691 X509 cert with GEN_RID subject alt name causes SytemError http://bugs.python.org/issue27866 ssl: get list of enabled ciphers https://bugs.python.org/issue27744 Add AF_ALG (Linux Kernel crypto) to socket module http://bugs.python.org/issue16113 Add SHA-3 and SHAKE (Keccak) support http://bugs.python.org/issue26798 add BLAKE2 to hashlib Christian ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
