Python 高手编程系列一千零五十二：可执行包中 Python 代码的安全性

独立可执行文件决不会让应用代码变得安全，知道这一点是很重要的。从这样的可执
行文件中反编译嵌入代码并不是一件容易的任务，但它的确是可行的。更重要的是，这种
反编译的结果（如果使用适当的工具）可能与原始源代码非常相似。
由于这一事实，对于泄露应用代码会对组织带来危害的闭源项目来说，独立 Python 可
执行文件并不是一个可行的解决方案。因此，如果仅复制应用的源代码就可以复制你的整
个业务，那么你应该考虑其他方法来分发应用。提供软件作为服务可能是更好的选择。
使反编译更难
如前所述，没有可靠的方法能够保护应用不被目前可用的工具反编译。不过仍有一些
方法可以使这个过程变得更加困难。但更加困难并不意味着可能性更小。对于我们中的一
些人来说，最吸引人的挑战正是最难的那些。并且我们都知道，这项挑战的最终奖励是非
常大的：就是你设法保护的代码。
通常来说，反编译过程包括以下几个步骤，如下所示。
• 从独立可执行文件中提取项目字节码的二进制表示。
• 将二进制表示映射到特定 Python 版本的字节码。
• 将字节码转换成 AST。
• 从 AST 直接重新创建源代码。
想要阻止开发者对独立可执行文件进行这种逆向工程，提供精确的解决方案毫无意义，
原因显而易见。所以我们只给出一些想法，可以阻止反编译过程或者使其结果变得没有价值。
• 运行时删除所有可用的代码元数据（文档字符串），从而稍微降低最终结果的可读性。
• 修改 CPython 解释器使用的字节码，这样从二进制转换成字节码、随后再转换成
AST 需要花费更多精力。
• 用复杂的方式修改 CPython 源代码版本，这样即使得到了应用的反编译源代码，没
有对修改过的 CPython 库反编译也是没有用的。
• 在将源代码打包成可执行文件之前对源代码使用混淆脚本，这将会使反编译后的源
代码变得没有价值。
这些解决方案都会使开发过程变得更加困难。上面的某些想法还需要对 Python 运行有
非常深入的理解，但每一个想法都有许多陷阱和缺点。大多数情况下，它们只是将不可避
免的结果推迟了而已。一旦你的把戏被识破了，你所有额外的努力都将变成时间和资源的
浪费。
要想不让闭源代码泄露到应用之外，唯一可靠的方法是就是不以任何形式将其直接发
送给用户。只有你的组织其他方面的安全性都做得很好时，这种方法才有效。
小结
本章描述了 Python 打包生态系统的细节。现在，读完本章之后，你应该知道哪些工具
适合你的打包需求，也知道你的项目需要哪种类型的发行版。你还应该知道解决常见问题
的常用技术，以及如何为项目提供有用的元数据。
我们还讨论了独立可执行文件的话题，它非常有用，特别是在分发桌面应用时。
下一章将大量依赖于我们本章所学的内容，来展示如何用可靠的自动化方法有效地处
理代码部署。
部署代码
即使是完美的代码（如果存在的话），如果它没有运行也是没有用的。所以为了实现某
个目的，我们需要在目标机器（计算机）上安装我们的代码并执行。使特定版本的应用或
服务对最终用户可用的过程叫作部署（deployment）。
对于桌面应用而言，这似乎很简单——提供一个可下载的软件包即可，必要时提供可
选的安装器。用户负责下载并在环境中安装。你的责任是使这个过程尽可能简单方便。正
确的打包仍然不是一项简单的任务，但上一章已经介绍过一些工具。
令人惊讶的是，如果你的代码本身不是一个产品，那么事情会变得更加复杂。如果你
的应用仅提供向用户销售的服务，那么你有责任在自己的基础设施上运行它。这个场景对
于 web 应用或任何“X 即服务”的产品来说是非常典型的。在这种情况下，代码被部署到
远程机器上，开发人员通常几乎无法实体访问这些机器。如果你已经是云计算服务（例如
亚马逊网络服务（AWS 或 Heroku）的用户的话，则更是如此。
本章我们重点关注将代码部署到远程主机方面的内容，因为 Python 在构建各种与 Web
相关的服务和产品的领域非常流行。虽然这门语言具有很高的可移植性，但却无法保证代
码能够轻松部署。最重要的是应用的构建方式，以及将其部署到目标环境中所使用的流程。
因此本章将重点讨论以下主题：
● 将代码部署到远程环境的主要挑战是什么？
● 在 Python 中如何构建易于部署的应用？
● 如何在不停机的情况下重新加载 Web 服务？
● 在代码部署中如何利用 Python 打包生态系统？
● 如何正确地监视并检测远程运行的代码？
二：可执行包中 Python 代码的安全性