Mailman 3 February 2019 - Python-Dev

Request review for bpo-35153
by Cédric Krier 17 Feb '19

17 Feb '19

Hi, A few months ago, I submitted bpo-35153 with a PR to allow to set headers from xmlrpc.client.ServerProxy. Is there a core developer willing to review it? It will be great to have it for Python 3.8. https://bugs.python.org/issue35153 https://github.com/python/cpython/pull/10308 Thanks, -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.krier(a)b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/

1 0

[RELEASE] Python 2.7.16 release candidate 1
by Benjamin Peterson 16 Feb '19

16 Feb '19

I'm pleased to announce the immediate availability of Python 2.7.16 release candidate 1. This is a prerelease for yet another bug fix release in the Python 2.7.x series. It includes over 100 fixes over Python 2.7.15. See the changelog at https://raw.githubusercontent.com/python/cpython/baacaac06f93dd624c9d7b3bac… for full details. Downloads are at: https://www.python.org/downloads/release/python-2716rc1/ Please test your software against the new release and report any issues to https://bugs.python.org/ If all goes according to plan, Python 2.7.16 final will be released on March 2. All the best, Benjamin

1 0

Is distutils.util.get_platform() the "current" or the "target" platform
by Steve Dower 16 Feb '19

16 Feb '19

As part of adding ARM32 support for Windows, we need to enable cross-compilation in distutils. This is easy enough, though it requires somehow getting the target platform as well as the current platform. Right now, the change at https://github.com/python/cpython/pull/11774 adds a get_target_platform() function for this and updates (as far as I can tell) all uses of get_platform() to use this instead. I would rather just change get_platform() to return the target platform. The current docs are somewhat vague on exactly what this function does, and I suspect have been mostly written from an "always build from source" mentality that may have implied, but not explicitly considered cross-compilation. https://docs.python.org/3/distutils/apiref.html#distutils.util.get_platform "Return a string that identifies the current platform. This is used mainly to distinguish platform-specific build directories and platform-specific built distributions." So it says "current" platform, explicitly says that "os.uname()" is the source, but then goes on to say: "For non-POSIX platforms, currently just returns sys.platform." Which is incorrect, as sys.platform is always "win32" always but get_platform() already returns "win-amd64" for 64-bit builds. And also: "For Mac OS X systems the OS version reflects the minimal version on which binaries will run (that is, the value of MACOSX_DEPLOYMENT_TARGET during the build of Python), not the OS version of the current system." So it seems like this function is already returning "the default platform that should be used when building extensions" - ignoring bugs in libraries that monkeypatch distutils, the "--plat-name" option should entirely override the return value of this function. Given this, does it seem to be okay to have it determine and return the target platform rather than the host platform? Right now, that would only affect the new target of building for win-arm32, but I would also like to update the documentation to make it more about how this value should be used rather than where it comes from. Any objections or concerns? Cheers, Steve

3 5

OpenSSL 1.1.1 fixes merged into Python 2.7
by Victor Stinner 15 Feb '19

15 Feb '19

