3.8
Name already in use
Commits on Mar 13, 2023
Commits on Mar 7, 2023
-
[3.8] gh-101726: Update the OpenSSL version to 1.1.1t (GH-101727) (GH…
…-101752) Fixes CVE-2023-0286 (High) and a couple of Medium security issues. https://www.openssl.org/news/secadv/20230207.txt Co-authored-by: Gregory P. Smith <greg@krypto.org> Co-authored-by: Ned Deily <nad@python.org>
Commits on Jan 30, 2023
Commits on Jan 21, 2023
Commits on Jan 20, 2023
Commits on Jan 8, 2023
Commits on Dec 6, 2022
-
-
-
[3.8] gh-100001: Omit control characters in http.server stderr logs. (G…
…H-100002) (#100033) * gh-100001: Omit control characters in http.server stderr logs. (GH-100002) Replace control characters in http.server.BaseHTTPRequestHandler.log_message with an escaped \xHH sequence to avoid causing problems for the terminal the output is printed to. (cherry picked from commit d8ab0a4) Co-authored-by: Gregory P. Smith <greg@krypto.org> * also escape \s (backport of PR #100038). * add versionadded and remove extraneous 'to' Co-authored-by: Gregory P. Smith <greg@krypto.org>
Commits on Nov 21, 2022
Commits on Nov 10, 2022
-
[3.8] gh-98433: Fix quadratic time idna decoding. (GH-99092) (GH-99222)…
… (GH-99231) There was an unnecessary quadratic loop in idna decoding. This restores the behavior to linear. (cherry picked from commit d315722) (cherry picked from commit a6f6c3a) Co-authored-by: Miss Islington (bot) <31488909+miss-islington@users.noreply.github.com> Co-authored-by: Gregory P. Smith <greg@krypto.org>
Commits on Oct 28, 2022
-
[3.8] gh-98517: Fix buffer overflows in _sha3 module (GH-98519) (#98527)
This is a port of the applicable part of XKCP's fix [1] for CVE-2022-37454 and avoids the segmentation fault and the infinite loop in the test cases published in [2]. [1]: XKCP/XKCP@fdc6fef [2]: https://mouha.be/sha-3-buffer-overflow/ Regression test added by: Gregory P. Smith [Google LLC] <greg@krypto.org> (cherry picked from commit 0e4e058) Co-authored-by: Theo Buehler <botovq@users.noreply.github.com>
-
[3.8] gh-98739: Update libexpat from 2.4.9 to 2.5.0 (GH-98742) (#98787)
Update libexpat from 2.4.9 to 2.5.0 to address CVE-2022-43680. Co-authored-by: Shaun Walbridge <shaun.walbridge@gmail.com> (cherry picked from commit 3e07f82)
Commits on Oct 11, 2022
-
[3.8] gh-68966: Make mailcap refuse to match unsafe filenames/types/p…
-
[3.8] gh-96710: Make the test timing more lenient for the int/str DoS…
… regression test. (GH-96717) (#98197) gh-96710: Make the test timing more lenient for the int/str DoS regression test. (GH-96717) A regression would still absolutely fail and even a flaky pass isn't harmful as it'd fail most of the time across our N system test runs. Windows has a low resolution timer and CI systems are prone to odd timing so this just gives more leeway to avoid flakiness. (cherry picked from commit 11e3548) Co-authored-by: Gregory P. Smith <greg@krypto.org>
-
-
Commits on Oct 4, 2022
-
[3.8] gh-95778: Mention sys.set_int_max_str_digits() in error message (…
…GH-96874) (GH-96877) (GH-97835) [3.9] gh-95778: Mention sys.set_int_max_str_digits() in error message (GH-96874) (GH-96877) When ValueError is raised if an integer is larger than the limit, mention sys.set_int_max_str_digits() in the error message. (cherry picked from commit e841ffc) Co-authored-by: Ned Deily <nad@python.org> (cherry picked from commit 4118813) Co-authored-by: Victor Stinner <vstinner@python.org>
-
[3.8] gh-96848: Fix -X int_max_str_digits option parsing (GH-96988) (G…
-
[3.8] gh-97616: list_resize() checks for integer overflow (GH-97617) (G…
…H-97628) gh-97616: list_resize() checks for integer overflow (GH-97617) Fix multiplying a list by an integer (list *= int): detect the integer overflow when the new allocated length is close to the maximum size. Issue reported by Jordan Limor. list_resize() now checks for integer overflow before multiplying the new allocated length by the list item size (sizeof(PyObject*)). (cherry picked from commit a5f092f) Co-authored-by: Victor Stinner <vstinner@python.org>
-
[3.8] gh-97612: Fix shell injection in get-remote-certificate.py (GH-…
…97613) (GH-97633) Fix a shell code injection vulnerability in the get-remote-certificate.py example script. The script no longer uses a shell to run "openssl" commands. Issue reported and initial fix by Caleb Shortt. Remove the Windows code path to send "quit" on stdin to the "openssl s_client" command: use DEVNULL on all platforms instead. Co-authored-by: Caleb Shortt <caleb@rgauge.com> (cherry picked from commit 83a0f44) Co-authored-by: Victor Stinner <vstinner@python.org>
Commits on Sep 11, 2022
-
[3.8] Update bugs URL references in README and Docs/bugs.rst from bpo…
… to gh issues (GH-96728) Co-authored-by: roy reznik <royreznik@gmail.com> Co-authored-by: Inada Naoki <songofacandy@gmail.com> Co-authored-by: Ezio Melotti <ezio.melotti@gmail.com>
Commits on Sep 6, 2022
Commits on Sep 5, 2022
-
[3.8] gh-95778: CVE-2020-10735: Prevent DoS by very large int() (#96503)
* Correctly pre-check for int-to-str conversion Converting a large enough `int` to a decimal string raises `ValueError` as expected. However, the raise comes _after_ the quadratic-time base-conversion algorithm has run to completion. For effective DOS prevention, we need some kind of check before entering the quadratic-time loop. Oops! =) The quick fix: essentially we catch _most_ values that exceed the threshold up front. Those that slip through will still be on the small side (read: sufficiently fast), and will get caught by the existing check so that the limit remains exact. The justification for the current check. The C code check is: ```c max_str_digits / (3 * PyLong_SHIFT) <= (size_a - 11) / 10 ``` In GitHub markdown math-speak, writing $M$ for `max_str_digits`, $L$ for `PyLong_SHIFT` and $s$ for `size_a`, that check is: $$\left\lfloor\frac{M}{3L}\right\rfloor \le \left\lfloor\frac{s - 11}{10}\right\rfloor$$ From this it follows that $$\frac{M}{3L} < \frac{s-1}{10}$$ hence that $$\frac{L(s-1)}{M} > \frac{10}{3} > \log_2(10).$$ So $$2^{L(s-1)} > 10^M.$$ But our input integer $a$ satisfies $|a| \ge 2^{L(s-1)}$, so $|a|$ is larger than $10^M$. This shows that we don't accidentally capture anything _below_ the intended limit in the check. <!-- gh-issue-number: gh-95778 --> * Issue: gh-95778 <!-- /gh-issue-number --> Co-authored-by: Gregory P. Smith [Google LLC] <greg@krypto.org> Co-authored-by: Christian Heimes <christian@python.org> Co-authored-by: Mark Dickinson <dickinsm@gmail.com>