Mailman 3 April 2018 - Python-Dev

gdb support could use some love
by Ned Deily 05 Apr '18

05 Apr '18

There are a bunch of open issues regarding gdb support including one with a PR in need of review for 3.6+. I imagine that there are duplicates at least among the more recent open issues. If you use and are familiar with the gdb macros, it would be really swell if you could take some time to review some of those open issues. Thanks! --Ned https://bugs.python.org/issue29673 https://github.com/python/cpython/pull/6126 https://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=g… -- Ned Deily nad(a)python.org -- []

4 7

ssl module and LibreSSL CVE-2018-8970
by Christian Heimes 05 Apr '18

05 Apr '18

Hi, I like to share the story of a critical security bug with you. Contrary to other issues in TLS/SSL, it's a story with happy ending. Nobody was harmed. The bug was fixed before it affected the general population. Introduction ------------ Python's ssl.match_hostname() function was a source of several CVEs and other security bugs. After a long struggle, I decided to drop support for old OpenSSL releases and uses a new OpenSSL method to offload host name verification to OpenSSL. The improvement [1] eventually landed in Python 3.7. Nowadays OpenSSL verifies host name or IP address during the TLS/SSL handshake. Later I discovered that LibreSSL <= 2.6 did not have X509_VERIFY_PARAM_set1_host() [2]. We had to temporarily suspend support for LibreSSL. About two months later, LibreSSL caught up and released version 2.7.0 with support for the function. The bug ------- One day after the release of LibreSSL 2.7.0, I started to port Python 3.7 to LibreSSL. In matter of minutes I got the ssl module to compile and work with LibreSSL. All tests were passing -- except for negative the host name verification tests. LibreSSL was accepting all invalid host names as correct! Python's vigorous test suite had discovered a critical security bug in LibreSSL. It turned out that LibreSSL copied the implementation of X509_VERIFY_PARAM_set1_host(param, name, namelen) from BoringSSL and the documentation from OpenSSL. BoringSSL's implementation didn't support the special case of 0 as namelen parammeter. OpenSSL supports namelen = 0, which is interpreted as namelen=strlen(name). It is documented in OpenSSL's man page and was even recommended on OpenSSL's wiki as preferred way. Happy Ending ------------ So I got in contact with LibreSSL's security team and BoringSSL's security team [3]. Less than a day later, both libraries released fixes for the bug [4]. Mitre has assigned CVE-2018-8970 [5] to the bug. Disaster averted! BoringSSL's security issue [3] contains more information. Adam Langley lifted the restriction about an hour ago. I like to thank Bob Beck (LibreSSL), Adam Langley (Google) and David Benjamin (Google) for their assistance and cooperation. Regards, Christian [1] https://bugs.python.org/issue31399 [2] https://github.com/libressl-portable/portable/issues/381 [3] https://bugs.chromium.org/p/chromium/issues/detail?id=824799 [4] https://www.libressl.org/releases.html [5] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8970

3 2

2.7.15 release schedule
by Benjamin Peterson 05 Apr '18

05 Apr '18

Hi all, It's that time yet again: I'm planning to release 2.7.15 release candidate 1 on April 14 and a final release two weeks later on April 28.

1 0

Enum, Flag, __contains__, and False vs TypeError
by Ethan Furman 04 Apr '18

04 Apr '18

API question. Background: ---------- When doing checks such as --> 3 in [4, 5, 6] --> 'test' in {'test':True, 'live':False} the result is True or False. When doing checks such as --> 3 in 'hello world' --> [4, 5, 6] in {'test':True, 'live':False} the result is a TypeError. The general rule seems to be that if it is impossible for the in-question object to be in the container object then a TypeError is raised, otherwise True or False is returned. Question 1: ---------- (A) A standard Enum class is a container of Enum members. It cannot hold anything else. However, it has been returning False both in cases where the in-question object was an Enum of a different class (a Fruit in a Color, for example) and when the in-question object was not even an Enum ('apple' in Fruit, for example). (B) The waters get even more muddied when Fruit has a str mixin, so `Fruit.APPLE == 'apple' is True` -- in that case, should `'orange' in Fruit` return True, False, or raise TypeError? Question 2: ---------- (A) The new Flag type allows `in` tests on the members themselves; so, for example: --> SomeFlag.ONE in SomeFlag.One|SomeFlag.TWO True The question, of course, is what to do when a non-Flag member is tested for: --> 'apple' in SomeFlag.ONE # False or TypeError? --> 2 in SomeFlag.TWO # True or TypeError? (B) And, of course, the same muddier question arises with IntFlag, where SomeFlag.TWO == 2 is True. My thoughts: ----------- For question 1A (pure Enum): I'm thinking a TypeError should be raised when the in-question object is not an Enum member of any kind -- it simply is not possible for that object to ever be in an Enum, and is surely a bug. For question 1B (mixed Enum): if 1A is TypeError, then 1B should also be TypeError at least for non-mixin in-question types (so checking for 1 in StrEnum would be a TypeError), but I'm torn between TypeError and True/False for cases where the in-question type matches the mixin type ('apple' in StrEnum).... On the one hand, even though an Enum member might be equal to some other type, that other type will not have the Enum attributes, etc, and a True answer would lead one to believe you could access `.name` and `.value`, etc., while a False answer would lead one to believe there was no match even though equality tests pass; on the other hand, how strong is the "container" aspect of a mixed Enum? How often is the test `'apple' in Fruit` meant to discover if you have a Fruit member vs whether you have something that could be a Fruit member? Also, how important is it to be consistent with IntFlag, which I definitely think should return True/False for int checks? For question 2A (pure Flag): I'm comfortable sticking with a TypeError (assuming we switch to TypeError for 1A). For question 2B (int Flag): I think a TypeError if the in-question object is not an int is appropriate (assuming TypeError for 1A and 2A), but if it is an int, True/False seems the better path. My reasoning being that Flag and IntFlag are more similar to sets than lists, and IntFlag is specifically meant to work with ints, and a test of `2 in some_int_flags` is more concerned with a flag being set than with .name or .value attributes that may or may not exist on the in-question object. Any and all thoughts appreciated. -- ~Ethan~

