Forging signed commits on GitHub

Root Cause: Regex vs. Proper Parsing

• Many commenters see this as a textbook case of “don’t parse structured formats with ad‑hoc regex,” especially for security‑critical code.
• Others stress the deeper issue is a parser mismatch: GitHub’s custom regex logic and Git’s own parser disagree on what’s valid, enabling desynchronization attacks.
• Several argue the only truly safe option is to reuse Git’s own implementation (or libgit2), not re‑implement parsing at all.
• Some defend regex if used in small, well‑scoped, multi‑step checks (e.g., first locate author lines, then strictly validate format and fail on anything odd).

---

Specification, Validation, and Postel’s Law

• Commenters criticize the fix as “just tweak the regex” instead of properly specifying the commit header format and enforcing it with a strict parser.
• Suggested safer pattern: fail fast on multiple author lines, malformed lines, or anything unexpected.
• Postel’s robustness principle (“be liberal in what you accept”) is heavily criticized as incompatible with modern security; lenient parsing makes other people’s bad inputs your problem.
• Others note Postel’s law historically helped early Internet interoperability, but is now dangerous for security‑sensitive components.

---

Meaning and Value of GitHub-Signed Commits

• Some treat “signed by GitHub’s verified signature” as equivalent to unsigned, since it’s not the author’s own key.
• Others see value: it attests the commit came via GitHub’s web UI or Codespaces under an authenticated account, and gives a trusted timestamp—useful in some supply‑chain and backdating scenarios, assuming GitHub isn’t compromised.
• Confusion and annoyance around GitHub rewriting the committer to itself to attach the verified badge; critics see this as polluting Git metadata, supporters say it fits the author/committer model (tool or maintainer acting on behalf of the author).
• Using one signing key for all users is seen as increasing the blast radius of bugs like this.

---

Signed Commits: Usefulness and Practical Pain

• Some call signed commits largely pointless: if attackers can push code, they often can sign it too.
• Others emphasize their role in mitigating supply‑chain risks, but only if key trust is meaningful (PGP web of trust, domain‑served keys, or platform‑hosted keys).
• Setup and tooling are viewed as cumbersome, though SSH‑based signing and password‑manager integrations are mentioned as easing the process.
• There’s agreement that blind signing endpoints (like Codespaces signing arbitrary commits) sharply increase complexity and attack surface.

---

Security Process and Transparency

• Several comments criticize GitHub’s (and big companies’) vulnerability triage: high noise from low‑quality reports leads to junior staff closing real issues as “not a bug.”
• Anecdotes highlight organizations dismissing serious findings as “intended behavior” until regulators or public exposure get involved.
• Some note GitHub’s pattern of quickly closing security issues and the lack of a detailed public post‑mortem (including whether the bug was ever exploited) as concerning.