Hi, I reviewed and merged pull requests written by my colleague Charalampos Stratakis to backport OpenSSL 1.1.1 fixes into the future Python 2.7.16. Benjamin Peterson (Python 2.7 release manager) wrote me: "I would very much like to see 1.1.1 support in a Python 2.7 release." These changes are backports of Python 3.6 changes written by Christian Heimes. With these changes, Python 2.7 becomes more secure and should be closer to Python 3.6 security. I apologize for merging these changes late in 2.7.16 devcycle, but we were very busy with higher priority issues :-( I hope that 2.7.16 release candidate will provide enough time to test properly these changes (and fix regressions if any). So far, I'm only aware of one issue on one specific buildbot worker, but I'm not sure that the test failures are regressions caused by merged ssl changes (the worker was offline for 1 month for an unknown reason): https://bugs.python.org/issue33570 Summary of the ssl changes: (*) ssl.SSLContext is now created with secure default values. The options OP_NO_COMPRESSION, OP_CIPHER_SERVER_PREFERENCE, OP_SINGLE_DH_USE, OP_SINGLE_ECDH_USE, OP_NO_SSLv2 (except for PROTOCOL_SSLv2), OP_NO_SSLv3 (except for PROTOCOL_SSLv3) are set by default. The initial cipher suite list contains only "HIGH" ciphers, no "NULL" ciphers and no "MD5" ciphers (except for PROTOCOL_SSLv2). (*) OpenSSL 1.1.1 has TLS 1.3 cipher suites enabled by default. The suites cannot be disabled with SSLContext.set_ciphers(). (*) Add a new ssl.OP_ENABLE_MIDDLEBOX_COMPAT constant (*) Tools/ssl/multissltests.py has been updated for OpenSSL 1.1.1. I merged 4 changes into 2.7: commit c49f63c1761ce03df7850b9e0b31a18c432dac64 Author: stratakis <cstratak(a)redhat.com> Date: Fri Feb 15 14:17:12 2019 +0100 [2.7] bpo-33570: TLS 1.3 ciphers for OpenSSL 1.1.1 (GH-6976) (GH-8760) (GH-10607) Change TLS 1.3 cipher suite settings for compatibility with OpenSSL 1.1.1-pre6 and newer. OpenSSL 1.1.1 will have TLS 1.3 cipers enabled by default. Also update multissltests to test with latest OpenSSL. Signed-off-by: Christian Heimes <christian(a)python.org>. (cherry picked from commit 3e630c541b35c96bfe5619165255e559f577ee71) Co-authored-by: Christian Heimes <christian(a)python.org> commit b8eaec697a2b5d9d2def2950a0aa50e8ffcf1059 Author: stratakis <cstratak(a)redhat.com> Date: Fri Feb 15 15:24:11 2019 +0100 [2.7] bpo-28043: improved default settings for SSLContext (GH-10608) The options OP_NO_COMPRESSION, OP_CIPHER_SERVER_PREFERENCE, OP_SINGLE_DH_USE, OP_SINGLE_ECDH_USE, OP_NO_SSLv2 (except for PROTOCOL_SSLv2), and OP_NO_SSLv3 (except for PROTOCOL_SSLv3) are set by default. The initial cipher suite list contains only HIGH ciphers, no NULL ciphers and MD5 ciphers (except for PROTOCOL_SSLv2). (cherry picked from commit 358cfd426ccc0fcd6a7940d306602138e76420ae) commit 28eb87f4f558952f259fada7be1ab5b31b8a91ef (upstream/2.7, 2.7) Author: stratakis <cstratak(a)redhat.com> Date: Fri Feb 15 17:18:58 2019 +0100 Fixup from test_ssl test_default_ecdh_curve (GH-11877) Partial backport from cb5b68abdeb1b1d56c581d5b4d647018703d61e3 Co-authored-by: Christian Heimes <christian(a)python.org> commit 2149a9ad7a9d39d7d680ec0fb602042c91057484 (HEAD -> 2.7, upstream/2.7) Author: stratakis <cstratak(a)redhat.com> Date: Fri Feb 15 18:27:44 2019 +0100 [2.7] bpo-32947: Fixes for TLS 1.3 and OpenSSL 1.1.1 (GH-8761) (GH-11876) Backport of TLS 1.3 related fixes from 3.7. Misc fixes and workarounds for compatibility with OpenSSL 1.1.1 from git master and TLS 1.3 support. With OpenSSL 1.1.1, Python negotiates TLS 1.3 by default. Some test cases only apply to TLS 1.2. OpenSSL 1.1.1 has added a new option OP_ENABLE_MIDDLEBOX_COMPAT for TLS 1.3. The feature is enabled by default for maximum compatibility with broken middle boxes. Users should be able to disable the hack and CPython's test suite needs it to verify default options Signed-off-by: Christian Heimes <christian(a)python.org> (cherry picked from commit 2a4ee8aa01d61b6a9c8e9c65c211e61bdb471826) And there is a minor multissltests update that's going will be merged as well: https://github.com/python/cpython/pull/11879 Victor -- Night gathers, and now my watch begins. It shall not end until my death.

1 0

Python 3.8.0a1 with sqlite 3.27.1 -> OK
by Stephane Wirtel 15 Feb '19

15 Feb '19

Hi all, I wanted to test with the new version of SQLite3 3.27.1 and there is no issue (compiled with a debian:latest docker image and the last version of 3.27.1). Sorry, it's not a bug, I wanted to inform you there is no issue with the last stable version of SQLite3. Have a nice week-end, Stéphane root@3b7c342683ff:/src# ./python -m test test_sqlite -v == CPython 3.8.0a1+ (default, Feb 15 2019, 16:05:54) [GCC 6.3.0 20170516] == Linux-4.20.7-200.fc29.x86_64-x86_64-with-glibc2.17 little-endian == cwd: /src/build/test_python_15721 == CPU count: 4 == encodings: locale=UTF-8, FS=utf-8 Run tests sequentially 0:00:00 load avg: 1.99 [1/1] test_sqlite test_sqlite: testing with version '2.6.0', sqlite_version '3.27.1' ... Ran 288 tests in 0.553s OK (skipped=3) == Tests result: SUCCESS == 1 test OK. Total duration: 654 ms Tests result: SUCCESS -- Stéphane Wirtel - https://wirtel.be - @matrixise

1 0

An update on heap-allocated types
by Eddie Elizondo 14 Feb '19

14 Feb '19

I’ll be adding a change to move the Py_INCREF of heap allocated types from PyType_GenericAlloc to PyObject_Init. You can follow the discussion and/or add comments to: https://bugs.python.org/issue35810. This change will make types created through PyType_FromSpec behave like classes in managed code. Thus, making CPython much safer. Without this change, there are a couple of edge cases where the use of PyObject_{,GC}_New{,Var} does not correctly increase refcount. This leads to weird behavior, especially when migrating types from PyType_Ready to PyType_FromSpec. For example, consider a static type with tp_new = NULL and tp_dealloc = NULL. This type initializes instances through PyObject_New and never increases the type’s refcount. tp_dealloc will be a no-op since it's NULL and it's a static type. When this type is migrated to PyType_FromSpec, tp_dealloc will now inherit subtype_dealloc which decrefs the type. This leads to a crash. For the vast majority of existing code this should not have a visible side effect. And, at worst, this will only cause some type to become immortal. I’ve added instructions in the “Porting to Python 3.8” to correctly account for this new incref along with examples. In general, there are only two cases that would require any modification: 1. If the type creates instances through PyObject_{,GC}_New{,Var} and the type manually increfs afterwards. The fix here is to remove that manual incref. 2. If the type has a custom tp_dealloc and it’s not decrefing the type. The fix here is that a custom tp_dealloc should ALWAYS decref the type. Open to feedback/discussion so feel free to reply if you have any questions! - Eddie Elizondo

1 0

2.7.16 release dates
by Benjamin Peterson 12 Feb '19

12 Feb '19

Greetings, I've set the dates for the 2.7.16 release in PEP 373. The release candidate will happen on February 16 with a final release 2 weeks later on March 2 if all goes well. Servus, Benjamin

1 0

Reviewing PEP 580
by Jeroen Demeyer 12 Feb '19

12 Feb '19

Hello, I would like to propose to the new steering council to review PEP 580. Is there already a process for that? Thanks, Jeroen.

3 2

[docs] [issue35155] Requesting a review
by Denton Liu 12 Feb '19

12 Feb '19

Hello all, A couple months back, I reported bpo-35155[1] and I submitted a PR for it[2]. After a couple of reviews, it seems like progress has stalled. Would it be possible for someone to review this? Thanks, Denton [1]: https://bugs.python.org/issue35155 [2]: https://github.com/python/cpython/pull/10313

1 0

find_library and issue21622
by Javier Castillo II 11 Feb '19

11 Feb '19

Ran into some issues trying to deploy in an alpine container, where I wound up coming across the issue. I found a solution ( not sure if an ideal solution can exist ) that walks the paths in the environment variable LD_LIBRARY_PATH. This was submitted in github PR 10460, but not sure if there were any technical issues with this impacting its review.

2 2