PEP 721 – 使用 tarfile.data_filter 提取源代码发行版
- 作者:
- Petr Viktorin <encukou at gmail.com>
- PEP 代表:
- Paul Moore <p.f.moore at gmail.com>
- 状态:
- 最终
- 类型:
- 标准跟踪
- 主题:
- 打包
- 需求:
- 706
- 创建:
- 2023年7月12日
- Python 版本:
- 3.12
- 历史记录:
- 2023年7月4日
- 决议:
- 讨论消息
摘要
提取源代码发行版归档文件通常应使用在 PEP 706 中添加的 data
过滤器。我们阐明了细节,并指定了无法直接使用该过滤器的工具的行为。
动机
源代码发行版 sdist
定义为 tar 归档文件。
tar
格式旨在捕获类 Unix 文件的所有元数据。其中一些是危险的,对于源代码来说是不必要的,并且/或者依赖于平台。如 PEP 706 中所述,在提取 tarball 时,应始终限制允许的功能,或明确赋予 tarball 完全控制权。
基本原理
对于源代码发行版,在 PEP 706 中引入的 data
过滤器就足够了。它允许的功能略多于 git
和 zip
(这两种方法通常用于打包工作流程)。
但是,并非所有工具都能使用 data
过滤器,因此本 PEP 指定了一组明确的期望。目标是使 pip download
和 setuptools.archive_util.unpack_tarfile
的当前行为有效,除了被认为过于危险而无法允许的情况。另一个考虑因素是非 Python 工具的易于实现性。
未修补的 Python 版本
在没有 tarfile 过滤器的 Python 上运行时,工具可以忽略此 PEP。
该功能已反向移植到 python.org
支持的所有 Python 版本。在第三方库中进行移植很棘手,我们不应该强制所有工具都这样做。这将保持安全更新的责任从工具转移到用户身上。
权限
常用工具(git
、zip
)不保留 Unix 权限(模式位)。告诉用户不要在 sdists 中依赖它们,并允许工具相对自由地处理它们,这似乎是公平的。
唯一的例外是可执行权限。我们建议,但不强制要求,工具保留它。鉴于脚本通常是特定于平台的,因此可以说保持它们的可执行性是特定于工具的行为。
请注意,虽然 git
保留可执行性,但 zip
(以及 wheel
)不能原生做到这一点。(可以在“外部属性”中对其进行编码,但 Python 的 ZipFile.extract
不支持该属性。)
规范
以下内容将添加到 PyPA 源代码发行版格式规范 中的新标题“源代码发行版归档功能”下
由于按原样提取 tar 文件很危险,并且结果是特定于平台的,因此源代码发行版的归档功能受到限制。
使用数据过滤器解包
在提取源代码发行版时,工具必须使用 tarfile.data_filter
(例如 TarFile.extractall(..., filter='data')
),或者遵循下面“不使用数据过滤器解包”部分中的说明。
作为例外,在没有 hasattr(tarfile, 'data_filter')
的 Python 解释器上(PEP 706),通常使用该过滤器(直接或间接)的工具可以警告用户并忽略此规范。在这种情况下,可用性(例如,完全信任归档文件)和安全性(例如,拒绝解包)之间的权衡由工具决定。
不使用数据过滤器解包
不直接使用 data
过滤器的工具(例如,为了向后兼容性、允许其他功能或不使用 Python)必须遵循本节。(在撰写本文时,data
过滤器也遵循本节,但将来可能会不同步。)
以下文件在 sdist
归档文件中无效。遇到此类条目时,工具应通知用户,不得解包该条目,并且可以中止并报错。
- 将放置在目标目录之外的文件。
- 指向目标目录之外的链接(符号或硬链接)。
- 设备文件(包括管道)。
以下文件也无效。工具可以像上面那样处理它们,但不强制要求这样做。
- 文件名或链接目标中包含
..
组件的文件。 - 指向归档文件中不存在的文件的链接。
工具可以将链接(符号或硬链接)解包为普通文件,使用归档文件中的内容。
提取 sdist
归档文件时
- 必须删除文件名中的前导斜杠。(这现在是
tar
解包的标准行为。) - 对于每个
mode
(Unix 权限)位,工具必须- 使用平台为新文件/目录(分别)的默认值,
- 根据归档文件设置该位,或
- 对于不可执行文件使用
rw-r--r--
(0o644
) 中的位,或者对于可执行文件和目录使用rwxr-xr-x
(0o755
) 中的位。
- 必须清除高
mode
位(setuid、setgid、sticky)。 - 建议保留用户可执行位。
更多提示
鼓励工具作者考虑 tarfile
文档中“进一步验证的提示”如何适用于他们的工具。
向后兼容性
现有行为未指定,并且不同工具的处理方式不同。此 PEP 明确了期望。
没有已知的向后兼容性问题,但某些项目可能依赖于未保证的细节。此 PEP 禁止其中最危险的功能,其余功能则特定于工具。
安全影响
建议的 data
过滤器被认为对常见漏洞是安全的,并且是将来发现缺陷时进行修改的唯一位置。
明确的规范包括来自 data
过滤器的保护。
如何教授
PEP 面向打包工具的作者,他们应该对 PEP 和更新的打包规范感到满意。
参考实现
待定
被拒绝的想法
目前还没有。
未解决的问题
目前还没有。
版权
本文件置于公共领域或根据 CC0-1.0-Universal 许可证发布,以更具许可性的为准。
来源:https://github.com/python/peps/blob/main/peps/pep-0721.rst