楼主不是专业的网络安全工作者，只是了解过一点入门知识。然而看到论坛里一键脚本 / 面板(往往也用一键脚本安装)如此流行，心有不安。但又不能绝对地下结论说“在座的各位都……不安全”。这里只能尝试分享自己有限的理解，分享一下我自己为什么绝对不会用一键脚本。

首先要说的是，本文指出的问题并非是一键脚本的“原罪”。其他的软件项目也可以有同样的问题。只是在一键脚本这类项目里，这些问题较为常见。

难于审阅

即使开发者完全没有恶意，我也想知道脚本在我的机器上具体做了什么。然后我才能避免与它们冲突，井水不犯河水。

我随手找到了几个用来安装软件 / 配置系统 / dd 的一键脚本，它们的代码长度可以轻易达到上千行。而 shell 脚本的严谨性 / 可读性相比其他编程语言较差，审阅难度颇高。如果我有个同事要用上千行 shell 脚本来实现一个功能，我肯定会先问“咱能换个别的编程语言吗”。

再者，功能范围较广的一键脚本为了提供“一站式服务”，往往还会再去下载调用其他的一键脚本。这样套娃下去，每个脚本都要逐个审核。难上加难。

供应链投毒

用 curl example.com/install.sh | bash 运行脚本时，网址 example.com/install.sh 中的域名 example.com 指向的是自建的 web 服务(有可能套 CDN)，而非托管代码的 GitHub / Gitee 等站点。从善意的角度去想，这可以是为了缩短代码，加速访问，且减少代码托管网站的负担。也许你在 GitHub 上审阅过了代码，感觉没问题。但实际上下载下来的脚本未必是同一份，还得再审。不应直接用管道交给 bash 立即运行。

虽然我愿意相信绝大多数开发者都会珍惜自己的声誉，不会轻易作恶。但也会有项目被卖掉后就被投毒的现象。比如这个例子：mirrors.oneinstack.com 国内完整包 含恶意代码 · Issue #511 · oneinstack/oneinstack · GitHub 初始脚本会去下载一系列源码压缩包，然后在压缩包里曾经一度夹带了木马。最终木马的安装是由压缩包内的构建脚本完成的。

在这个基础上再设想一下：如果投毒方不是持续投毒，而是每天只投一小时。看到论坛上有暴露的风声，就暂停投毒。这样更不容易被白帽子发现，更为隐蔽。反正用户也没有可靠证据来指控投毒。

忽略安全实践

在安装命令或脚本代码里，往往会给 wget 加参数 --no-check-certificate，或者给 curl 加参数 -k / --insecure。亦即，在遇到服务器 TLS 证书错误时，忽略错误继续下载。有些下载 URL 甚至放弃 HTTPS，直接用明文 HTTP。这就给中间人劫持提供了机会。

至于这么做的原因，我猜是因为在老旧系统里，根证书库严重过期，无法验证现今网站的 TLS 证书链。脚本作者为了保证能跑通功能，就放弃安全，满足用户需求。

当然话说回来，HTTPS 也不是必须要用的。在 HTTPS 流行起来之前，Linux 发行版大多用 PGP 数字签名来验证完整性，避免被劫持篡改。现在这个验证机制依然在普遍应用。Ubuntu / Debian 甚至还在默认用明文 HTTP 来提供 -security 仓库的访问。但我从来没见过哪个一键脚本项目会提供数字签名。

实际上真的有中间人劫持吗？有的兄弟，有的。最近在 linux.do 那边就有这么一例从 Cloudflare 回源配置不够严格，疑似为 TLS 降级劫持：使用CloudflareCDN却不幸遭到域名劫持，跳转到恶意网站，如何解决？ - #51，来自 Firgt - 开发调优 - LINUX DO 。虽然这和下载一键脚本的流量方向不同，但劫持原理是一样的。

权衡得失

话又说回来，复用开源项目的代码本来是很平常的事。为什么我对一键脚本要格外地严格对待呢。

首先，几乎所有的一键脚本都需要 root 权限来装软件 / 改系统配置，在 Linux 系统里，root 权限已经是最高了。而在普通的开发项目里引入一个依赖，被依赖的代码只能在应用的权限范围内活动，往往还要限制在容器里运行。

再者，装软件 / 改配置这点事，我自己用 shell / Ansible 去管理也没多难，不值得冒那么大的风险去跑上千行难于审阅的第三方 shell 脚本。这方面有个类似的例子是前端界著名的 left-pad 事件。虽然 left-pad 不是被投毒了，只是被作者删包，无法安装。但是那么点简单的代码也要引入第三方库，增加项目风险，实在是有点没必要。

结语

俗话说得好：怂别用，用别怂。我先怂了，你随意