在受限环境中避免依赖地狱

在受限环境中避免依赖地狱

这可能是一个典型问题,也可能只是因为我缺乏经验,但我很好奇,当你发现自己处于对常见的开放存储库访问受限的环境中时,是否存在旨在避免依赖地狱的最佳实践。

在我们的具体案例中,我们的困难是在一个大公司的背景下开展工作,该公司的安全政策严重削弱了在安装各种软件时访问外部软件包存储库的能力。

您如何在安全性与访问公共存储库的需求之间取得平衡?有没有办法限制对外部存储库的依赖,而不会导致无法安装 Linux 软件?对于 yum 或 apt-get 存储库的安全性和可靠性,可以提出什么样的论据?

我知道这是一个很宽泛的问题 — — 我希望它在这里是合适的 — — 但我很好奇其他人在这个领域的经验是什么。

答案1

你可以避免依赖地狱(以及一大堆其他问题)更好的当你限制使用的外部存储库数量时。由于你无法保证这些存储库内容的质量、长期可用性和及时性,因此非常依赖其内容(和持续存在)的举动很糟糕。

举个具体的例子,我以前见过一些稳定 Linux 发行版的半官方第三方软件包存储库,随着时间的推移,软件包不断出现。这造成了很大的麻烦,因为我们可能一次构建几台机器,而这些机器都安装了同一版本的关键软件包。一段时间后,当我们去构建更多机器时,我们指定的版本不再可用(被更新、更炫的版本取代),我们必须再次测试所有内容,以确保新软件包仍能正常工作。

这并非最糟糕的情况。如果我们没有测试新软件包,发现其中有一个严重错误?真糟糕。当然,我们选择的版本可能存在安全漏洞,但没关系,因为作为负责任的打包者,我们会密切关注上游安全公告并确保适当修补所有漏洞。

谨慎的管理员仅从两个地方将软件包安装到他/她的系统中:

  • 发行版的官方存储库(当然,经过适当的加密验证以确保真实性),其中软件包的添加和删除方式的政策和实践是已知的,并且符合您自己的风险管理评估;以及
  • 内部管理的软件包存储库或存储库(再次经过加密验证)。

该内部存储库集的内容可以通过几种不同的方式填充:

  • 从外部第三方存储库下载软件包,在测试环境中验证其实用性和稳定性,然后将其添加到存储库。
  • 如果您有点偏执,您可以从上述存储库重建源包,然后测试并添加。
  • 如果你是适当偏执,你把自己关在一间小房间里,没有任何电脑或电子设备。

相关内容