Documentation/translations/zh_TW/admin-guide/security-bugs.rst - linux - Git at Google

 .. SPDX-License-Identifier: GPL-2.0

 .. include:: ../disclaimer-zh_TW.rst

 :Original: :doc:`../../../admin-guide/security-bugs`

 :譯者:

  吳想成 Wu XiangCheng <bobwxc@email.cn>
  胡皓文 Hu Haowen <src.res@email.cn>

 安全缺陷
 =========

 Linux內核開發人員非常重視安全性。因此我們想知道何時發現了安全漏洞，以便儘快
 修復和披露。請向Linux內核安全團隊報告安全漏洞。

 聯絡
 -----

 可以通過電子郵件<security@kernel.org>聯繫Linux內核安全團隊。這是一個安全人員
 的私有列表，他們將幫助驗證錯誤報告並開發和發布修復程序。如果您已經有了一個
 修復，請將其包含在您的報告中，這樣可以大大加快進程。安全團隊可能會從區域維護
 人員那裡獲得額外的幫助，以理解和修復安全漏洞。

 與任何缺陷一樣，提供的信息越多，診斷和修復就越容易。如果您不清楚哪些信息有用，
 請查看「Documentation/translations/zh_TW/admin-guide/reporting-issues.rst」中
 概述的步驟。任何利用漏洞的攻擊代碼都非常有用，未經報告者同意不會對外發布，除
 非已經公開。

 請儘可能發送無附件的純文本電子郵件。如果所有的細節都藏在附件里，那麼就很難對
 一個複雜的問題進行上下文引用的討論。把它想像成一個
 :doc:`常規的補丁提交 <../process/submitting-patches>` （即使你還沒有補丁）：
 描述問題和影響，列出復現步驟，然後給出一個建議的解決方案，所有這些都是純文本的。

 披露和限制信息
 ---------------

 安全列表不是公開渠道。爲此，請參見下面的協作。

 一旦開發出了健壯的補丁，發布過程就開始了。對公開的缺陷的修復會立即發布。

 儘管我們傾向於在未公開缺陷的修復可用時即發布補丁，但應報告者或受影響方的請求，
 這可能會被推遲到發布過程開始後的7日內，如果根據缺陷的嚴重性需要更多的時間，
 則可額外延長到14天。推遲發布修復的唯一有效原因是爲了適應QA的邏輯和需要發布
 協調的大規模部署。

 雖然可能與受信任的個人共享受限信息以開發修復，但未經報告者許可，此類信息不會
 與修復程序一起發布或發布在任何其他披露渠道上。這包括但不限於原始錯誤報告和
 後續討論（如有）、漏洞、CVE信息或報告者的身份。

 換句話說，我們唯一感興趣的是修復缺陷。提交給安全列表的所有其他資料以及對報告
 的任何後續討論，即使在解除限制之後，也將永久保密。

 協調
 ------

 對敏感缺陷（例如那些可能導致權限提升的缺陷）的修復可能需要與私有郵件列表
 <linux-distros@vs.openwall.org>進行協調，以便分發供應商做好準備，在公開披露
 上游補丁時發布一個已修復的內核。發行版將需要一些時間來測試建議的補丁，通常
 會要求至少幾天的限制，而供應商更新發布更傾向於周二至周四。若合適，安全團隊
 可以協助這種協調，或者報告者可以從一開始就包括linux發行版。在這種情況下，請
 記住在電子郵件主題行前面加上「[vs]」，如linux發行版wiki中所述：
 <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>。

 CVE分配
 --------

 安全團隊通常不分配CVE，我們也不需要它們來進行報告或修復，因爲這會使過程不必
 要的複雜化，並可能耽誤缺陷處理。如果報告者希望在公開披露之前分配一個CVE編號，
 他們需要聯繫上述的私有linux-distros列表。當在提供補丁之前已有這樣的CVE編號時，
 如報告者願意，最好在提交消息中提及它。

 保密協議
 ---------

 Linux內核安全團隊不是一個正式的機構實體，因此無法簽訂任何保密協議。
	.. SPDX-License-Identifier: GPL-2.0

	.. include:: ../disclaimer-zh_TW.rst

	:Original: :doc:`../../../admin-guide/security-bugs`

	:譯者:

	吳想成 Wu XiangCheng <bobwxc@email.cn>
	胡皓文 Hu Haowen <src.res@email.cn>

	安全缺陷
	=========

	Linux內核開發人員非常重視安全性。因此我們想知道何時發現了安全漏洞，以便儘快
	修復和披露。請向Linux內核安全團隊報告安全漏洞。

	聯絡
	-----

	可以通過電子郵件<security@kernel.org>聯繫Linux內核安全團隊。這是一個安全人員
	的私有列表，他們將幫助驗證錯誤報告並開發和發布修復程序。如果您已經有了一個
	修復，請將其包含在您的報告中，這樣可以大大加快進程。安全團隊可能會從區域維護
	人員那裡獲得額外的幫助，以理解和修復安全漏洞。

	與任何缺陷一樣，提供的信息越多，診斷和修復就越容易。如果您不清楚哪些信息有用，
	請查看「Documentation/translations/zh_TW/admin-guide/reporting-issues.rst」中
	概述的步驟。任何利用漏洞的攻擊代碼都非常有用，未經報告者同意不會對外發布，除
	非已經公開。

	請儘可能發送無附件的純文本電子郵件。如果所有的細節都藏在附件里，那麼就很難對
	一個複雜的問題進行上下文引用的討論。把它想像成一個
	:doc:`常規的補丁提交 <../process/submitting-patches>` （即使你還沒有補丁）：
	描述問題和影響，列出復現步驟，然後給出一個建議的解決方案，所有這些都是純文本的。

	披露和限制信息
	---------------

	安全列表不是公開渠道。爲此，請參見下面的協作。

	一旦開發出了健壯的補丁，發布過程就開始了。對公開的缺陷的修復會立即發布。

	儘管我們傾向於在未公開缺陷的修復可用時即發布補丁，但應報告者或受影響方的請求，
	這可能會被推遲到發布過程開始後的7日內，如果根據缺陷的嚴重性需要更多的時間，
	則可額外延長到14天。推遲發布修復的唯一有效原因是爲了適應QA的邏輯和需要發布
	協調的大規模部署。

	雖然可能與受信任的個人共享受限信息以開發修復，但未經報告者許可，此類信息不會
	與修復程序一起發布或發布在任何其他披露渠道上。這包括但不限於原始錯誤報告和
	後續討論（如有）、漏洞、CVE信息或報告者的身份。

	換句話說，我們唯一感興趣的是修復缺陷。提交給安全列表的所有其他資料以及對報告
	的任何後續討論，即使在解除限制之後，也將永久保密。

	協調
	------

	對敏感缺陷（例如那些可能導致權限提升的缺陷）的修復可能需要與私有郵件列表
	<linux-distros@vs.openwall.org>進行協調，以便分發供應商做好準備，在公開披露
	上游補丁時發布一個已修復的內核。發行版將需要一些時間來測試建議的補丁，通常
	會要求至少幾天的限制，而供應商更新發布更傾向於周二至周四。若合適，安全團隊
	可以協助這種協調，或者報告者可以從一開始就包括linux發行版。在這種情況下，請
	記住在電子郵件主題行前面加上「[vs]」，如linux發行版wiki中所述：
	<http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>。

	CVE分配
	--------

	安全團隊通常不分配CVE，我們也不需要它們來進行報告或修復，因爲這會使過程不必
	要的複雜化，並可能耽誤缺陷處理。如果報告者希望在公開披露之前分配一個CVE編號，
	他們需要聯繫上述的私有linux-distros列表。當在提供補丁之前已有這樣的CVE編號時，
	如報告者願意，最好在提交消息中提及它。

	保密協議
	---------

	Linux內核安全團隊不是一個正式的機構實體，因此無法簽訂任何保密協議。