>>> import sys >>> sys.set_int_max_str_digits(4300) # Illustrative, this is the default. >>> _ = int('2' * 5432) Traceback (most recent call last): ... ValueError: Exceeds the limit (4300) for integer string conversion: value has 5432 digits.
Python3.10.7为类型转换引入了这一突破性的变化.
文档:Integer string conversion length limitation
其实我也不明白为什么
请参阅GitHub第CVE-2020-10735: Prevent DoS by large int<->str conversions #95778期:
Problem个
在CPython中发现了一个拒绝服务(DoS)问题 因为我们在int实现中使用了二进制bignum.一个巨大的 Integer将始终消耗接近二次的CPU时间 转换为具有大数字的基数为10(十进制)的字符串或从基数为10(十进制)的字符串进行转换 数位数.没有其他有效的算法可以做到这一点.
对于实现网络协议和 对输入执行INT(UNTRUSTED_STRING_OR_BYTES_VALUE)的数据序列化 在不限制输入长度或的情况下获取数值 执行
log("processing thing id %s", unknowingly_huge_integer)或任何操作 类似于无需首先判断即可将int转换为字符串的概念 它的规模.(http、json、xmlrpc、logging，将大值加载到 通过线性时间转换实现的整数，例如存储在 YAML或任何基于用户控制的计算较大值的对象 输入…然后最终try 在稍后输出为小数). 所有这些都可能在不可信的情况下遭受CPU消耗的DoS 数据.每个人都在为此审核所有现有代码，添加长度保护， 坚持这种做法无处不在是不可行的，也是不可能的 我们认为绝大多数用户想要做的事情.
此问题已报告给Python安全响应团队 自2020年初以来，由几个不同的人多次提出，大多数 最近几周前，当我正在打磨 PR，所以它会在3.11.0rc2之前准备好.
Mitigation个
在讨论了Python安全响应团队之后 邮寄列表结论是，我们需要限制 用于非线性时间转换的整数到字符串的转换 (默认情况下，不是2的幂).并提供了以下能力 配置或禁用此限制.
Python指导委员会意识到了这一变化，并将其视为 这是必要的.
更多的讨论可以在开发人员讨论主题Int/str conversions broken in latest Python bugfix releases上找到.
我发现史蒂夫·道尔的this comment本书信息量很大:
我们对这一过程缺乏透明度表示歉意.这个 这个问题最先报告给了其他一些安全团队， 汇聚在Python安全响应团队，在那里我们达成了一致 正确的修复方法是修改运行时.
报告和修复之间的延误完全是我们的错.安全措施 团队由志愿者组成，我们的可用性并不总是可靠的， 也没有人"负责"协调工作.我们一直在 讨论如何改进我们的流程.然而，我们确实同意 剥削的可能性很高，以至于我们不想 在没有可用的修复程序并可供使用的情况下披露该问题.
我们确实通过许多替代方法进行了工作，实现 他们中的许多人.执行INT(GIGABYTE_LONG_UNTRUSTED_STRING)的代码可能 位于json.Load或HTTP头解析器中的任何位置，并且可以非常 很深.解析库无处不在，并且倾向于使用int 不加区别地(尽管它们通常已经处理了ValueError). 期望每个库都向每个int()调用添加一个新参数 会导致数以千计的漏洞被归档，并 用户永远不可能相信他们的系统不能 多斯德.
我们同意在核心做这件事是一把沉重的锤子，但这也是 只有锤子有机会让用户有信心保持 在他们的应用程序边界上运行Python.
现在，我个人倾向于同意int->字符串转换应该 做一些不同于加薪的事情.我被击败了，因为它会打破 往返，这是我接受的一个合理的论点.我们可以的 不过，随着时间的推移，仍然会改进这一点，使其更易于使用.然而，在大多数情况下 我们看到的 case 中，渲染过长的字符串是不可取的 两种都行.这应该是 Select 加入的行为.
从str引发异常可能会被证明是太多了，而且可能是 重新考虑，但我们没有看到一种可行的方法来推送更新 INT的每一个用户，所以这肯定会保持全球性.