# 公開性 在自由軟件中，在純內部討論和公開聯系聲明之間通常有一個相對平滑的連接。這部分因為目標讀者一直不明：因為大多數文章都是公開可訪問的，項目無法控制整個世界對此的印象。某人—假設是[slashdot.org](http://slashdot.org/)的一個編輯—可能為謀篇文章帶來幾百萬的讀者，而本來沒人認為它會被項目之外的人看到。這就是開源項目生活的世界，但是在實踐中，這種風險通常很小。通常情況下，項目希望公開化的聲明就會得到最大的公開化，只要你能用正確的機制指出其對外部世界的新聞價值。 對于主要的聲明，通常會有4或5個主要分發渠道，所有的聲明最好盡可能同時發出： 1. 你的項目主頁可能是項目中被看得最多的頁面。如果你確實有主聲明，請在此放一個夸張的廣告。這個廣告一定是一個簡短的概要，可以鏈接到有更多信息的新聞稿。 1. 同一時間，你的站點一定也要有一個“新聞”或“新聞發布”區，可以詳細寫明聲明。新聞稿的部分目的是提供一個單獨的權威“聲明對象”，這樣別的站點可以用來鏈接，所以要以此為依據確保其結構：要么每個發布一個網頁，或每個是一個博客條目，要么其他種類可以被鏈接的實體，同時與同一區域的其他新聞稿區分開來。 1. 如果你的項目有RSS供稿（見[the section called “RSS供稿”](# "RSS供稿")），請確保聲明也會出現在這里。這也可能在你創建新聞稿時自動發生，取決于你是如何設置的站點。 1. 如果聲明是軟件的新版本，請更新[http://freshmeat.net/](http://freshmeat.net/)中的項目條目（關于首次創建條目請看[the section called “通告”](# "通告")）。每當你更新Freshmeat條目時，該條目就會出現在Freshmeat當日的變更列表中。這個變更列表不僅僅會在Freshmeat本身更新，也會出現在許多被很多人關注的門戶站點（包括[http://slashdot.org](http://slashdot.org)）上。Freshmeat也會通過供稿提供相同的數據，所以即使那些沒有訂閱你的項目供稿的人，也會通過Freshmeat看到聲明。 1. 向你的項目聲明郵件列表發送一個郵件。這個列表的名稱應當是“announce”，例如`announce@yourprojectdomain.org`，因為現在這已經成為了標準的習慣，而且列表的管理者一定要說明該列表的內容很少，僅用于主要的項目聲明。大多數此類聲明都是關于軟件的新版本，但是偶爾也會其他事件，例如本章后面說的募集資金激勵，發現安全漏洞（見[the section called “聲明安全漏洞”](# "聲明安全漏洞")），或者項目方向的重大轉移，也會發布到這里。因為內容很少，只用于重大事件，所以`announce`列表通常是項目中訂閱最多的列表（當然，這意味著你不要濫用它—發布之前一定要小心）。為了防止其他人，甚至是垃圾郵件發出聲明，`announce`列表應該一直需要審核。 要力爭在所有的三個地方同時作出聲明，越接近越好。人們在郵件列表中看到聲明，而在主頁或新聞發布區上沒有對應的內容時就會感到困惑。如果你能將各方面的（郵件、網頁等等）修改排隊，并依次發出，你可以將這種時間差控制到最小。 對于不太重要的事件，你可以省略上面的某個發布出口。根據事件的重要程度，該事件還是會被外部世界注意到。例如，軟件的一個新版本是主要事件，而設定下一次發布的日期，即使有些新聞價值，也不會比發布本身更重要。設定日期值得我們在日常郵件列表（而不是聲明列表）中發一個郵件，以及更新項目時間線或網頁狀態，但僅此而已。 然而，你還是會在網上的其他地方的討論中看到日期。在你的列表中的潛伏者僅僅會聽，而不會說任何事，并不一定在其他地方也是沉默的。口碑會造成廣泛的傳播；你必須考慮到這一點，使用這種方式構建更小的聲明，鼓勵信息傳遞的精確性。特別的，你期望引用文章一定要在明確的在引用部分出現，就像你在寫正式的新聞稿。例如： > *僅僅是進度更新：我們計劃在2005年8月中旬發布Scanley的2.0版本。你可以檢查http://www.scanley.org/status.html的更新。新特性是正則表達式搜索。* > *其他特性包括：?...也會包含其他bug修正，包括?...* 第一段很簡短，僅提供了最重要的信息（發布日期和主要新特性），以及訪問進一步新聞的URL。如果某人的屏幕僅出現這個段落，也完成的足夠好了。郵件的余下部分可以省略，不會損失內容的要點。當然，有時人們會鏈接整個郵件，但是更常見的，他們只會引用一小部分。假設后一種的可能性，你所做的也讓他們的工作更容易，此外也因為所引用的內容獲得了更多的影響力。 ### 聲明安全漏洞 安全漏洞的處理與其他類型bug報告有所不同。在自由軟件中，公開透明的工作方式通常幾乎是宗教信條。只要你愿意，標準bug處理過程的每個步驟都是可見的：最初到來的報告，實現確認的討論以及最終的修正。 安全bug則有些不同。它們會危及用戶數據，甚至是用戶的整個電腦。如果公開討論這個問題，就是將其公示天下—包括那些會惡意利用這個bug的人。甚至僅僅是有效率的提交一個修正宣布bug的存在（會有潛在的攻擊者看到公開項目的提交日志，有系統的查找變更，以便在以前的代碼中獲取安全問題）。大多數開源項目都為公開性和秘密性的沖突準備了相同的處理步驟，基于如下的基本指導方針： 1. 在發現修正之前，不要公開談論bug；然后在宣布bug的同時立刻提供修正。 1. 盡可能迅速的完成修正—特別是如果項目外的某人報告了這個bug，因此你知道至少有一個項目外的人能夠破解這個漏洞時。 在實踐中，那些原理會導致一系列標準化的步驟，將會在下面的小節描述。 ### 接收報告 很明顯，人們需要從任何人那里接收安全報告的能力。但是不能用常規的bug報告地址，因為那樣所有人都會看到。因此，可以設定一個接收安全bug報告的郵件列表。這個郵件列表一定不要有公共可讀的歸檔，而且必須嚴格控制其訂閱權—只有長期可信的開發者可以在列表上。如果你需要為“可信的”作出正式的定義，可以規定為“所有提交過兩年及以上的人”，或類似的，避免偏袒。這將會是處理安全bug的團隊。 理想狀態下，安全列表不應該是垃圾保護的或需要經過審核的，因為你不會希望僅僅因為在周末沒有審核者而造成重要的報告被過濾掉或者被延遲。如果你使用自動垃圾郵件保護軟件，可以嘗試使用較高的容忍設置；允許部分垃圾郵件通過總比漏掉一個報告要好。當然，為了列表的效率，你應當將列表的地址廣而告之；但是因為它沒有審核，或者只有輕微的防垃圾設置，一定要確保要有郵件地址隱藏的變化，就像[Chapter?3, *技術基礎設施*](# "Chapter?3.?技術基礎設施")中的[the section called “歸檔中的地址隱藏”](# "歸檔中的地址隱藏")所說的。幸運的是，地址隱藏不需要將地址變的難以識別；舉個例子，可以看[http://subversion.tigris.org/security.html](http://subversion.tigris.org/security.html)，以及該網頁的HTML源代碼。 ### 默默的開發修正 當接收到報告時，在安全列表上要怎么做？首要任務是評估問題的嚴重性和緊急性。 1. 漏洞很嚴重嗎？它會造成使用該軟件的計算機被惡意攻擊接管嗎？或者說，是否僅僅會泄漏他們文件大小的信息嗎？ 1. 破解這個漏洞很簡單嗎？攻擊可以腳本化，還是需要環境相關的知識、有意識的猜測甚至運氣？ 1. *誰*向你報告了這個問題？當然，這個問題的答案不會改變漏洞的本性，但你可以以此判斷有多少人了解此事。如果報告來自于項目自己的開發者，你可以松一口氣了（也就一口），因為你可以相信他們不會告訴別人。另一方面，如果是來自類似`anonymous14@globalhackerz.net`的郵件，你最好立即行動。盡管這個好人提醒了你，但你無法知曉她告訴了多少人，或者她還會等多少時間去破解正式安裝系統中的這個漏洞。 請注意，我們這里討論的范圍僅僅是*緊急*和*極端?緊急*之間。即使報告來自于一個已知的、友好的來源，網上的其他人也可能早就發現了這個bug，只是沒有報告。唯一不緊急的情況是，bug在本性上不會嚴重的影響安全。 另外，“`anonymous14@globalhackerz.net`”的例子并不可笑。你可能真的會從隱形身份的人那里得到bug報告，根據他們的詞匯和行為，你無法判斷他們是否站在你一邊。這沒有關系：如果他們向你報告了安全漏洞，他們會覺得理應得到好的回報，你應當友好的回應。感謝他們的報告，給他們一個發布修正的時間或截止時間，并與他們保持聯系。有時，他們會給*你*一個日期—那是將在該日期公布bug的威脅的暗示，無論當時你是否已經準備妥當。這看起來像是一種權利的欺凌游戲，但是更像是一種預先的免疫行動，因為之前有對許多令人失望的遲鈍的軟件制造者，沒有將安全報告認真對待。無論如何，你不能對他視而不見，畢竟，如果bug很嚴重，他擁有的知識會給你帶來很大的麻煩。友好的對待這種報告者，希望他們也能投桃報李。 另一個安全bug的常見報告者是安全專家，一些長期審核代碼并鉆研軟件漏洞的人。這些人通常精通兩個領域—他們不僅會接收，也會發送報告，可能比你項目的大多數開發者都多。他們也通常會為修正某個漏洞設定公布于眾的截止日期。截止日期也許可以討價還價，但是這取決于報告者；截止日期已經成為安全專家唯一認可可靠方法，可以讓組織迅速的定位安全問題。所以，不要認為截止日期很野蠻，這是久經考驗的傳統，這樣做有足夠的理由。 當你知道了嚴重性和緊急性，你就可以開始修正了。有時，需要在優雅和速度之間做出權衡；這也是為什么在開始前要首先確認緊急性。當然，也要保證討論僅限于安全列表用戶，原始的報告者（如果她希望加入），以及所有因技術原因必須參與的人之間。 不要提交修正到版本庫。在公開之前，請一直用補丁的形式。如果你準備提交，即使采用了無辜的日志信息，也會讓某些人注意到并理解此變更。你永遠無法知道誰在關注你的版本庫，以及他們感興趣的原因。關閉提交郵件可能會有些用；但是畢竟提交郵件序列本身會讓人起疑，而且數據已經進入了版本庫。只應該以補丁的形式完成所有的開發，并保持補丁在私密的地方，也可以是一個單獨的獨立版本庫，只有知曉此bug的人能夠知道。 （如果你使用分布式的版本控制系統，例如Arch或SVK，你可以在完全版本控制下完成這個工作，只需要保證外來者無法訪問此版本庫。） ### CAN/CVE號碼 你或許看到過隨安全問題出現的*CAN號碼*或*CVE號碼*。例如看起來類似“CAN-2004-0397”或“CVE-2002-0092”。 兩種號碼都代表了相同類型的實體：在[http://cve.mitre.org/](http://cve.mitre.org/)上維護的“常見漏洞和曝光”列表中的一個條目。這個列表的目的為所有已知的安全問題提供標準化的名稱，這樣每個人都可以在討論時使用唯一的標準化的名稱，并提供一個可以查找更多信息的中心地點。 “CAN”和“CVE”的唯一區別是前者代表了候選條目，還未經CVE編輯委員會認可，而后者則是經過認可的條目。 然后，兩種類型的條目都對公眾可見，條目的編號不會隨著認可而改變—僅僅是“CAN”前綴替換成了“CVE”。 CAN/CVE條目本身并不包含bug的完整描述，以及如何防范的信息。相反，它只會包含一個簡短的摘要，然后是到參考和外部資源的列表（例如郵件列表歸檔），人們可以去查看詳細信息。[http://cve.mitre.org/](http://cve.mitre.org/)的真正目的是提供一個組織良好的空間，每個漏洞都可以有一個名稱以及獲取更多信息的途徑。一個條目的例子可以看[http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092](http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092)。請注意，引用可以非常的簡潔，其中的來源表現為神秘的縮寫。這些縮寫的關鍵點可以看[http://cve.mitre.org/data/refs/refkey.html](http://cve.mitre.org/data/refs/refkey.html)。 如果你的漏洞達到了CVE的標準，你或許會希望得到一個CAN號碼。這個過程是故意封閉的：一般來說，你需要認識某人，或認識某人認識某人。這并不是表面上的那么瘋狂。為了避免被偽造的或編寫糟糕的提交壓垮，CVE編輯委員會只從已知和信任的來源獲取提交。然而，為了獲取你的漏洞列表，你需要從你的項目找一個CVE編輯委員會認識的人。在你的開發者中詢問一下是否認識某人之前曾經完成過CAN過程，或知道某人會認識。這樣做的好處是該鏈路上的某處，某人會知道足夠的信息告訴你 a) 根據MITRE的標準，它不會作為漏洞或曝光，所以沒有提交的意義，或者 b) 這個漏洞已經*有了*CAN或CVE號碼。后者可能是因為該bug已經在另一個安全忠告列表上發布了，例如位于[http://www.cert.org/](http://www.cert.org/)或者位于[http://www.securityfocus.com/](http://www.securityfocus.com/)的BugTraq郵件列表。 （如果是在你的項目對此一無所知的情況下發生了這種情況，你一定會擔心還有什么不知道的。） 如果你已經得到了CAN/CVE號碼，你一定希望盡早將其納入bug研究中來，這樣以后的所有交流都可以引用這個號碼。在公布之前，CAN條目會被禁止訪問；這個條目會作為占位符保持（這樣就不會丟失名稱），但不會揭示任何漏洞信息，直到你宣布此bug并修正了它。 關于CAN/CVE流程的更多信息可以查看[http://cve.mitre.org/about/candidates.html](http://cve.mitre.org/about/candidates.html)，一個開源項目中使用CAN/CVE號碼的例子可以看[http://www.debian.org/security/cve-compatibility](http://www.debian.org/security/cve-compatibility)。 ### 預通知 一旦你的安全響應團隊（那些在安全郵件列表上的開發者，或者那些你認為應該加入到解決特定報告的人）準備好了修正，你就要決定如何描述它。 如果僅僅是提交你們的修正到版本庫，或者是向全世界宣布，所有使用該軟件的人就必須立刻升級，否則就要經受被攻擊的風險。有時，更應該對某些特別重要的用戶進行*預提醒*。對于客戶端/服務器軟件這一點尤其重要，因為也許某些用戶的服務器是攻擊的誘人目標。那些服務器的管理員也許會對提前一兩天進行升級而感到感激，這樣他們就可以在破解出現在公眾之前做好保護。 預提醒的意思是在公布之前向那些管理員發送郵件，告訴他們這些漏洞以及如何修正。一定要確保只向你相信會保守秘密的人發送預提醒。也就是，接收預提醒的資格包括兩重意思：接收者一定是在運營一個大的，重要的服務器，影響重大，*而且*這些接收者也一定不會在公開之前到處亂說這個安全問題。 向每個接收者單獨（每次一個）發送預提醒郵件。*不要*一次向整個列表的接收者發送，因為他們會看到其他人的名字—那樣意味著告訴了每個接收者*他們*的服務器有安全漏洞。完全通過暗送（BCC）也不是好方法，因為某些管理員使用垃圾過濾會屏蔽或減少BCC郵件的等級，因為現在有太多使用BCC發送的垃圾郵件。 以下是一個預提醒郵件： ~~~ From: 你的名字 To: admin@large-famous-server.com Reply-to: 你的名字（不要用安全列表地址） Subject: 重要Scanley漏洞提醒。 這個郵件是Scanley服務器安全警告的重要預提醒。 不要向任何人轉發本郵件。公共聲明將會在3月19日發布，我們很希望在此 之前能夠保密此信息。 您收到此郵件是因為（我們認為）您運行了Scanley服務器，并希望在19號公 布此安全漏洞之前做好補丁。 參考： =========== CAN-2004-1771: Scanley查詢堆棧溢出漏洞： ============== 如果服務器的locale設置配置錯誤，而且客戶端發送了不合法的查詢，會導 致可以運行任何命令。 嚴重程度： ========= 非常嚴重，可以導致服務器上任意代碼的執行。 周邊工作： ============ 在scanley.conf中將'natural-language-processing'選項設置為'off'，可以關閉 這個漏洞。 補丁： ====== 以下補丁適應于Scanley 3.0、3.1和3.2。 一個新的公共版本（Scanley 3.2.1）將會在3月19日發布，同時該漏洞也會 公開。你可以現在打補丁，或者等待公開版本。3.2與3.2.1的唯一區別將是此 補丁。 [...補丁在這里...] ~~~ 如果你有CAN號碼，即使該信息依然是保密的，它的MITRE頁面沒有任何內容，也請在預提醒中提供（上面例子中顯示的）。包含CAN號碼允許接收者可以知曉自己被預提醒的bug正是他們將來可能通過公共渠道獲知的bug，這樣他們就不必為是否要采取進一步的行動而感到擔心，關鍵點就是CAN/CVE號碼。 ### 公開分發修正 處理安全bug的最后一步是公開分發修訂。在一個單獨的完整的聲明中，你需要描述該問題，如果有CAN/CVE號碼，也要提供，描述工作的背景，以及如何永久修正。通常情況下，“修正”意味著將軟件升級到新版本，有時也可能是應用一個補丁，特別是如果你的軟件以源代碼形式運行時。如果你要發布新版本，一定要確保是與現有的某個版本的區別就是安全補丁。使用此方法，保守的管理員就可以作出升級，無需擔心會影響其他的功能；他們也不必擔心將來的升級，因為安全補丁將會理所當然的出現在未來版本中。（關于發布的詳細信息可以看[Chapter?7, *打包、發布和日常開發*](# "Chapter?7.?打包、發布和日常開發")的[the section called “安全發布”](# "安全發布")。） 無論公開修正是否包含了新的版本，不要像發布新版本那樣粗糙：在項目`聲明`列表中發送一封郵件，發布一個新的新聞稿，更新Freshmeat條目等等。你不應該因為項目的名譽，而試圖減弱安全bug的存在性，你應當確立與安全聲明問題的嚴重程度相匹配的基調和突出程度。如果安全漏洞僅僅是輕微的信息暴露，而不會導致用戶攻克整個計算機，無需大驚小怪。你甚至會覺得無需為此分散`聲明`列表的注意力。畢竟，如果項目每次都喊狼來了，用戶會誤以為軟件很不安全，而且會在真的有大問題要宣布時不相信你。關于判斷嚴重性的更好的介紹可以看[http://cve.mitre.org/about/terminology.html](http://cve.mitre.org/about/terminology.html)。 一般情況下，如果你對如何處理安全問題并不確定，可以找某個更有經驗的人討論一下。評估和處理漏洞更像是一種學習得到的技巧，一開始很容易誤入歧途。