Provenance without a permanent identity graph

As a security-minded maintainer, I want contributors to prove continuity without making every commit a permanent public identity graph. A Git commit already carries author and committer names, emails, timestamps, and a UTC offset; signatures mainly show that the committer controlled a key, not that they personally authored every line. That is useful evidence, but it is not a license to expose someone’s employer history, timezone, or activity across unrelated projects.

I’d support project-scoped aliases backed by platform-held identity escrow: public continuity inside a repository, with account linkage disclosed only under narrowly governed abuse or legal processes. Signing identities could rotate while the project records the continuity relationship. This would not stop investigations, but it would raise the cost of casual correlation and harassment.

Would that improve contributor privacy, or merely make code provenance harder to audit? Maintainers and contributors: what counterexample am I missing?

I like the distinction between public continuity and platform-held linkage, but “narrowly governed” is doing a lot of work. The proposal needs an auditable access policy, retention limits, and some way to challenge abusive disclosure. Otherwise escrow just moves the identity graph from the public to an institution we are asked to trust.

Project scope is the right boundary, but rotating signing keys are operationally expensive. Every rotation creates another continuity edge to maintain, and recovery from a lost key becomes part of the trust model. I’d prefer a stable project alias with short-lived signing keys underneath it.

The privacy gain is real even if it is imperfect. A public noreply address already hides a personal mailbox, but it does not erase timestamps, authorship fields, signatures, or activity patterns. Reducing automatic cross-project correlation is worthwhile; privacy does not require pretending provenance is binary.

A maintainer mostly needs to know “is this the same contributor I reviewed last month?” They rarely need a searchable employment history. Keep the useful continuity local and stop treating a public email address as an identity primitive.

Counterexample: coordinated vulnerability submissions across several projects. Cross-project identity can help maintainers recognize a campaign and compare claims. Making every project an island may protect a lone contributor while weakening collective defense.

The ugly implementation question is authorship. A signed commit can establish committer key possession, but patches get rebased, cherry-picked, and submitted by someone else. An alias scheme should expose author/committer separation clearly rather than putting a green checkmark over the ambiguity.

There is also a social default problem. If the private option is buried, people will use the most convenient identity and discover the consequences later. Make project-scoped identity the normal setting, then offer deliberate disclosure for contributors who actually want a portable public reputation.

From an organizational risk perspective, escrow without independent controls will not pass review. Enterprises will ask who can unlock it, what counts as abuse, and whether the provider can produce a complete history. The answer cannot just be “trust the platform.”

I’d use this tomorrow for small projects. Requiring a public work email or a forever-linked account is a bad tax on contributors who are donating nights and weekends. If a serious incident happens, platform records and signed commits still give investigators something to work with.

I’m wary of making the host essential to provenance. If the platform disappears, a project-scoped alias backed only by escrow may become an orphaned label. The continuity proof should be exportable: signed project membership and revocation records, without exporting the person’s wider identity.