diff options
Diffstat (limited to 'Documentation/translations/zh_TW/admin-guide/security-bugs.rst')
-rw-r--r-- | Documentation/translations/zh_TW/admin-guide/security-bugs.rst | 26 |
1 files changed, 13 insertions, 13 deletions
diff --git a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst index 65c8dd24c9..c0e9fc2476 100644 --- a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst +++ b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst @@ -19,17 +19,17 @@ Linux內核開發人員非常重視安全性。因此我們想知道何時發現 ----- 可以通過電子郵件<security@kernel.org>聯繫Linux內核安全團隊。這是一個安全人員 -的私有列表,他們將幫助驗證錯誤報告並開發和發布修復程序。如果您已經有了一個 +的私有列表,他們將幫助驗證錯誤報告並開發和發佈修復程序。如果您已經有了一個 修復,請將其包含在您的報告中,這樣可以大大加快進程。安全團隊可能會從區域維護 -人員那裡獲得額外的幫助,以理解和修復安全漏洞。 +人員那裏獲得額外的幫助,以理解和修復安全漏洞。 與任何缺陷一樣,提供的信息越多,診斷和修復就越容易。如果您不清楚哪些信息有用, -請查看「Documentation/translations/zh_TW/admin-guide/reporting-issues.rst」中 +請查看“Documentation/translations/zh_CN/admin-guide/reporting-issues.rst”中 概述的步驟。任何利用漏洞的攻擊代碼都非常有用,未經報告者同意不會對外發布,除 非已經公開。 -請儘可能發送無附件的純文本電子郵件。如果所有的細節都藏在附件里,那麼就很難對 -一個複雜的問題進行上下文引用的討論。把它想像成一個 +請儘可能發送無附件的純文本電子郵件。如果所有的細節都藏在附件裏,那麼就很難對 +一個複雜的問題進行上下文引用的討論。把它想象成一個 :doc:`常規的補丁提交 <../process/submitting-patches>` (即使你還沒有補丁): 描述問題和影響,列出復現步驟,然後給出一個建議的解決方案,所有這些都是純文本的。 @@ -38,15 +38,15 @@ Linux內核開發人員非常重視安全性。因此我們想知道何時發現 安全列表不是公開渠道。爲此,請參見下面的協作。 -一旦開發出了健壯的補丁,發布過程就開始了。對公開的缺陷的修復會立即發布。 +一旦開發出了健壯的補丁,發佈過程就開始了。對公開的缺陷的修復會立即發佈。 -儘管我們傾向於在未公開缺陷的修復可用時即發布補丁,但應報告者或受影響方的請求, -這可能會被推遲到發布過程開始後的7日內,如果根據缺陷的嚴重性需要更多的時間, -則可額外延長到14天。推遲發布修復的唯一有效原因是爲了適應QA的邏輯和需要發布 +儘管我們傾向於在未公開缺陷的修復可用時即發佈補丁,但應報告者或受影響方的請求, +這可能會被推遲到發佈過程開始後的7日內,如果根據缺陷的嚴重性需要更多的時間, +則可額外延長到14天。推遲發佈修復的唯一有效原因是爲了適應QA的邏輯和需要發佈 協調的大規模部署。 雖然可能與受信任的個人共享受限信息以開發修復,但未經報告者許可,此類信息不會 -與修復程序一起發布或發布在任何其他披露渠道上。這包括但不限於原始錯誤報告和 +與修復程序一起發佈或發佈在任何其他披露渠道上。這包括但不限於原始錯誤報告和 後續討論(如有)、漏洞、CVE信息或報告者的身份。 換句話說,我們唯一感興趣的是修復缺陷。提交給安全列表的所有其他資料以及對報告 @@ -57,10 +57,10 @@ Linux內核開發人員非常重視安全性。因此我們想知道何時發現 對敏感缺陷(例如那些可能導致權限提升的缺陷)的修復可能需要與私有郵件列表 <linux-distros@vs.openwall.org>進行協調,以便分發供應商做好準備,在公開披露 -上游補丁時發布一個已修復的內核。發行版將需要一些時間來測試建議的補丁,通常 -會要求至少幾天的限制,而供應商更新發布更傾向於周二至周四。若合適,安全團隊 +上游補丁時發佈一個已修復的內核。發行版將需要一些時間來測試建議的補丁,通常 +會要求至少幾天的限制,而供應商更新發布更傾向於週二至週四。若合適,安全團隊 可以協助這種協調,或者報告者可以從一開始就包括linux發行版。在這種情況下,請 -記住在電子郵件主題行前面加上「[vs]」,如linux發行版wiki中所述: +記住在電子郵件主題行前面加上“[vs]”,如linux發行版wiki中所述: <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>。 CVE分配 |