Commits · 8feefc281f03c0f1af3422a8f0febb68edb145f2

Update the vendored copy of libexpat to 2.4.1 (from 2.2.8) to get the
fix for the CVE-2013-0340 "Billion Laughs" vulnerability. This copy
is most used on Windows and macOS.

Co-authored-by: Victor Stinner <vstinner@python.org>

Co-authored-by: Łukasz Langa <lukasz@langa.pl&gt;.>
(cherry picked from commit 3fc5d840)

Co-authored-by: Miguel Brito <5544985+miguendes@users.noreply.github.com>

Co-authored-by: Łukasz Langa <lukasz@langa.pl>
(cherry picked from commit 0897253f)

Various date parsing utilities in the email module, such as
email.utils.parsedate(), are supposed to gracefully handle invalid
input, typically by raising an appropriate exception or by returning
None.

The internal email._parseaddr._parsedate_tz() helper used by some of
these date parsing routines tries to be robust against malformed input,
but unfortunately it can still crash ungracefully when a non-empty but
whitespace-only input is passed. This manifests as an unexpected
IndexError.

In practice, this can happen when parsing an email with only a newline
inside a ‘Date:’ header, which unfortunately happens occasionally in the
real world.

Here's a minimal example:

    $ python
    Python 3.9.6 (default, Jun 30 2021, 10:22:16)
    [GCC 11.1.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import email.utils
    >>> email.utils.parsedate('foo')
    >>> email.utils.parsedate(' ')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python3.9/email/_parseaddr.py", line 176, in parsedate
        t = parsedate_tz(data)
      File "/usr/lib/python3.9/email/_parseaddr.py", line 50, in parsedate_tz
        res = _parsedate_tz(data)
      File "/usr/lib/python3.9/email/_parseaddr.py", line 72, in _parsedate_tz
        if data[0].endswith(',') or data[0].lower() in _daynames:
    IndexError: list index out of range

The fix is rather straight-forward: guard against empty lists, after
splitting on whitespace, but before accessing the first element.
(cherry picked from commit 989f6a38)

Co-authored-by: wouter bolsterlee <wouter@bolsterl.ee>

It wasn't actually detecting the regression due to the
assertion being too lenient.
(cherry picked from commit e60ab843)

Co-authored-by: Gregory P. Smith <greg@krypto.org>

Co-authored-by: Gregory P. Smith <greg@krypto.org>

bpo-44022: Fix http client infinite line reading (DoS) after a HTTP 100 Continue (GH-25916) (GH-25934)

Fixes http.client potential denial of service where it could get stuck reading lines from a malicious server after a 100 Continue response.

Co-authored-by: Gregory P. Smith <greg@krypto.org>
(cherry picked from commit 47895e31)

Co-authored-by: Gen Xu <xgbarry@gmail.com>

Co-authored-by: Gregory P. Smith <greg@krypto.org>
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
(cherry picked from commit 76cd81d6)
Co-authored-by: Senthil Kumaran <senthil@uthcode.com>
(cherry picked from commit 515a7bc4)

Co-authored-by: Miss Islington (bot) <31488909+miss-islington@users.noreply.github.com>

Fix Regular Expression Denial of Service (ReDoS) vulnerability in
urllib.request.AbstractBasicAuthHandler. The ReDoS-vulnerable regex
has quadratic worst-case complexity and it allows cause a denial of
service when identifying crafted invalid RFCs. This ReDoS issue is on
the client side and needs remote attackers to control the HTTP server.
(cherry picked from commit 7215d1ae)

Co-authored-by: Yeting Li <liyt@ios.ac.cn>

Signed-off-by: Christian Heimes <christian@python.org>
(cherry picked from commit 34477500)

Co-authored-by: Christian Heimes <christian@python.org>

Ubuntu 20.04 comes with a patched OpenSSL 1.1.1. Default security level
2 blocks TLS 1.0 and 1.1 connections. Regular OpenSSL 1.1.1 builds allow
TLS 1.0 and 1.1 on security level 2.

See:
See: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878
See: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625


Signed-off-by: Christian Heimes <christian@python.org&gt;.>
(cherry picked from commit f6c6b582)

Co-authored-by: Christian Heimes <christian@python.org>

[3.7] bpo-43660: Fix crash when displaying exceptions with custom values for sys.stderr (GH-25075). (GH-25085)

(cherry picked from commit 09b90a03)

Co-authored-by: Pablo Galindo <Pablogsal@gmail.com>

CVE-2021-3426: Remove the "getfile" feature of the pydoc module which
could be abused to read arbitrary files on the disk (directory
traversal vulnerability). Moreover, even source code of Python
modules can contain sensitive data like passwords. Vulnerability
reported by David Schwörer.
(cherry picked from commit 9b999479)

Co-authored-by: Victor Stinner <vstinner@python.org>

Co-authored-by: Victor Stinner <vstinner@python.org>

The IPv4 address value returned from the server in response to the PASV command
should not be trusted.  This prevents a malicious FTP server from using the
response to probe IPv4 address and port combinations on the client network.

Instead of using the returned address, we use the IP address we're
already connected to.  This is the strategy other ftp clients adopted,
and matches the only strategy available for the modern IPv6 EPSV command
where the server response must return a port number and nothing else.

For the rare user who _wants_ this ugly behavior, set a `trust_server_pasv_ipv4_address`
attribute on your `ftplib.FTP` instance to True..
(cherry picked from commit 0ab152c6)

Co-authored-by: Gregory P. Smith <greg@krypto.org>
(cherry picked from commit 664d1d16)

(cherry picked from commit 94894dd4)

Co-authored-by: Brandt Bucher <brandt@python.org>

Co-authored-by: Brandt Bucher <brandt@python.org>

The note about the GIL was buried pretty deep in the threading documentation,
and this made it hard for first time users to discover why their attempts
at using threading to parallelizing their application did not work.

In this commit, the note is moved to the top of the module documention for
visibility..
(cherry picked from commit 32181be6)

Co-authored-by: Guanzhong Chen <quantum2048@gmail.com>

(cherry picked from commit 813db24f)

Co-authored-by: Pablo Galindo <Pablogsal@gmail.com>

bpo-42967: [security] Address a web cache-poisoning issue reported in
urllib.parse.parse_qsl().

urllib.parse will only us "&" as query string separator by default
instead of both ";" and "&" as allowed in earlier versions. An optional
argument seperator with default value "&" is added to specify the
separator.

Co-authored-by: Éric Araujo <merwok@netwok.org>
Co-authored-by: Ken Jin <28750310+Fidget-Spinner@users.noreply.github.com>
Co-authored-by: Adam Goldschmidt <adamgold7@gmail.com>
(cherry picked from commit fcbe0cb0)

[3.7] closes bpo-42938: Replace snprintf with Python unicode formatting in ctypes param reprs. (GH-24249)

(cherry picked from commit 916610ef)

Co-authored-by: Benjamin Peterson <benjamin@python.org>

(cherry picked from commit de6f20a6)

Co-authored-by: Dong-hee Na <donghee.na@python.org>

(cherry picked from commit ec316532)

Co-authored-by: Dong-hee Na <donghee.na@python.org>

Up until now, the `multiprocessing.pool.ThreadPool` class has gone
undocumented, despite being a public class in multiprocessing that is
included in `multiprocessing.pool.__all__`.
(cherry picked from commit 84ebcf27)

Co-authored-by: Matt Wozniski <mwozniski@bloomberg.net>

* build(deps): bump actions/cache from v2.1.2 to v2.1.3 (23582)

Bumps [actions/cache](https://github.com/actions/cache) from v2.1.2 to v2.1.3.
- [Release notes](https://github.com/actions/cache/releases)
- [Commits](https://github.com/actions/cache/compare/v2.1.2...0781355a23dac32fd3bac414512f4b903437991a

)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
(cherry picked from commit a43fea88)

* [3.7] build(deps): bump actions/cache from v2.1.2 to v2.1.3 (23582)

Bumps [actions/cache](https://github.com/actions/cache) from v2.1.2 to v2.1.3.
- [Release notes](https://github.com/actions/cache/releases)
- [Commits](https://github.com/actions/cache/compare/v2.1.2...0781355a23dac32fd3bac414512f4b903437991a

)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com&gt;.>
(cherry picked from commit a43fea88)

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791

 .)
(cherry picked from commit 31729366)

Co-authored-by: Devin Jeanpierre <jeanpierreda@google.com>

* bpo-42336: Improve PCbuild batch files (GH-23325)

* Remove ARM platforms

* Prevent some possible DoS attacks via providing invalid Plist files
  with extremely large number of objects or collection sizes.
* Raise InvalidFileException for too large bytes and string size instead of returning garbage.
* Raise InvalidFileException instead of ValueError for specific invalid datetime (NaN).
* Raise InvalidFileException instead of TypeError for non-hashable dict keys.
* Add more tests for invalid Plist files..
(cherry picked from commit 34637a0c)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

(cherry picked from commit 283f9a25)

bpo-41944: No longer call eval() on content received via HTTP in the CJK codec tests (GH-22566) (GH-22578)

(cherry picked from commit 2ef5caa5)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

Co-authored-by: Ronald Oussoren <ronaldoussoren@mac.com>

[3.7] bpo-41976: Fix the fallback to gcc of ctypes.util.find_library when using gcc>9 (GH-22598). (GH-22601)

(cherry picked from commit 27ac19cc)

Co-authored-by: Pablo Galindo <Pablogsal@gmail.com>