10^4300 年问题

CVE-2020-10735 及其“修复”

2022 年 9 月 7 日Python安全更新已发布。

“固定”漏洞是CVE-2020-10735是。粗略地说，它是在Python中使用的整数字符串转换算法不是很酷¹，例如，将 100,000 个十进制数字的字符串转换为整数需要 50 毫秒，而 100,000 位数字需要 5 秒。²，它可以用于 DoS 攻击。

在这里，Python开发团队采取的解决方案不是改进算法³，喜欢“使固定”是。

>>> n = 10**4300
>>> str(n)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Exceeds the limit (4300) for integer string conversion

默认情况下，超过 4300 个字符的整数作为字符串会发生错误。在上面的示例中，$10^{4300}$ 有 4301 个十进制数字，因此在尝试将其转换为字符串时会出错。它在以前的版本中运行良好，因此我们破坏了与补丁版本的向后兼容性⁴这是一个有争议的问题⁵.

现在，考虑一个这样的 Python 程序：

import calendar

year = eval(input("year?"))
month = eval(input("month?"))
calendar.TextCalendar().prmonth(year, month)

要求用户输入年份和月份⁶,calendar 模块的TextCalendarclass用于输出该月/年的日历。例如，

year?2022
month?9

将 2022 年 9 月的日历打印到标准输出。

   September 2022
Mo Tu We Th Fr Sa Su
          1  2  3  4
 5  6  7  8  9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30

现在让我们把注意力转向遥远的未来。因为在 Python 中很容易显示一年中 12 月的日历 $10^{4300}$-1。⁷.

year?10**4300-1
month?12

December 99999999999999999999999999999999999999999999999999999999999999999999999
... (省略) ...
9999999999999999
Mo Tu We Th Fr Sa Su
       1  2  3  4  5
 6  7  8  9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31

但是，当我尝试显示下个月 1 月 $10^{4300}$ 的日历时，出现错误。

year?10**4300
month?1

Traceback (most recent call last):
  File "//prog.py", line 5, in <module>
    calendar.TextCalendar().prmonth(year, month)
  File "/usr/local/lib/python3.10/calendar.py", line 352, in prmonth
    print(self.formatmonth(theyear, themonth, w, l), end='')
  File "/usr/local/lib/python3.10/calendar.py", line 360, in formatmonth
    s = self.formatmonthname(theyear, themonth, 7 * (w + 1) - 1)
  File "/usr/local/lib/python3.10/calendar.py", line 345, in formatmonthname
    s = "%s %r" % (s, theyear)
ValueError: Exceeds the limit (4300) for integer string conversion

我的天啊！我能够编写一个程序，该程序可以工作到 $10^{4300}$-1 AD 年，但一旦达到 $10^{4300}$ AD 就停止工作。⁸.这就是 $10^{4300}$ AD 问题的诞生。⁹.遥远的未来，质子衰变¹⁰或真空塌陷¹¹这样的，世凯主角即便如此，它还是在2022年9月埋下的一个“虫子”，在人类克服了许多破坏危机之后，已经达到了拼命逃跑的程度。¹².去吧，后代。尽力而为。

粗略解释为 Python $simeq$ CPython 的 0 阶近似值。除了 CPython，例如派皮讨论在这里.↩
（取决于机器）对于大小为 $n$ 的输入，计算量增加 $O(n^2)$ 而不是特定的秒数是危险的。↩
使算法更好一点的论点是这里.↩
语义版本控制据他介绍，当你升级补丁版本时，你应该只修复具有向后兼容性的错误。↩
这里和这里和这里和这里和这里和。↩
我不会清理用户输入并将其提供给eval()，但不要模仿它。↩
这个日历适合泽勒公式($y = 400n-1$ ($n$ 是一个整数)，所以变得容易理解了)。↩
其实我是想做一个不用输入年月自动获取当前日期时间并显示日历的程序，但是Python标准datetime模块牙齿最多只能处理 9999它是当然，10000 年问题.↩
所谓的“Y10K 及以后”问题已经有了解决方案，包括公元 10^{4300}$ 问题。RFC 2550(日文翻译) 并通过高达 10 美元 ^{18308} 年的示例进行讨论。该 RFC 于 1999 年发布。4月1日是。↩
截至 2022 年 10 月，质子平均寿命的实验下限为 90% 置信水平下的 3.6 次 10^{29}$ 年（不可见模式，来源为这个和这个和）。↩
这个根据 95% 的置信水平，它将发生在 $10^{65}$ 和 $10^{1383}$ 年之间。这里也可以看看↩
我想知道人类是否会在 $10^{4300}$ 之前使用 Python，如果这个“错误”直到那时才能修复，如果它不是内部表示溢出，所以这不是本质问题，或者西方日历是否是还在用。是公历吗？↩

原创声明：本文系作者授权爱码网发表，未经许可，不得转载;

原文地址：https://www.likecs.com/show-308628119.html