胡蘿蔔披露:Forgejo
自從 Fedora 從 Pagure 遷移到 Forgejo 後,我終於有動力好好審視 Forgejo 的安全狀況,結果發現其程式碼庫存在大量漏洞,我決定採用胡蘿蔔披露模式,僅發布經遮蔽的漏洞利用輸出,以激勵開發者進行全面的安全審計。
背景
隨著 Fedora 專案從 Pagure 遷移至 Forgejo,安全研究員 Carrot 開始對這款開源 Git 託管平台的安全性進行審查。作者聲稱在極短的時間內便發現了包括 SSRF、加密實踐錯誤、身分驗證漏洞及遠端程式碼執行(RCE)在內的多項嚴重缺陷。然而,作者並未選擇傳統的漏洞披露流程,而是採取了一種被稱為「胡蘿蔔披露」(Carrot Disclosure)的激進手段:僅展示漏洞利用結果的截圖或輸出,要求開發者必須自行進行全面審計以修復潛在問題,否則將面臨用戶流失的風險。
社群觀點
Hacker News 社群對此篇文章的反應相當兩極,且多數留言對作者的態度與動機表示強烈質疑。許多評論者認為作者表現出的傲慢態度令人反感,特別是針對其拒絕遵循 Forgejo 既有的安全政策一事。有網友指出,Forgejo 的披露流程其實相當標準且透明,作者對政策中強調安全性與隱私的規範感到不滿,顯得有些無理取鬧。更有留言者翻出疑似作者先前提交的拉取請求(PR),指出作者在貢獻程式碼時多次無視維護者要求提供測試案例的建議,僅以「已在本地測試過」帶過,這種不願配合社群開發規範的行為,讓其後續發布的漏洞指控顯得更像是因為提案被拒而產生的報復性行為。
關於「胡蘿蔔披露」模式的有效性與真實性,社群內也展開了激烈的辯論。部分網友對作者展示的 RCE 證據感到不以為然,認為在本地環境運行 Python 腳本並取得權限並不能充分證明其遠端攻擊的威力,甚至有人懷疑這可能只是一場精心設計的表演。這種缺乏透明度的披露方式被批評為缺乏建設性,對開源生態系的健康發展並無助益。然而,也有少數觀點對此持開放態度,認為這種模式比傳統的「協調披露」更自然,且能避免潛在的勒索嫌疑。支持者認為,安全研究員的天職是保護用戶安全而非修補特定工具,如果軟體架構本身已腐爛不堪,研究員確實沒有義務投入大量精力協助修復。
此外,討論中也觸及了開源維護者與貢獻者之間的權力動態。有留言分析,作者作為一名新加入的貢獻者,一進場就要求刪除大量舊有支援卻未提供充分的安全理由,自然難以獲得維護者的信任。這種溝通上的挫敗反映了軟實力在技術協作中的重要性。社群中亦有人引用密碼學史上的經典軼事來對比此情境:當一名業餘愛好者不斷拿漏洞百出的加密演算法煩擾專家時,專家最終選擇給出三個信封並要求對方自行找出答案。這則故事在討論中引發了反思,即當軟體品質低落到一定程度時,專家是否還有義務繼續參與這種「打地鼠式」的修補遊戲。
延伸閱讀
在討論過程中,網友引用了 Bruce Schneier 於 1998 年發布的 Crypto-Gram 存檔,其中記載了一則關於密碼學家如何應對業餘愛好者挑戰的經典故事,用以對比當前安全研究員與開發者之間的互動僵局。此外,留言中也附上了相關的 Forgejo 拉取請求連結,讓讀者能進一步了解雙方在技術實作與測試規範上的爭議細節。
相關文章
其他收藏 · 0