事後諸葛亮:如何寫出沒有bug的軟體

發表於 2022-11-28

網上對蘋果iOS7作業系統中最新暴露出的一個嚴重安全漏洞的討論讀起來十分有趣。如果你還沒有讀過Alex Langley對此的分析,那現應該讀一下,寫的非常好。

附帶說一下,是一個TLS v1.2 SSL連線問題上的bug,簽名認證沒有被檢查,使偽造簽名成為可能。原因是程式碼永久的直接跳到了方法的結尾處,沒有實際檢查雜湊結果是否正確。

問題程式

是什麼導致了這樣一個弱者的bug?我四處看了一下,下面是網友們總結出的幾個原因:

  • 用C語言很難寫出正確無誤的程式
  • 蘋果公司的程式設計師不用心
  • 編碼風格中允許忽略大括號
  • 蘋果公司裡沒有正規的程式碼審查
  • 使用了goto語句
  • 使用了自動程式碼合併
  • 沒有開啟編譯器對死程式碼的警告
  • 沒有使用靜態分析工具
  • 沒有好好測試

所有的這些原因看起來都像是在這個bug的產生中扮演了一定的角色。但有一個主導原因嗎?

對程式碼的差異對比給不了多少有用的資訊,在631行上的這個bug看起來怎麼產生的都有可能。也許是一次程式碼合併錯誤,也許是愚蠢的複製/貼上造成。

事實上,你很難,或許不可能找到一個單一的為此bug負責的原因,那我們能有什麼良方?很多人說是指程式碼上沒有用花括號包圍的原因。例如Zed說:

這就是帕金森瑣碎定理的一個很好的例子:花費大量時間討論無關緊要的瑣事。引起這個bug的根源不是缺少花括號。有沒有花括號不會成為這個多餘的goto的產生的原因。

為什麼我們,程式設計師們,總是抱怨編碼風格問題,但卻不重視程式碼審查對程式正確性的決定作用呢?雖然不好的編碼風格會隱藏程式bug,但並不是編碼風格產生的問題。我們太重視程式碼佈局視覺上的問題,卻故意逃避正確性問題。如果更注重正確性,絕對不可能讓這種關鍵程式碼中未經測試的情況下發布。

好的編碼風格並不能防止大部分的bug的產生——儘管有點作用。簡單的程式語言能夠減少bug的產生。程式碼審查的作用更大。靜態分析能讓你避免大量的bug。

認真的測試可以捕捉並防止很多bug的產生。這就是為什麼對於關鍵的軟體,比如cryptography
library
,有100%的測試覆蓋率。這種一眼就能看出來的bug絕對不會在這種軟體裡出現。

未經測試的加密程式碼是用來解密的程式碼。

所以說,抱怨花括號是愚蠢的做法。相反,在這種情況下花括號會讓問題更難發現,花括號不是問題的根源,也不是問題的解決方案。大家找錯了方向。

[英文原文:Wrong Solutions ]
via: http://www.vaikan.com/wrong-solutions/