(cherry picked from commit a17c57eee5b5cc81390750d07e4800b19c0c3084)
(cherry picked from commit 0329bd11c7e98484727bbb9062d53a8fa53ac7fd)
Co-authored-by: Miss Islington (bot) <31488909+miss-islington@users.noreply.github.com>
Also adds a new "strict" argument to realpath() to avoid changing the default behaviour of pathlib while sharing the implementation.
(cherry-picked from commit baecfbd849dbf42360d3a84af6cc13160838f24d)
Co-authored-by: Barney Gale <barney.gale@gmail.com>
Make `versionchanged:: next`` expand to current (unreleased) version.
When a new CPython release is cut, the release manager will replace
all such occurences of "next" with the just-released version.
(See the issue for release-tools and devguide PRs.)
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
(cherry picked from commit 7d24ea9db3e8fdca52058629c9ba577aba3d8e5c)
gh-121277: Raise nice error on `next` as second argument to deprecated-removed (GH-124623)
(cherry-picked from e349f73a5ad2856b0a7cbe4aef7cc081c7aed777)
(cherry-picked from 3.11: f0895aa9c1d40d0add673cc51bd143556e22100a)
(cherry-picked from 3.10: 8773554b717cfb08b4bd11a927813f4ed74762c7)
It was never really safe and this claim conflicts directly with the big warning in the docs about it being able to crash the interpreter.
(cherry picked from commit 8baef8ae367041a5cfefb40b19c7b87e9bcb56a2)
Co-authored-by: Gregory P. Smith <greg@krypto.org>
Detect email address parsing errors and return empty tuple to
indicate the parsing error (old API). Add an optional 'strict'
parameter to getaddresses() and parseaddr() functions. Patch by
Thomas Dwyer.
(cherry picked from commit 4a153a1d3b18803a684cd1bcc2cdf3ede3dbae19)
Co-authored-by: Victor Stinner <vstinner@python.org>
Co-Authored-By: Thomas Dwyer <github@tomd.tel>
Per RFC 2047:
> [...] these encoding schemes allow the
> encoding of arbitrary octet values, mail readers that implement this
> decoding should also ensure that display of the decoded data on the
> recipient's terminal will not cause unwanted side-effects
It seems that the "quoted-word" scheme is a valid way to include
a newline character in a header value, just like we already allow
undecodable bytes or control characters.
They do need to be properly quoted when serialized to text, though.
This should fail for custom fold() implementations that aren't careful
about newlines.
(cherry picked from commit 097633981879b3c9de9a1dd120d3aa585ecc2384)
Co-authored-by: Petr Viktorin <encukou@gmail.com>
Co-authored-by: Bas Bloemsaat <bas@bloemsaat.org>
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
The _private_networks variables, used by various is_private
implementations, were missing some ranges and at the same time had
overly strict ranges (where there are more specific ranges considered
globally reachable by the IANA registries).
This patch updates the ranges with what was missing or otherwise
incorrect.
100.64.0.0/10 is left alone, for now, as it's been made special in [1].
The _address_exclude_many() call returns 8 networks for IPv4, 121
networks for IPv6.
[1] https://github.com/python/cpython/issues/61602
In 3.10 and below, is_private checks whether the network and broadcast
address are both private.
In later versions (where the test wss backported from), it checks
whether they both are in the same private network.
For 0.0.0.0/0, both 0.0.0.0 and 255.225.255.255 are private,
but one is in 0.0.0.0/8 ("This network") and the other in
255.255.255.255/32 ("Limited broadcast").
---------
Co-authored-by: Jakub Stasiak <jakub@stasiak.at>
Allow controlling Expat >=2.6.0 reparse deferral (CVE-2023-52425) by adding five new methods:
- `xml.etree.ElementTree.XMLParser.flush`
- `xml.etree.ElementTree.XMLPullParser.flush`
- `xml.parsers.expat.xmlparser.GetReparseDeferralEnabled`
- `xml.parsers.expat.xmlparser.SetReparseDeferralEnabled`
- `xml.sax.expatreader.ExpatParser.flush`
Based on the "flush" idea from https://github.com/python/cpython/pull/115138#issuecomment-1932444270 .
Includes code suggested-by: Snild Dolkow <snild@sony.com>
and by core dev Serhiy Storchaka.
Co-authored-by: Gregory P. Smith <greg@krypto.org>
Doc/library/xml.rst: Document CVE-2023-52425 under "XML vulnerabilities"
(cherry picked from commit fbd40ce46e7335a5dbaf48a3aa841be22d7302ba)
Co-authored-by: Sebastian Pipping <sebastian@pipping.org>
gh-102153: Start stripping C0 control and space chars in `urlsplit` (GH-102508)
`urllib.parse.urlsplit` has already been respecting the WHATWG spec a bit GH-25595.
This adds more sanitizing to respect the "Remove any leading C0 control or space from input" [rule](https://url.spec.whatwg.org/GH-url-parsing:~:text=Remove%20any%20leading%20and%20trailing%20C0%20control%20or%20space%20from%20input.) in response to [CVE-2023-24329](https://nvd.nist.gov/vuln/detail/CVE-2023-24329).
I simplified the docs by eliding the state of the world explanatory
paragraph in this security release only backport. (people will see
that in the mainline /3/ docs)
(cherry picked from commit 2f630e1ce18ad2e07428296532a68b11dc66ad10)
(cherry picked from commit 610cc0ab1b760b2abaac92bd256b96191c46b941)
(cherry picked from commit f48a96a28012d28ae37a2f4587a780a5eb779946)
Co-authored-by: Illia Volochii <illia.volochii@gmail.com>
Co-authored-by: Gregory P. Smith [Google] <greg@krypto.org>
(cherry picked from commit 1cf3d78c92eb07dc09d15cc2e773b0b1b9436825)
(cherry picked from commit 88fe8d701af3316c8869ea18ea1c7acec6f68c04)
Co-authored-by: Jeremy Paige <ucodery@gmail.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
* [3.9] Update copyright years to 2023. (gh-100848).
(cherry picked from commit 11f99323c2ae0ec428c370a335695e3d8d4afc1d)
Co-authored-by: Benjamin Peterson <benjamin@python.org>
* Update additional copyright years to 2023.
Co-authored-by: Ned Deily <nad@python.org>
* 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 d8ab0a4dfa48f881b4ac9ab857d2e9de42f72828)
Co-authored-by: Gregory P. Smith <greg@krypto.org>
* also escape \s (backport of PR #100038).
* add versionadded and remove extra 'to'
Co-authored-by: Gregory P. Smith <greg@krypto.org>
gh-68966: Make mailcap refuse to match unsafe filenames/types/params (GH-91993)
(cherry picked from commit b9509ba7a9c668b984dab876c7926fe1dc5aa0ba)
Co-authored-by: Petr Viktorin <encukou@gmail.com>
Revert params note in urllib.parse.urlparse table
(cherry picked from commit eed80458e8e776d15fa862da71dcce58c47e2ca7)
Co-authored-by: Stanley <46876382+slateny@users.noreply.github.com>
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 e841ffc915e82e5ea6e3b473205417d63494808d)
Co-authored-by: Ned Deily <nad@python.org>
This documents the behavior that has always been the case since timeout
support was introduced in Python 3.3.
(cherry picked from commit b05dd796492160c37c9e15e3882f699f411b3461)
Co-authored-by: Gregory P. Smith <greg@krypto.org>
* Correctly pre-check for int-to-str conversion (#96537)
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>
It fixes 252 errors from a Sphinx nitpicky run (sphinx-build -n). But
there's 8182 errors left.
Co-authored-by: Ezio Melotti <ezio.melotti@gmail.com>
(cherry picked from commit 664aa94b570a4a8f3535efb2e3d638a4ab655943)
Co-authored-by: Julien Palard <julien@palard.fr>
