安全审计整改：Warehouse
内容提要
本文讨论了PyPI.org的Warehouse代码库的安全审计结果及整改措施。审计发现18个问题，包括AWS SNS验证弱签名、缺乏速率限制和潜在的竞争条件等。部分问题已整改，部分接受。整改措施包括更新签名验证和改进搜索锁定机制，旨在提升PyPI的安全性。
延伸解读
整改优先级背后的权衡逻辑
从整改状态看，团队并非机械地修复所有问题，而是根据严重性、修复难度和实际风险进行权衡。例如，中危的AWS SNS弱签名问题被修复，而低危的速率限制缺失则被接受，因为已有补偿控制。这种基于风险的选择性整改，反映了安全工程中资源有限时的务实决策。
依赖上游修复的被动性
多个已接受的问题依赖外部条件：Backblaze B2存储后端缺少SHA-256支持，需等待其路线图；docutils的未捕获异常bug尚未得到维护者回应；AWS SNS的SHA256默认设置也需服务方推进。这提示读者，开源项目的安全整改常受制于第三方，需持续跟踪并适时更新。
系统升级带来的意外修复
XMLRPC服务器的不安全XML处理问题，最终通过将操作系统从Debian 11升级到12而解决，因为新版本中的expat库已修复漏洞。这提醒我们，定期进行系统维护和依赖升级，有时能自动消除已知安全风险，而不必专门修改代码。
接受风险不等于忽视风险
对于tar.gz上传的拒绝服务风险，团队因检测成本高且已有专用工作池缓解而选择接受；对于LIKE查询未转义，则因影响限于管理界面且表较小而接受。这些决定都附带了未来重新评估的可能性，并持续监控相关资源，体现了风险接受后的动态管理。
Q&A
Warehouse的安全审计发现了哪些主要问题？
审计发现了18个问题，包括AWS SNS验证弱签名、缺乏速率限制和潜在的竞争条件等。
针对AWS SNS的弱签名问题，Warehouse采取了什么整改措施？
已更新为仅接受SHA256签名，以提升安全性。
Warehouse在处理搜索锁定机制时做了哪些改进？
更新了实现以防止潜在的竞争条件，采用了更好的上下文管理器。
对于缺乏速率限制的问题，Warehouse的处理态度是什么？
接受该发现，未来可能会重新评估速率限制策略。
Warehouse如何应对tar.gz文件上传的拒绝服务风险？
已接受该发现，未来可能会增加系统级别的限制。
在XMLRPC服务器中，Warehouse是如何解决不安全的XML处理问题的？
通过升级操作系统解决了不安全的XML处理问题。
