在实时服务器上不托管编译器的原因是什么？

Question

在我目前的工作中，我们就将Python代码部署到生产服务器进行了一场小小的讨论。我投票在服务器本身上构建二进制依赖项（如python mysql驱动程序），只使用pip install -r requirements.txt。这很快得到了否决，没有更好的解释，“我们不把编译器放在实时服务器上”。因此，我们的部署过程变得复杂和过度设计，只是为了避免这个编译步骤。

我的问题是：现在避免在实时服务器上安装编译器的原因是什么？

Answer 1

一般来说，服务器安装的普遍看法是它们应该尽可能地被剥离。这有一些动机，但它们并没有真正直接应用于您关于编译器的问题：

• 最大限度地减少资源使用。 GCC可能会占用一些额外的磁盘空间，但可能还不够重要 - 而且大部分时间都不会运行，因此CPU /内存使用量不足这是一个很大的问题。
• 最大限度地降低复杂性。在您的服务器上构建可能会为您的构建过程添加一些故障模式（如果您在其他地方构建，那么至少在之前你会发现错误你弄乱了你的生产服务器），但除此之外，它不会妨碍。
• 最小化attack surface 。正如其他人所指出的，当攻击者可以使用编译器时，你可能已经搞砸了......

在我的公司，如果我们的服务器上安装了编译器，我们通常不会太在意，但我们也永远在我们的服务器上运行pip，原因完全不同。我们并不关心构建软件包的位置，而是关注它们的下载时间和方式。

我们中间特别偏执的人会注意到pip（和easy_install）会很乐意从PYPI安装软件包而不需要任何形式的身份验证（没有SSL，没有软件包签名，......）。此外，其中许多实际上并未在PYPI上托管; pip和easy_install遵循重定向。所以，这里有两个问题：

• 如果pypi - 或托管您的依赖项的任何其他网站 - 发生故障，那么您的构建过程将失败
• 如果攻击者以某种方式设法对您的服务器进行中间人攻击，因为它正在尝试下载依赖包，那么他将能够将恶意代码插入下载

因此，我们在首次添加依赖项时下载软件包，尽力确保源代码是真的（这不是万无一失），并将它们添加到我们自己的版本控制系统中。我们实际上是在一个单独的构建服务器上构建我们的软件包，但这不是那么重要;我们发现有一个二进制包很有用，我们可以快速部署到多个实例。

Answer 2

我建议您参考此serverfault post。

避免远程编译漏洞是有意义的

对我而言，在安全性方面，它只会使劫持者的任务比使用编译器更难，但它并不完美。

Answer 3

这会给服务器带来沉重的压力吗？