第三方库的陷阱

• 第三方库的陷阱

今天聊到最近出的第三方日志库的一个漏洞, 可以很低门槛的利用以执行远程命令. 一个日志库和远程命令看着毫不相干, 但是画蛇添足的第三方库遍地都是.

读的代码越多越感受到很多开源代码的水平非常差, 无论它有多少 k 的 star, star 代表了需求, 不代表开发水平.

开源的好处是有更多的人来开发, 好处是特性迅速增加, bug 有人来解, 代码有人来审核, 但是水平参差不齐.

如果没有一个强有力的提交约束, 代码的质量很难保证.

代码越多增加的攻击面越多

虽说重复造轮子不好, 但是产品需求就是婴儿车轮子, 一个塑料轮子怎么都用不坏, 装了个飞机轮胎, 徒增攻击面和维护成本. 因此如果只需要婴儿车的轮子, 不需要大材小用.

维护成本高, 第三方库需要专门的流程和人员去维护. 华为一个魔改的测试框架, 直接导致升级编译器就用例失败, 升级测试框架和升级编译器产生冲突, 维护时要花大量时间继续魔改这条路. 作为参与者深刻体会到魔改三方库的困难. 如果魔改的是特性可以合回开源库还好说, 为了自己的需求去侵入式的定制开发, 会导致很难维护.

对待第三方库华为创建了一系列流程, 可以说阻力重重.

门槛收的极紧, 增加的第三方库需要 18 级专家和 20 级部长评审, 基本只有久负盛名的三方库能被使用.

所有第三方库都放在 thirdparty 文件夹下, 全量编译时 CI 和源库对比, 严格禁止侵入式修改.

专门的工具追踪所有第三方库的版本, 这部分请了外包人员来管理, 如果开发申请升级版本需要提申请, 部长审核.

很难找部长去处理这样的事, 当一个流程非常繁琐的时候, 它实际上是在劝你不要这样做.

对待第三方库应该保持不轻信的态度, 相信自己人的开发.