在工作期间分析xz后门目前，已经提出了一些改进软件供应链生态系统的想法。其中一些想法是好的，一些想法充其量是无关紧要和无害的，而一些建议显然是坏的。我想尝试将之前讨论过的两个想法形式化，但它们可以被欣赏的背景并不像今天那么清楚。
- 可复制的柏油球。其想法是，发布的源tarball应该能够以某种方式独立复制，并且应该不断测试和验证，最好是作为上游项目持续集成系统的一部分（例如GitHub操作或GitLab管道）。虽然名义上这看起来很容易实现，但其中有一些复杂的问题，例如：tarball中的文件使用什么时间戳？我已经提出了这个方面之前。
- 在没有生成供应商文件的情况下，最小化源tarball。大多数基于GNU Autoconf/Automake的tarball预先生成文件，这些文件对于在没有所需依赖关系的外来系统上进行引导很重要。要使引导故事成功，必须支持这种方法。然而，很明显，这种做法会带来巨大的成本和风险。大多数现代GNU/Linux发行版都具有所有必需的依赖性，实际上更喜欢从源代码重新构建所有内容。这些预先生成的额外文件给该过程带来了不确定性。
我提出的改进建议是定义新的tarball格式*-src.tar.gz公司至少具有以下属性：
- tarball应该允许用户构建项目，这就是所有这些的全部目的。这意味着至少必须包含项目的所有源代码。
- tarball应该签名，例如使用PGP或minisign。
- tarball应该可以由第三方使用上游的版本控制源和使用修订的指针（例如git标记或git提交）逐位复制。
- tarball不需要互联网连接就可以下载东西。
- 推论：每个外部依赖项要么必须明确记录下来（例如，gcc和GnuTLS），要么包含在tarball中。
- 观察：这意味着包括所有
*.po型 获取文本通常从版本控制源构建时下载的翻译。
- tarball应该包含使用尽可能多的外部发布版本化工具从源代码构建项目所需的所有内容。这是目前所缺乏的“最小”财产。
- 推论：这意味着包括OpenSSL或libz的供应商副本是不可接受的：作为外部项目链接到它们。
- 开放性问题：非发布的外部工具如何，例如格努利布或autoconf存档宏? 这有点微妙：大多数发行版要么只打包一个当前版本的gnulib，要么打包autoconf存档，而不是打包以前的版本。虽然这可能会发生变化，但发行版可以打包gnulib git存储库（直到某些当前版本）和autoconf存档git存储库可提取所需的版本(格努利布的/引导程序已经通过支持此–gnulib-refdir参数)，这通常不到位。
- 建议的推论：tarball应该包含git子模块的内容，例如gnulib和项目所需的必要Autoconf存档M4宏。
- 类似于GNU项目指定的方式/配置界面我们需要一个文档化的接口来指导如何引导项目。我建议使用已经很成熟的跑步习惯用法
./引导设置包以便以后可以通过./配置。当然，有些项目没有使用autotool./配置接口，也不会遵循这一点，但与autotools竞争的大多数构建系统都有关于如何构建项目的说明，它们应该记录类似的接口，以便引导源tarball进行构建。
如果实现上述目标的tarball可以从流行的上游项目中获得，那么发行版可以更容易地使用它们，而不是当前包含预生成内容的tarball。优点是构建过程不会被“不必要的”文件污染。我们需要为维护人员开发工具来创建这些tarball，类似于制造距离产生今天的foo-1.2.3.tar.gz（目标.gz）文件夹。
我认为反对这种方法的一个常见论点是：为什么要费心这么做，而只是使用git存档输出？或者避免整个tarball方法，直接转向版本控制的签出，并将上游版本称为git URL和commit标记或idSHA-1断裂，因此信任SHA-1标识符是不安全的。另一个反驳意见是，这以上游维护者为代价优化了打包者的利益：大多数上游维护者不想存储gettext*.po型源代码存储库中的翻译。在维护者和包装者的需求之间进行折衷是有用的，因此*-src.tar.gz公司tarball方法是我们需要解决的间接方法。更新：在我的实验中仅为Libntlm提供源代码tarball我实际上使用了git-archive输出。
你怎么认为？