perlsecpolicy - Perl 安全性報告處理政策
Perl 專案非常重視安全性問題。
及時有效地處理安全性報告的責任已委派給由 Perl 核心開發人員組成的安全團隊。
本文檔說明 Perl 安全團隊如何運作，以及團隊如何評估新的安全性報告。
如果您認為已在 Perl 解譯器或核心 Perl 程式碼庫中維護的模組中找到安全性漏洞，請將詳細資料寄送電子郵件至 perl-security@perl.org。這個地址是一個封閉的會員寄件名單，由 Perl 安全團隊監控。
您應該在 72 小時內收到對您報告的初步回應。如果您在那段時間內沒有收到回應，請聯絡 Perl Steering Council。
當安全團隊成員回覆您的訊息時，他們通常會在回應的「收件者」或「副本」欄位中包含 perl-security@perl.org 地址。這允許所有安全團隊成員追蹤討論並在需要時加入討論。當您傳送後續回應時，請使用電子郵件客戶端的「全部回覆」功能，以便整個安全團隊都能收到訊息。
安全小組會評估您的報告，並初步判斷它是否符合小組處理問題的範圍。有關如何做出此判斷的一般準則，詳述於 「什麼是安全性問題」 一節中。
如果您的報告符合小組的標準，將會在小組的私人問題追蹤器中開啟一個問題，並會提供問題的 ID 編號。問題識別碼的形式為 perl-security#NNN。請在您發送的任何後續訊息中包含此識別碼。
安全小組將定期發送有關您的問題狀態的更新，並指導您完成漏洞修復程序所需的任何進一步操作。漏洞通常會經歷的階段，說明於 「我們如何處理安全性問題」 一節中。
漏洞是軟體系統的行為，會危害系統預期的機密性、完整性或可用性保護。
安全性問題是軟體系統中一個或多個特定元件的錯誤，會造成漏洞。
使用 Perl 程式語言編寫的軟體通常由許多不同小組編寫的許多軟體層組成。要確定複雜的真實世界應用程式中哪個特定層會導致漏洞行為，可能非常複雜，但這是修復漏洞的必要部分。
Perl 安全小組處理下列安全性問題：
Perl 詮譯器
與詮譯器一起發布的 Perl 模組，在 Perl 核心存放庫中開發
與詮譯器一起發布的命令列工具，在 Perl 核心存放庫中開發
Perl 存放庫和發行 tarball 中 cpan/ 目錄下的檔案，是獨立開發和維護的。Perl 安全小組不會直接處理這些模組的安全性問題，但由於此程式碼與 Perl 捆綁在一起，我們將協助將問題轉發給相關維護人員，而且您仍然可以秘密地向我們報告這些問題。
Perl 被設計為一種快速且靈活的通用程式設計語言。Perl 解譯器和 Perl 模組讓撰寫安全和穩定的應用程式變得容易，但它們確實有其限制。
一般來說，Perl 中的錯誤需要符合以下所有條件，才能被視為安全性問題
Perl 的文件或公開問題追蹤器中未提及此漏洞行為。
此漏洞行為並非預期行為所暗示。
此漏洞行為並非實作中普遍接受的限制。
此漏洞行為很可能會在以 Perl 撰寫的其他安全應用程式中受到攻擊。
此漏洞行為會為觸發該行為的攻擊者提供具體且有形的利益。
有些類別的錯誤經常被回報給安全團隊，但並不符合上述條件。
以下是常見回報但並未視為安全性問題的錯誤清單。
Perl 解析器並非設計用於評估不受信任的程式碼。如果您的應用程式需要評估不受信任的程式碼，則應依賴作業系統層級的沙盒來確保安全性。
過度遞迴通常是由未對輸入強制限制的程式碼所造成。Perl 解譯器假設應用程式會強制執行遞迴限制。
常見的 Perl 建構，例如 pack、x 運算子，以及正規表示式，接受控制多少記憶體會被分配來儲存中間值或結果的數字量詞。如果您允許攻擊者提供這些量詞並消耗所有可用記憶體，Perl 解譯器將不會阻止它。
操作碼 限制和 安全 隔間不受支援作為安全性機制。Perl 解析器並非設計用於評估不受信任的程式碼。
p 和 P 封裝範本的使用這些範本在設計上並不安全。
這些錯誤通常表現為使用後釋放錯誤或對 SV 類型的斷言失敗。堆疊未參考計數的崩潰通常發生在程式碼同時修改參考或 glob，並使用該 glob 或參考引用的值時。
這種類型的錯誤是 Perl 解譯器長久以來的問題，在一般程式碼中很少發生。這種類型的錯誤範例通常假設攻擊者提供的程式碼將由 Perl 解譯器評估。
Storable 被設計為一種非常快速的序列化格式。它並非設計用於對不可信輸入進行反序列化。
SDBM_File 模組不適用於不可信的 SDBM 資料庫。
當 :utf8 PerlIO 層用於讀取編碼錯誤的資料，或使用其他機制直接處理 SV 上的 UTF-8 標記時，就會發生這種類型的錯誤。
編碼錯誤的 UTF-8 標記 SV 不是有效的 SV。以這種方式建立 SV 的程式碼會損壞 Perl 的內部狀態。
blead 分支和 Perl 候選版本不提供安全性支援。僅存在於 Perl 預發行版本中的安全性缺陷會透過正常的錯誤回報和解決流程處理。
Perl 安全團隊專注於 Perl 核心程式碼庫中維護的 Perl 直譯器和模組。團隊無法特別存取 CPAN 模組、以 Perl 編寫的應用程式、Perl 專案網站、Perl 郵件清單或 Perl IRC 伺服器。
Perl 直譯器會嘗試在 Windows 系統上模擬 fork、system、exec 和其他 POSIX 行為。此模擬有許多怪癖，已在 Perl 的公開問題追蹤器中廣泛記錄。變更這些行為會對 Windows 上的現有使用者造成重大中斷。
Perl 直譯器中的一些錯誤發生在程式碼庫中既對安全性敏感又容易在正常使用期間發生故障的區域。
不受信任的正規表示式通常可以安全編譯並與之比對，但有幾個注意事項。Perl 的正規表示式引擎的下列行為由開發人員負責限制。
在 use re 'eval'; 生效時評估不受信任的正規表示式絕不安全。
無法保證正規表示式會在任何特定有限的時間範圍內編譯或評估。
正規表示式在編譯或評估時可能會耗盡所有可用的系統記憶體。
正規表示式可能會導致過度遞迴，導致 perl 直譯器停止。
一般來說，請勿期望 Perl 的正規表示式引擎能抵抗阻斷服務攻擊。
這些模組仰賴外部函式庫與資料庫檔案互動。
讀寫這些檔案格式所造成的錯誤通常是由於底層函式庫實作造成的，並非 Perl 中的安全問題。
Perl 錯誤處理底層函式庫意外的有效回傳值，可能會被視為 Perl 中的安全問題。
Perl 解譯器對演算法複雜度攻擊具有相當的穩健性，但並非免疫。
演算法複雜度錯誤，仰賴解譯器處理攻擊者提供的大量資料，通常不會被視為安全問題。
請參閱 perlsec 中的「演算法複雜度攻擊」 以取得更多資訊。
Perl 安全團隊遵循負責任的揭露實務。安全問題會保密，直到大多數使用者都能輕易取得修正程式。這將使用者的內在風險降至最低，以避免 Perl 中的漏洞。
暫時對使用者隱藏問題是為了保障使用者安全而必須的權衡取捨。永久對使用者隱藏問題並非我們的目標。
當你透過 perl-security@perl.org 聯絡地址私下回報安全問題時，我們通常會期待你遵循負責任的揭露實務處理回報。如果你無法或不願意在使用者取得修正程式前保密問題，你應該在最初的回報中清楚說明。
安全團隊的漏洞修復工作流程旨在盡可能公開且透明地說明你的安全回報狀態。
新的漏洞報告將在安全團隊的郵件清單收到後 72 小時內收到初步回覆。如果您在該時間內未收到任何回覆，請聯絡 Perl 指導委員會。
安全團隊發送的初步回覆將確認您的訊息已收到，並提供安全團隊分類分析的預計時間範圍。
安全團隊將評估報告，並確定是否可能符合作為安全問題處理的標準。
安全團隊的目標是在兩週內完成初步報告分類。需要大量討論或研究的複雜問題可能需要更長的時間。
如果無法重現安全報告或不符合團隊作為安全問題處理的標準，您將收到電子郵件通知，並有機會回應。
通過初步分類分析的安全報告將轉換為安全團隊私人問題追蹤器中的問題。當報告進展到此點時，您將獲得問題 ID 以供未來參考。這些識別碼的格式為 perl-security#NNN 或 Perl/perl-security#NNN。
分配問題 ID 並不表示安全報告代表 Perl 中的漏洞。許多報告需要進一步分析才能得出該結論。
安全團隊私人追蹤器中的問題用於收集有關問題的詳細資訊，並追蹤解決進度。在問題解決後，這些筆記和其他詳細資訊不會公開。保持問題筆記私密，讓安全團隊可以自由討論攻擊方法、攻擊工具和其他相關的私人問題。
安全團隊成員將詳細檢查報告和相關程式碼，以產生受支援 Perl 版本的修正程式。
如果團隊發現報告的問題不符合團隊在此階段的標準，您將收到電子郵件通知，並在問題關閉之前獲得回應機會。
在此時間範圍內，團隊可能會與您討論潛在的修正程式，或為您提供測試目的的修補程式。在此階段不應公開分享任何資訊。
一旦問題完全確認並找到潛在的修正程式，安全團隊將為問題請求一個 CVE 識別碼，以用於公開公告。
需要收集有關受影響 Perl 版本範圍和發現漏洞的人員身分的詳細資訊，才能提交 CVE ID 請求。
安全團隊可能會要求您澄清我們在表彰發現問題時應使用的確切名稱。"漏洞表彰和獎金"文件的部分說明了我們對此表彰的偏好格式。
一旦分配了 CVE ID，您將收到電子郵件通知。在此階段不應公開討論漏洞。
當安全團隊確信安全問題的修正程式已準備好公開發布時，將向 Perl 的主要再發行商發送預發布通知公告。
此預發布公告包含受此漏洞影響的 Perl 版本清單、對使用者風險的分析、安全團隊已製作的修補程式，以及安全團隊可取得的關於減輕或回溯修正至舊版 Perl 版本的任何資訊。
預發布公告將包含特定目標日期，屆時問題將公開宣布。預發布公告與發布日期之間的時間範圍允許再發行者準備和測試自己的更新和公告。在此期間，漏洞詳細資訊和修正程式將受到禁運，不應公開分享。如果在測試期間發現問題，此禁運期可能會進一步延長。
您將收到與您報告的特定問題相關的預發布公告部分。此電子郵件將包含目標發布日期。如果目標發布日期變更，將會傳送其他更新。
Perl 安全團隊不直接製作官方 Perl 發行版。該團隊透過在 Perl 的公開 git 儲存庫中放置提交並發送公告來發布安全修正程式。
許多使用者和再發行者偏好使用官方 Perl 發行版，而不是將修補程式套用至舊版發行版。安全團隊與 Perl 的發行版管理員合作，讓這成為可能。
Perl 的新官方發行版通常在預發布禁運期間於私人系統上製作和測試。
在禁運期結束時，安全性修正程式將提交至 Perl 的公開 git 儲存庫，並將公告傳送至 perl5-porters 和 oss-security 郵件清單。
如果 Perl 官方版本已準備就緒，將在此刻發布，並在 perl5-porters 郵件清單中公告。
在發布程序完成後，安全團隊將向參與禁運期前發布的所有人員傳送後續通知。在 Perl 安全團隊的發布程序完成之前，漏洞報告者和 Perl 再發行者不應發布自己的公告或修正程式。
安全團隊的漏洞修復工作流程假設問題會以私人方式報告，並在問題解決之前保密。這並非總是如此，而且在修正程式準備就緒之前，資訊偶爾會外洩。
在這些情況下，團隊必須決定秘密運作是會增加還是減少 Perl 使用者的風險。在某些情況下，公開安全問題所造成的風險，將允許使用者防禦風險；在其他情況下，引起注意未解決的安全問題將使其更有可能遭濫用。
如果 Perl 中未解決的重大安全問題正被積極濫用來攻擊系統，安全團隊將盡可能迅速發布公告，並提供團隊可用的任何緩解措施。
Perl 的公開缺陷追蹤器將用於處理問題，以便受影響的使用者能盡快看到額外的資訊、修正和 CVE ID。
根據揭露的安全問題資訊的顯著程度和問題成為零時差攻擊的風險，安全團隊可能會略過部分或全部正常的補救工作流程。
如果安全團隊在 Perl 的公開問題追蹤器中識別並解決重大安全問題後得知該問題，團隊將要求 CVE ID 並發送公告通知使用者。
Perl 專案感謝安全研究人員在確保 Perl 安全方面投入的努力。
由於這項工作的很大一部分對公眾隱藏，因此公開感謝研究人員是漏洞補救程序的重要部分。
當安全問題得到解決時，我們將嘗試在我們的公告中感謝發現漏洞的特定研究人員。
信用使用研究人員偏好的全名進行公告。
如果研究人員的貢獻是由特定公司資助或作為有組織的漏洞研究專案的一部分，我們將在研究人員的要求下為此小組包含一個簡短的名稱。
Perl 的公告使用 7 位元 ASCII 字元集以英文撰寫，以便在各種格式中重現。我們不會在這些感謝中包含超連結、網域名稱或行銷資料。
如果無法建立漏洞發現的適當信用，或者 Perl 安全團隊與研究人員之間對於如何給予信用存在分歧，則會從公告中省略信用。
Perl 專案是一個非營利志工組織。我們不提供任何金錢獎勵來回報 Perl 中的安全問題。