徽章實際記錄了甚麼
驗證提交徽章是簽名檢查的結果，並非品格證明。當你在 GitHub 上看到提交旁邊的「Verified」標記，平台只告訴你一件狹窄的事：它檢查了附加於該提交的密碼學簽名，而檢查通過。
GitHub 會在簽名成功驗證時，將已簽署的提交標記為 Verified。來源
徽章附屬於提交，而非附屬於個人。它亦不是你所查看帳戶的即時安全指標。驗證結果是某個時間點所發生檢查的歷史記錄。
驗證一經記錄，即使簽署金鑰已被撤銷或已過期，該記錄仍可保留。來源
這種持續保留對調查人員很重要。即使產生徽章的簽署金鑰已被撤銷或已過期，舊提交上的徽章仍可顯示。撤銷金鑰不會追溯抹除徽章，過期金鑰亦不會令舊提交變成未驗證。因此，徽章只告訴你簽名在記錄時通過了檢查，並不代表金鑰仍受信任、帳戶仍然安全，或現時帳戶持有人就是當初簽署的人。
第一步：分開三個問題
當有人以驗證提交作為開發者身份的證據時，他們通常混淆了三個不同問題。在評估任何事物之前，先將它們分開。
| 問題 | 驗證徽章能顯示甚麼 | 它本身不能顯示甚麼 |
|---|---|---|
| 此提交是否已簽署並驗證？ | GitHub 記錄了該提交的簽名驗證成功。 | 誰撰寫了程式碼，或程式碼質素如何。 |
| 現時由誰控制該帳戶？ | 沒有直接顯示。徽章繫於提交，而非現時登入控制權。 | 是否仍由同一人擁有帳戶，或帳戶是否已易手。 |
| 此人是否就是其自稱的人，或受僱於其自稱的機構？ | 沒有直接顯示。 | 身份、僱傭關係，或代表組織發言的授權。 |
驗證徽章只回答第一行。第二及第三行需要獨立證據。這與我們在公開個人檔案搜尋能與不能揭示一個人的甚麼指南中所述的紀律相同：公開產物是線索，不是結論。
第二步：閱讀提交，而非只看徽章
徽章是捷徑，而捷徑會隱藏背景。打開提交本身，查看驗證結果周圍的內容。
- 提交作者欄位與提交者欄位。 這些是元數據條目，並非誰鍵入程式碼的證明。在許多工作流程中，它們可以設定為任何內容。
- 所顯示的簽署金鑰。 GitHub 會將驗證結果與金鑰關聯。注意該金鑰是呈現為屬於某個帳戶、某個組織，還是某個機械人。
- 儲存庫與分支。 個人分支中的驗證提交，其組織份量低於合併到維護中專案的提交，但兩者均不能證明僱傭關係。
- 日期。 舊的驗證提交是歷史數據點。它對帳戶現時的安全狀況毫無說明。
這些欄位無論單獨或合併，均不能確立帳戶持有人就是個人簡介中所稱的人，或該人任職於個人檔案所稱的機構。
第三步：另行查核現時帳戶控制權
驗證提交是關於某個提交的記錄。帳戶控制權是另一個問題，公開頁面很少直接回答。你可以做的是尋找一致性與連續性。
- 比較帳戶隨時間的公開歷史。長期而連貫的貢獻歷史是線索，不是證明。
- 在其他平台尋找相同的用戶名稱或顯示名稱。名稱吻合是線索，並非證明帳戶屬於同一人，因為用戶名稱在不同平台並不唯一，可被重用或搶註。
- 將個人檔案文字、頭像及簡介視為帳戶持有人所作的聲稱，而非已驗證的事實。
如果有人以驗證徽章作為他們現時控制某帳戶的證明，那是類別錯誤。徽章不衡量現時登入安全，亦不確認與你對話的人就是帳戶持有人。
第四步：尋找獨立證據
獨立證據是指並非源自提出聲稱的同一帳戶的任何事物。例子包括組織自行發布的團隊成員名單、會議網站上的演講名單，或由組織帳戶維護並有其自身公開記錄的儲存庫。即使這些也只是佐證，不是身份證明。你的工作是決定組合起來應給予多少份量，而非宣稱確定。
決策表：應給予驗證徽章多少份量
| 情況 | 合理解讀 | 剩餘不確定性 |
|---|---|---|
| 有徽章，金鑰仍與帳戶關聯，近期提交 | 簽名已驗證，金鑰關聯是現時的。 | 不能證明該人控制帳戶或撰寫了程式碼。 |
| 有徽章，金鑰已撤銷或過期 | 驗證在發生時已被記錄。 | 對現時金鑰信任或帳戶安全毫無說明。 |
| 徽章僅見於舊提交 | 歷史驗證記錄。 | 對現時活動或控制權沒有暗示。 |
| 沒有徽章 | 該提交沒有驗證簽名。 | 沒有徽章並非不當行為的證據；許多正當工作流程不會為每個提交簽署。 |
| 徽章加上其他平台名稱吻合 | 值得跟進的線索。 | 用戶名稱並不唯一；帳戶可能屬於不同的人。 |
| 徽章加上組織檔案提及 | 對可能隸屬關係的佐證。 | 不能證明僱傭關係或代表組織發言的授權。 |
常見錯誤
- 將徽章當作身份檢查。 它是簽名結果，不是背景審查。
- 假設歷史徽章證明現時帳戶安全。 記錄可在金鑰撤銷或過期後保留，因此徽章不是即時狀態燈。
- 混淆作者與提交者元數據與著作權。 這些欄位是提交物件中的聲稱，並非誰撰寫程式碼的已驗證事實。
- 將名稱吻合當作同一人的證明。 同一用戶名稱在兩個平台出現是線索，並非證明帳戶屬於同一人。
- 將分支上的徽章解讀為組織認可。 個人分支中的驗證提交不能確立組織已審查或認可該工作。
- 假設未簽署提交可疑。 許多正當貢獻者及工作流程不會為每個提交簽署。
自我審查清單
在重複一個以驗證徽章為依據的開發者聲稱之前，請執行此清單。
- 我是否有打開提交並記下作者、提交者、金鑰、儲存庫及日期？
- 我是否有將「簽名已驗證」與「帳戶控制權」及「身份或僱傭關係」分開？
- 我是否有查核金鑰是否仍與帳戶關聯，或記錄是否可能在撤銷或過期後保留？
- 我是否有尋找至少一個並非源自同一帳戶的來源？
- 我是否有將名稱吻合描述為線索，而非同一人的證明？
- 我是否有避免聲稱徽章證明現時安全、著作權或僱傭關係？
保護自己的數碼足跡
如果你簽署提交，請記住驗證徽章是你留下的記錄。它可能比產生它的金鑰更長壽。在撤銷或輪換簽署金鑰之前，決定你希望舊提交如何呈現，並保留自己的筆記，記錄何時使用了哪些金鑰。如果你維護公開個人檔案，檢視你歷來使用過的用戶名稱，並查核舊帳戶是否仍指向你。用戶名稱搜尋如 TraceSeek 可協助你檢視自己在 3,000+ 個平台上已知的公開用戶名稱；首次掃描免費，無需註冊或登入，結果通常在 20–30 秒內返回。將輸出視為待審查的線索清單，而非身份驗證。TraceSeek 不會更改平台設定、不保證匹配，亦不驗證任何人的身份。關於我們如何界定證據與限制，請參閱我們的方法論。
關鍵事實
- GitHub 會在簽名成功驗證時，將已簽署的提交標記為 Verified。
- 驗證一經記錄，即使簽署金鑰已被撤銷或已過期，該記錄仍可保留。
- 驗證提交徽章是針對特定提交的簽名結果，並非現時帳戶控制權或身份的證明。
- 跨平台吻合的公開識別碼是線索，並非帳戶屬於同一人的證明。
- TraceSeek 涵蓋 3,000+ 個平台，並提供免費首次掃描，無需註冊或登入。