Gulp即将滑向Log4j2的深渊

​​

log4shell漏洞暂时平息之际，是时候注意其他类似log4j流行度极广而又非常缺乏维护的包了，在前端十分流行任务运行器gulp就是其中一个值得关注的对象。

查阅一下gulp的release，发现最后一次更新是2019年5月7日发布的v4.0.2，但请注意，从v4.0.0开始这就是一个破坏性的版本，连声明task的方式都发生了变化，task是gulp的基石，这种根基上的修改很难使人愿意对其进行升级，依然有很多人在使用v3.9.1，过去七天内它的下载量仍然高达30万次，在Github是查看这是一个2019年4月22日的版本，这一天gulp在12:56时同时发布了以下版本：

v4.0.1, v3.9.1, v3.9.0, v3.8.11, v3.8.10, v3.8.9, v3.8.8, v3.8.7, v3.8.6, v3.8.5, v3.8.4, v3.8.3, v3.8.1

这是非常糟糕的发布方式，怎么会有人在同一时刻发布这么多版本？这是不可能的，在npm上查一下原来v3.8.1发布于2014年6月18日，但gulp团队在2019才在Github上同步发行了它，这是因为gulp在2019年才开放源代码吗？当然不是，gulp2013年6月4日就建立了gulp，他只是一直无视Github的release，那时候gulp还是用coffeescript编写的，gulp早已全盘抛弃了coffeescript，如今它似乎连自己也要抛弃了。

由于npm设计的非常糟糕，参考npm-audit-broken-by-design，使很多开发人员不想去处理由npm报告的漏洞，很多微不足道的问题被打上critical或high的安全问题，他们也许真的写了非常危险的代码，但是这些危险是需要一个入口的，绝大多数情况下，这个入口只存在于幻想之中或是源代码被修改，这让大家都变成了惊弓之鸟。对此开发者们分为两派，一派彻底放弃npm的管理，将依赖包集成到内部，package.json变的干干净净，npm无法扫描到依赖项，由自己把控安全风险，这一派可以称为自信派。另一派则坚持传统，但对安全问题摆烂，禁止社区报告安全漏洞，坚持不修复安全漏洞。gulp就是传统派，即使有人写好了升级项#2630，gulp也拒绝merge，认为这些东西都是nothing的，还会破坏现状，现在安装gulp@v4.0.2，由于愚蠢的glob-parent，npm将报告6个高危漏洞，实际上gulp.src()，gulp.watch()都有可能引发漏洞，把漏洞的入口交给了用户，他们说开发人员们应该清楚自己使用了什么路径，但如今时代不同很多路径也都是拼合而来的，gulp也早已进入了许多CI/CD中，gulp不再是一个“第一入口”，也在逐渐成为一个“中间件”，真的有必要保持这么多年的自信吗，升级glob-parent不会让gulp失去什么，只会让它变得健壮。

谈到CI方面，gulp的Appveyor CI失败已经两年多了，github对每次CI失败都会向contributors们发送失败的邮件，gulp的开发人员情愿收两年邮件也不愿意修复这样的错误，当然也可能早已拒收了来自gulp的邮件。令人惊奇的是，这个CI还在尝试在Node 0.10.48这种平台上运行gulp，而所尝试的最新的平台也仅是Node 10.24.1，面对如今的Node 17.4.0，它实在掉队太远太远了，不过也不用怀疑是否有效，Node也是热衷于破坏性更新的，已经有中国的开发者报告在Node 14 support上的问题了（存疑，我同样在Node14.x上跑gulp，watch部分从2020年底到如今都运行良好）。

尽管到目前为止gulp并没有出现较大的安全危机，但最后一次package升级，已经是2019年4月22日的一个commit，所直接或间接依赖的274个module，他们未来的安全性，随着gulp几乎停止的维护令人越来越感到担忧，同时对于平台的支持性，gulp越来越滞后，Node的LTS版本也从14升到了16，gulp还停留在10.x，未来这个项目即使要继续维护，也要经过很多大修大改，在生态方面，很多包还在用gulp早年推出的gulp-util，如今它已经被废弃5年之久，gulp-typescript在使用的ts版本为3.6.3，而现在的ts最新版是4.6.0，即使无力维护对typescript的支持，3.x的版本最新的也应该是3.9.7，gulp-typescript已经停更两年了，UglifyJS发布了v3.15.0，而还在使用v3.0.5的gulp-uglify已经停止更新3年多了，gulplog已经6年没有更新，连gulp自己都放弃了它，宁愿更多的使用console.log这样完全无法控制的东西，这个快速，支持并行的任务运行器还会持续存活吗？还是等来正式的停止维护通知？还是像Log4j2？

Log4j2从2018年3月到高危漏洞事发前夕3年半的时间总计不到1000个commit，比2013年到2018年间任何一年的commit量都要低，当一个基础项目的维护变得缓慢都将引发灾难，那么一个基础项目彻底停止呢？

如果Gulp陷入这样的境地，和现在一样持续的无法支持新版node，无法支持新版ts，欠账越累越多，未来使用的人就会越来越少，那一直所依赖gulp构建的项目又将不得不换成与其相似的任务运行器Grunt，而Grunt与Gulp的差异极大，同时Grunt是笨重的，它通常产生临时文件，不像Gulp专注于stream的传输，且不能并行执行，是一种极大的限制，通常情况下Grunt 需要的时间几乎是 Gulp 的两倍，这场向下“升级”又是一场前端的领域的Log4j2式的灾难