Commits
3.6
Name already in use
Commits on Dec 28, 2021
Commits on Sep 4, 2021
Commits on Aug 31, 2021
-
[3.6] bpo-44394: Update libexpat copy to 2.4.1 (GH-26945) (GH-28042) (G…
…H-28080) 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>. (cherry picked from commit 3fc5d84)
-
bpo-38965: Fix faulthandler._stack_overflow() on GCC 10 (GH-17467) (G…
…H-28079) Use the "volatile" keyword to prevent tail call optimization on any compiler, rather than relying on compiler specific pragma. (cherry picked from commit 8b78796) Co-authored-by: Victor Stinner <vstinner@python.org> (cherry picked from commit 5044c88) Co-authored-by: Miss Islington (bot) <31488909+miss-islington@users.noreply.github.com>
Commits on Aug 30, 2021
-
bpo-45001: Make email date parsing more robust against malformed input (
GH-27946) (GH-27976) 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 989f6a3) Co-authored-by: wouter bolsterlee <wouter@bolsterl.ee>
Commits on Jul 5, 2021
Commits on Jun 28, 2021
Commits on Jun 3, 2021
Commits on May 20, 2021
-
[3.6] bpo-43882 - Mention urllib.parse changes in Whats New section f…
…or 3.6.14 (GH-26268) Co-authored-by: Gregory P. Smith <greg@krypto.org>
Commits on May 6, 2021
-
bpo-44022: Fix http client infinite line reading (DoS) after a HTTP 1…
…00 Continue (GH-25916) (GH-25935) 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 47895e3) Co-authored-by: Gen Xu <xgbarry@gmail.com>
-
bpo-43075: Fix ReDoS in urllib AbstractBasicAuthHandler (GH-24391) (G…
…H-25250) 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 7215d1a) Co-authored-by: Yeting Li <liyt@ios.ac.cn>
-
[3.6] bpo-43882 - urllib.parse should sanitize urls containing ASCII …
…newline and tabs (GH-25924) Co-authored-by: Gregory P. Smith <greg@krypto.org> Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> (cherry picked from commit 76cd81d) Co-authored-by: Senthil Kumaran <senthil@uthcode.com> (cherry picked from commit 515a7bc) Co-authored-by: Miss Islington (bot) <31488909+miss-islington@users.noreply.github.com>
Commits on Mar 29, 2021
-
bpo-42988: Remove the pydoc getfile feature (GH-25015) (GH-25067)
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 9b99947) Co-authored-by: Victor Stinner <vstinner@python.org>
Commits on Mar 16, 2021
-
[3.6] bpo-43285 Make ftplib not trust the PASV response. (GH-24838) (G…
…H-24881) (GH-24882) 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 0ab152c) Co-authored-by: Gregory P. Smith <greg@krypto.org> (cherry picked from commit 664d1d1)
Commits on Feb 16, 2021
Commits on Feb 15, 2021
-
[3.6] bpo-42967: only use '&' as a query string separator (GH-24297) (G…
…H-24532) 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>
Commits on Jan 18, 2021
Commits on Jan 1, 2021
Commits on Dec 14, 2020
-
bpo-40791: Make compare_digest more constant-time. (GH-23438) (GH-23767)
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 3172936) Co-authored-by: Devin Jeanpierre <jeanpierreda@google.com>
Commits on Nov 10, 2020
-
bpo-35560: Remove assertion from format(float, "n") (GH-11288) (GH-23231
) Fix an assertion error in format() in debug build for floating point formatting with "n" format, zero padding and small width. Release build is not impacted. Patch by Karthikeyan Singaravelan. (cherry picked from commit 3f7983a) Co-authored-by: Xtreak <tir.karthi@gmail.com>
-
[3.6] bpo-42103: Improve validation of Plist files. (GH-22882) (GH-23118
) * 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 34637a0) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Commits on Oct 22, 2020
-
[3.6] Remove 3.5 from Doc version switcher in master. (GH-22886) (#22891
) (cherry picked from commit 283f9a2)
Commits on Oct 20, 2020
Commits on Aug 17, 2020
Commits on Jul 19, 2020
Commits on Jul 15, 2020
-
bpo-39017: Avoid infinite loop in the tarfile module (GH-21454) (#21485)
Avoid infinite loop when reading specially crafted TAR files using the tarfile module (CVE-2019-20907). (cherry picked from commit 5a8d121) Co-authored-by: Rishi <rishi_devan@mail.com>