tar-codec：为 Rust 生态打造的高效安全 tar 解析器
内容提要
uv 0.13 起采用自研 tar-codec 解析源码包，速度约为旧实现的两倍，并减少解析差异与安全风险。tar 格式存在 V7、UStar/pax、GNU 等变体，状态机复杂，易被利用产生解析差异。tar-codec 按魔数锁定单一格式，严格处理 pax 扩展头优先级与 GNU 扩展，拒绝混合格式，并通过分层设计与 cap-std 安全解压，提升安全性与性能。
延伸解读
解析差异为何成为安全焦点
文章指出，tar 格式的多种变体（V7、UStar/pax、GNU）各有复杂状态机，且许多解析器允许状态混合，导致同一压缩包在不同工具中解析出不同内容。这种“解析差异”可能被攻击者利用，构造对索引看似安全、但对安装器危险的包。uv 因此放弃修补旧库，转而自研 tar-codec，从设计上拒绝混合格式，以消除此类风险。
严格锁定格式的取舍
tar-codec 在解析开始时根据首个块的魔数锁定单一 tar 家族（UStar/pax 或 GNU），并拒绝头部不一致的归档。文章承认这会牺牲对混合格式的兼容，但强调现实中的编码器不会混用格式，因此破坏风险很小。这种“保守接受”的策略是减少差异的关键，但也意味着某些非标准归档可能无法解析。
性能提升与安全解压的平衡
tar-codec 解析速度约为旧实现的两倍，优化包括校验和生成、pax 记录长度计算及内存分配复用。然而，安全解压并非没有代价：基于 cap-std 的目录能力跟踪在缺乏 openat2 的系统（如 macOS）上会带来可测量的开销。文章表明，性能与安全在此并非完全对立，但解压环节仍需权衡系统调用成本。
对 pax 规范的务实妥协
尽管 tar-codec 力求严格，文章透露它不得不对 pax 规范做若干妥协，以兼容现实实现。例如，pax 要求记录值为 UTF-8，但 GNU tar 和 star 曾输出二进制厂商记录；CPython 的 tarfile 允许 uname/gname 填满 32 字节而非 NUL 终止。tar-codec 默认拒绝厂商记录，但提供忽略选项，并跟踪缺失字段而非赋默认值，体现了在规范与现实间的谨慎取舍。
Q&A
uv 从哪个版本开始默认使用 tar-codec 解析源码包？
从 uv 0.13 起，tar-codec 成为默认的 tar 解析器，可通过设置 UV_LEGACY_TAR_BACKEND=1 禁用。
tar-codec 相比 uv 之前的 tar 实现有哪些优势？
tar-codec 解析速度约为旧实现（astral-tokio-tar）的两倍，同时通过严格拒绝混合格式和解析差异，降低了 uv 暴露于解析器差异和其他安全风险的程度。
为什么 uv 要放弃 astral-tokio-tar 而自研 tar 解析器？
主要出于安全考虑：astral-tokio-tar 收到多个安全报告，且其设计过于宽松，容易产生解析器差异（如追加差异或完全差异），导致同一 tar 包在不同工具中解析出不同内容。此外，旧代码库无法在不重写的情况下达到性能目标，因此决定从头实现。
tar-codec 如何防止不同 tar 格式变体混合导致的解析差异？
tar-codec 在解析开始时根据第一个块的魔数和版本进行“分类”，将后续解析锁定为单一格式家族（UStar/pax 或 GNU）。如果后续头块与初始家族不一致，则拒绝该归档，从而避免混合格式带来的语义不清和潜在差异。
tar-codec 如何处理 pax 扩展头的优先级和“墓碑”记录？
tar-codec 严格遵循 pax 规范：局部扩展头（x）优先于全局扩展头（g），且全局头影响后续所有成员。对于值为空的记录（墓碑），它视为显式删除对应字段，并会拒绝因此产生的无路径等无意义状态。
tar-codec 在解压到磁盘时如何保证安全？
tar-codec 通过分层设计将解析与解压分离，并基于 cap-std 实现文件系统解压，将解压操作“锚定”在单一目录内，从而避免链接和路径遍历等常见安全陷阱。
