操作系統(tǒng)安全是現(xiàn)在最重要的事情，而 Linux 則是一個主要被討論的部分。首先要解決的問題之一就是：我們?nèi)绾未_定提交到上游的補丁已經(jīng)進行了代碼審核?

Wolfram Sang 從 2008 年開始成為一名 Linux 內(nèi)核開發(fā)者，他經(jīng)常在各地召開的 Linux 峰會上發(fā)表講話，比如在 2016 年柏林 Linux 峰會，他提出了如何提高內(nèi)核開發(fā)實踐的想法。

讓我們來看看他的觀點。

在 2013 年的時候，你曾在愛丁堡(Edinburgh)提醒 ELCE 委員會，如果不作出改變，那么子系統(tǒng)的潛在問題和其他爭議問題將會逐漸擴大。他們做出改變了嗎?你所提及的那些事件發(fā)生了嗎?

是的，在某些程度上來說。當(dāng)然了，Linux 內(nèi)核是一個很多部分組成的項目，所以給以 Linux 各個子系統(tǒng)更多關(guān)注應(yīng)該放在一個更重要的位置。然而，有太多的子系統(tǒng)“只是拼圖中的一塊”，所以通常來說，這些子系統(tǒng)的潛在問題還未被解決。

你曾指出代碼審核人數(shù)是一個大問題。為何你覺得 Linux 內(nèi)核開發(fā)社區(qū)沒有足夠的代碼審核人員呢?

理由之一就是，大多數(shù)開發(fā)者實際上只是編寫代碼，而讀代碼并不多。這本是沒有什么錯，但卻說明了并非每個人都是代碼審核人員，所以我們真的應(yīng)該鼓勵每個人都進行代碼審核。

我所看到另一件事就是，但我們要請人員加入我們的社區(qū)時，最重要的考核就是補丁貢獻數(shù)量。我個人認(rèn)為這是很正常的，并且在初期總貢獻量少的時候是非常好的做法。但是隨著越來越多的人員，特別是公司的加入，我們就碰到源碼審核的問題。但是別誤解了，有著數(shù)量可觀的貢獻是很棒的。但目前需要指出的是，參與社區(qū)有著更多內(nèi)涵，比方說如何為下一步發(fā)展負(fù)責(zé)。有些部分在改善，但是還不夠。

你認(rèn)為更多的代碼審核人員培訓(xùn)或者審核激勵措施是否會有幫助?

我最主要的觀點就是要指出，現(xiàn)今仍存在問題。是的，目前為止我們做到很好，但不意味著全都做的很好。我們也有類似擴張方面的問題。讓人們了解事實，是希望能夠讓一些團體對此感興趣并參與其中。盡管，我并不認(rèn)為我們需要特殊的訓(xùn)練。我所熟悉的一些代碼審核人員都非常棒或者很有天賦，只是這類人太少或者他們的空閑時間太少。

首先就是需要有這種內(nèi)在動力，至于其它的，邊做邊學(xué)就非常好了。這又是我想要指出的優(yōu)勢之一：審核補丁能夠使你成為更出色的代碼開發(fā)者。

依你之見，是否有那么一個受歡迎的大項目在擴張這方面做的很好，可以供我們借鑒?

我還真不知道有這么一個項目，如果有的話隨時借鑒。

我很專注于 Linux 內(nèi)核，所以可能會存在一些偏見。然而在我看來，Linux 內(nèi)核項目在規(guī)模大小、貢獻數(shù)量和多樣性方面真的很特別。所以當(dāng)我想要找另一個項目來尋找靈感以便改善工作流是很正常的想法，目前我們的擴張問題真的比較特別。而且我發(fā)現(xiàn)，看看其他子系統(tǒng)在內(nèi)核中做了什么是一個很有的方法。

你曾說安全問題是我們每個人都該想到的事情，那用戶應(yīng)該做些什么來避免或者改善安全問題的危險?

在今年(2016年)柏林 Linux 峰會我的談話是針對開發(fā)層面的。安全隱患可能來自于沒有正確審核的補丁中。我并不想要用戶親自解決這種問題，我更希望這些安全問題永遠(yuǎn)不會出現(xiàn)。當(dāng)然這是不可能的，但這仍然是我處理問題所首選的方法。

我很好奇這個龐大社區(qū)如何改善這些問題。是否有你希望用戶定期以文件形式提交的某些類型的錯誤報告?需要定期檢查的區(qū)域卻因為某些原因沒有注意到的?

我們并不缺少錯誤報告。我所擔(dān)心的是：由于代碼審核人員的短缺造成補丁不完整，從而導(dǎo)致更多的錯誤報告。所以，到時候不僅需要處理大量的貢獻，還需要處理更多錯誤或者進行版本回退。

你是否還有什么事情希望我們讀者知道，以了解你所在的努力?

Linux 內(nèi)核的特殊性，常常讓我牢記著，在底層它就是代碼而已。