4

Where I currently work we've had a small debate about deploying our Python code to the production servers. I voted to build binary dependencies (like the python mysql drivers) on the server itself, just using pip install -r requirements.txt. This was quickly vetoed with no better explanation that "we don't put compilers on the live servers". As a result our deployment process is becoming convoluted and over-engineered simply to avoid this compilation step.

My question is this: What's the reason these days to avoid having a compiler on live servers?

4

3 回答 3

5

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

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

在我的公司，我们通常不太关心编译器是否安装在我们的服务器上，但我们也从不在我们的服务器上运行pip，原因完全不同。我们并不关心包在哪里构建，而是何时以及如何下载它们。

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

  • 如果 pypi - 或托管您的依赖项的任何其他站点 - 出现故障，那么您的构建过程将失败
  • 如果攻击者在尝试下载依赖包时设法对您的服务器执行中间人攻击，那么他将能够在下载中插入恶意代码

所以，我们在第一次添加依赖的时候下载包，尽量确保源是正版的（这不是万无一失的），并将它们添加到我们自己的版本控制系统中。我们确实在单独的构建服务器上构建我们的包，但这并不重要；我们只是发现拥有一个可以快速部署到多个实例的二进制包很有用。

于 2012-05-01T03:13:53.880 回答
1

我建议参考这个serverfault 帖子。

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

对我来说，就安全性而言，与使用编译器相比，它只会使劫持者的任务更难完成，但这并不完美。

于 2012-04-30T20:30:09.143 回答
0

会给服务器带来很大的压力吗？

于 2012-04-30T20:23:40.910 回答