This is based off of psrt/CVE-2020-10735-3.8backport branch at cd54fc3.

This is required for the 3.7 tree to pass on modern macOS.

I don't know why, but macOS in 3.7 CI is failing to build the zlib
module these days so it's exposing this test that didn't have the
proper `@requires_zlib` annotation.

Getting it to build with zlib and other things that are now wrongly
"missing" in the 3.7 CI setup would be nice, but probably involves
invasive backporting of parts of
python@b29d0a5
by a macOS domain expert.

Not worth it.

This test also appears to require changes to
Lib/ctypes/macholib/dyld.py to work in the existing macOS CI config.
I'm just skipping it, backporting that would be a feature.
Not going to happen in 3.7.

There may be a way to configure macOS CI to use an older macOS and
toolchain instead as an alternate option.  Someone else can figure
that out if so.  This branch only lives for another 9 months per
https://peps.python.org/pep-0537/

Thanks Ned!

the 3.8 branch got rid of this line already.  it blocks seeing the
actual error while testing a doc build!

…on into CVE-2020-10735-3.7backport

python#96542

Per mdickinson@'s comment on the main branch PR.

…#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: pythongh-95778 -->
* Issue: pythongh-95778
<!-- /gh-issue-number -->

Co-authored-by: Gregory P. Smith [Google LLC] <greg@krypto.org>