Document commit signing: rationale, setup, and org-wide enforcement
@Ethan-Arrowood 已經在處理了。
開始於 2026年7月10日。
評估
這個 Issue 還沒有評估資料。
描述
Summary
Write a commit signing guideline doc. We want to enforce commit signing across the org — all commits to all HarperFast repos, with public-facing OSS repos as the highest priority, should be signed.
Doc outline
The doc should be structured in this order:
1. Why commit signing matters
Open with the rationale: signed commits cryptographically verify that a commit actually came from the person it claims to be from. Cover the threat model briefly — author spoofing (anyone can set user.name/user.email to anything), supply chain integrity for our OSS consumers, and the "Verified" badge as a trust signal on public repos.
2. How to set it up
Link out to setup resources rather than duplicating them:
- GitHub: About commit signature verification
- GitHub: Signing commits
- SSH key signing (the lowest-friction option for most people): Telling Git about your SSH key
- GPG setup for those who prefer it
- Note on signing via the GitHub web UI (web-created commits are automatically signed by GitHub)
3. How we enforce it
Link to the enforcement mechanisms and document which ones we use:
- Org-level: rulesets at the organization level with the "Require signed commits" rule
- Repo-level: branch protection / repo rulesets requiring signed commits on default branches
- Document the actual settings we apply so repo admins can verify their repo is compliant
4. AI agent workflows
Platform enforcement (rulesets, CI, hooks) is the backstop, but AI agents are a major producer of commits and a major reviewer of PRs — the guideline should be embedded in agent workflows too, especially in the window before hard enforcement is rolled out:
- Producing commits: skills / agent instructions (e.g. in the
skillsrepo,CLAUDE.md/AGENTS.mdconventions) should instruct agents that commits they author must be signed — verify the environment's signing config (git config commit.gpgsign, signing key present) before committing, and surface a warning rather than silently producing unsigned commits. - Reviewing PRs: PR-review skills should include a commit check step — flag unsigned/unverified commits in review output. This gives us soft enforcement via agent review before org rulesets are turned on.
The doc should note this pattern; actually updating the individual skills can be follow-up work.
5. Effective date
Short closing section: this policy was adopted in July 2026. Enforcement applies to commits from this point onward — historical unsigned commits are grandfathered in and do not need to be rewritten. Only new commits are required to pass signature verification.
Acceptance criteria
- Doc added to this repo following the sections above
- Enforcement settings (org ruleset and/or repo-level guidance) documented
- AI agent workflow guidance included (agents sign their commits; review skills check for signatures)
- Effective date (July 2026, forward-looking only) stated
- 主要語言
- JavaScript
- 星號
- 3
- 分支
- 0
- PR 合併指標
- 30 天內沒有已合併 PR
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
HarperFast/code-guidelines 的其他 Issue
-
Define commit standards: authorship, AI attribution, and trailers可能重新可做 @Ethan-Arrowood 於 101 天前認領,目前沒有進行中的 PR。 未關閉
HarperFast/code-guidelines#13 · 已指派 1 人 ·
查看 HarperFast/code-guidelines 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 77/100
mihai-vlc/sublime-jsfmt#56 ·
-
Bug v3
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 77/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 76/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 84/100
維護者通常 1 天內回覆