6 8

Python Bug Tracker
by Agnostic Dev 04 Apr '18

04 Apr '18

Apologies if this is not the correct place to report this, but I am seeing outages on bugs.python.org. I am in the Chicago area so maybe this is a regional issue or possibly the site is being update, but I wanted to report it. Matt Eaton (Agnosticdev)

2 2

Are undocumented functions part of the stable ABI?
by Jeroen Demeyer 04 Apr '18

04 Apr '18

Hello, I have a question about PEP 384: can undocumented functions ever be considered as part of the stable ABI? With undocumented, I mean not appearing in the "Python/C API Reference Manual". Whatever the answer to this question is, it would be good to make it explicit in PEP 384. I am in particular asking about functions starting with PyCFunction_ appearing in Include/methodobject.h Thanks, Jeroen.

2 1

Hi, I am amar :)
by amar 04 Apr '18

04 Apr '18

Hi, all. Quick joke, Do you know why all functional programmers are anarchists? Because they want to get rid of the state! :D I know there are a lot more important issues than this, but i feel this is important too. I wish some people could take a look at Python/Cpython pull request #6343[1] and the reopened PR #6362[2]. Little background here, I am a science student working on GIS(Geospatial Information Systems) Web Processing Service as a hobby project. I am a human too, i like jokes. But not at the expense of truth. I hope i can make more meaningful contributions in the future! [1]https://github.com/python/cpython/pull/6343 [2] https://github.com/python/cpython/pull/6362#issuecomment-378174084

3 2

<int> in <str>
by Ethan Furman 04 Apr '18

04 Apr '18

This behavior was recently brought to my attention [1]: --> 1 in 'hello' Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'in <string>' requires string as left operand, not int However, in any other collection (set, dict, list, tuple, etc), the answer would be False. Does anyone remember the reason why an exception is raised in the string instance instead of returning False? -- ~Ethan~ [1] https://bugs.python.org/msg314900

5 4

building extensions as builtins is broken in 3.7
by Pablo Galindo Salgado 03 Apr '18

03 Apr '18

Hi, I am working on the release blocker https://bugs.python.org/issue32232. I tried to apply the patch proposed by Matthias Klose and I found that it works on Unix but it fails to build on Windows (probably because circular imports). I tried to add some tests but after some work on the problem and some comments by Ned Deily I am starting to think that the test for this is basically compiling the whole interpreter with static linking of the built-ins and run the whole test suite. This has to be done as a new build target on Travis. I did some experiments with this following: https://wiki.python.org/moin/BuildStatically But I run into multiple linking errors. The Travis build hangs forever and then fails in the best case. Here is an example of what I am talking: https://github.com/pablogsal/cpython/pull/1 In this PR you can see the patch and the static linking configured as per above and the Travis output. I am happy to work on this as long as someone can tell me what is the appropriate course of action. Thank you very much for your time!

1 0

IDLE colorizer
by MRAB 02 Apr '18

02 Apr '18

A thread on python-ideas is talking about the prefixes of string literals, and the regex used in IDLE. Line 25 of Lib\idlelib\colorizer.py is: stringprefix = r"(?i:\br|u|f|fr|rf|b|br|rb)?" which looks slightly wrong to me. The \b will apply only to the first choice. Shouldn't it be more like: stringprefix = r"(?:\b(?i:r|u|f|fr|rf|b|br|rb))?" ?

4 5