Christian Heimes [Sun, 23 Sep 2018 07:50:25 +0000 (09:50 +0200)]
bpo-17239: Disable external entities in SAX parser (GH-9217)
The SAX parser no longer processes general external entities by default
to increase security. Before, the parser created network connections
to fetch remote files or loaded local files from the file system for DTD
and entities.
Signed-off-by: Christian Heimes <christian@python.org>
https://bugs.python.org/issue17239
bpo-34759: Fix error handling in ssl 'unwrap()' (GH-9468)
OpenSSL follows the convention that whenever you call a function, it
returns an error indicator value; and if this value is negative, then
you need to go look at the actual error code to see what happened.
Commit c6fd1c1c3a introduced a small mistake in
_ssl__SSLSocket_shutdown_impl: instead of checking whether the error
indicator was negative, it started checking whether the actual error
code was negative, and it turns out that the error codes are never
negative. So the effect was that 'unwrap()' lost the ability to raise
SSL errors.
David Cuthbert [Sat, 22 Sep 2018 01:31:15 +0000 (18:31 -0700)]
bpo-32117: Allow tuple unpacking in return and yield statements (gh-4509)
Iterable unpacking is now allowed without parentheses in yield and return
statements, e.g. ``yield 1, 2, 3, *rest``. Thanks to David Cuthbert for the
change and jChapman for added tests.
bpo-34537: Fix test_gdb:test_strings with LC_ALL=C (GH-9483)
We cannot simply call locale.getpreferredencoding() here,
as GDB might have been linked against a different version
of Python with a different encoding and coercion policy
with respect to PEP 538 and PEP 540.
Thanks to Victor Stinner for a hint on how to fix this.
bpo-32718: Make Activate.ps1 for venv cross-platform and available on all platforms (GH-9321)
PowerShell Core 6.1 is the cross-platform port of Windows PowerShell. This change updates Activate.ps1 to not make Windows assumptions as well as installing it into the bin/Scripts directory on all operating systems.
Requires PowerShell Core 6.1 for proper readline support once the shell has been activated for the virtual environment.
Reduce the knotty preprocessor conditional logic, dedent unnecessarily nested
code, and handle errors properly.
The first edition of this change (afde1c1a05cc8a1e8adf6403c451f6708509a605)
failed (bpo-34715) because FreeBSD doesn't define the timezone globals. That's
why we're now checking for HAVE_DECL_TZNAME.
Ben Hoyt [Wed, 19 Sep 2018 10:28:28 +0000 (06:28 -0400)]
bpo-34712: Fix style in examples in "Input and Output" (GH-9361)
A couple of fixes here to make this more PEP-8:
* Avoid multiple statements on one line with `;` statement separator -- this is very rare in Python and is "generally discouraged" in PEP 8 (and if used, per PEP 8 there shouldn't be a space before the `;`)
* Add output for the first "Formatted String Literals" example. (Side note: are the doctests for this being run? If so, why didn't it fail?)
* Avoid space before `!r`. I have generally not seen spaces before the `!`, and this also matches the style used in the docs here: https://docs.python.org/3/library/string.html#format-string-syntax
Ross Burton [Wed, 19 Sep 2018 06:25:48 +0000 (07:25 +0100)]
closes bpo-34585: Don't do runtime test to get float byte order. (GH-9085)
Currently configure.ac uses AC_RUN_IFELSE to determine the byte order of doubles, but this silently fails under cross compilation and Python doesn't do floats properly.
Instead, steal a macro from autoconf-archive which compiles code using magic doubles (which encode to ASCII) and grep for the representation in the binary.
RFC because this doesn't yet handle the weird ancient ARMv4 OABI 'mixed-endian' encoding properly. This encoding is ancient and I don't believe the union of "Python 3.8 users" and "OABI users" has anything in. Should the support for this just be dropped too? Alternatively, someone will need to find an OABI toolchain to verify the encoding of the magic double.
bpo-33721: Make some os.path functions and pathlib.Path methods be tolerant to invalid paths. (#7695)
Such functions as os.path.exists(), os.path.lexists(), os.path.isdir(),
os.path.isfile(), os.path.islink(), and os.path.ismount() now return False
instead of raising ValueError or its subclasses UnicodeEncodeError
and UnicodeDecodeError for paths that contain characters or bytes
unrepresentative at the OS level.
Victor Stinner [Mon, 17 Sep 2018 23:22:29 +0000 (16:22 -0700)]
bpo-34589: C locale coercion off by default (GH-9073)
Py_Initialize() and Py_Main() cannot enable the C locale coercion
(PEP 538) anymore: it is always disabled. It can now only be enabled
by the Python program ("python3).
test_embed: get_filesystem_encoding() doesn't have to set PYTHONUTF8
nor PYTHONCOERCECLOCALE, these variables are already set in the
parent.
The test tries to fill the receiver's socket buffer and expects an
error. But the RDS protocol doesn't require that. Moreover, the Linux
implementation of RDS expects that the producer of the messages
reduces its rate, it's not the role of the receiver to trigger an
error.
The test fails on Fedora 28 by design, so remove it.
Eric Snow [Fri, 14 Sep 2018 21:17:20 +0000 (14:17 -0700)]
bpo-34651: Only allow the main interpreter to fork. (gh-9279)
When os.fork() is called (on platforms that support it) all threads but the current one are destroyed in the child process. Consequently we must ensure that all but the associated interpreter are likewise destroyed. The main interpreter is critical for runtime operation, so we must ensure that fork only happens in the main interpreter.
Gregory P. Smith [Fri, 14 Sep 2018 05:08:31 +0000 (22:08 -0700)]
bpo-6721: Hold logging locks across fork() (GH-4071)
bpo-6721: When os.fork() was called while another thread holds a logging lock, the child process may deadlock when it tries to log. This fixes that by acquiring all logging locks before fork and releasing them afterwards.
A regression test that fails before this change is included.
Within the new unittest itself: There is a small _potential_ due to mixing of fork and a thread in the child process if the parent's thread happened to hold a non-reentrant library call lock (malloc?) when the os.fork() happens. buildbots and time will tell if this actually manifests itself in this test or not. :/ A functionality test that avoids that would be a challenge.
An alternate test that isn't trying to produce the deadlock itself but just checking that the release and acquire calls are made would be the next best alternative if so.