第三方庫的陷阱
Categories:
- 第三方庫的陷阱
今天聊到最近出的第三方日誌庫的一個漏洞, 可以很低門檻的利用以執行遠程命令. 一個日誌庫和遠程命令看著毫不相干, 但是畫蛇添足的第三方庫遍地都是.
讀的代碼越多越感受到很多開源代碼的水平非常差, 無論它有多少 k 的 star, star 代表了需求, 不代表開發水平.
開源的好處是有更多的人來開發, 好處是特性迅速增加, bug 有人來解, 代碼有人來審核, 但是水平參差不齊.
如果沒有一個強有力的提交約束, 代碼的質量很難保證.
代碼越多增加的攻擊面越多
雖說重復造輪子不好, 但是產品需求就是嬰兒車輪子, 一個塑料輪子怎麼都用不壞, 裝了個飛機輪胎, 徒增攻擊面和維護成本. 因此如果只需要嬰兒車的輪子, 不需要大材小用.
維護成本高, 第三方庫需要專門的流程和人員去維護. 華為一個魔改的測試框架, 直接導致升級編譯器就用例失敗, 升級測試框架和升級編譯器產生沖突, 維護時要花大量時間繼續魔改這條路. 作為參與者深刻體會到魔改三方庫的困難. 如果魔改的是特性可以合回開源庫還好說, 為了自己的需求去侵入式的定制開發, 會導致很難維護.
對待第三方庫華為創建了一系列流程, 可以說阻力重重.
門檻收的極緊, 增加的第三方庫需要 18 級專家和 20 級部長評審, 基本只有久負盛名的三方庫能被使用.
所有第三方庫都放在 thirdparty 文件夾下, 全量編譯時 CI 和源庫對比, 嚴格禁止侵入式修改.
專門的工具追蹤所有第三方庫的版本, 這部分請了外包人員來管理, 如果開發申請升級版本需要提申請, 部長審核.
很難找部長去處理這樣的事, 當一個流程非常繁瑣的時候, 它實際上是在勸你不要這樣做.
對待第三方庫應該保持不輕信的態度, 相信自己人的開發.