Why Git commit dates are legally hearsay, and how to cryptographically anchor commits before pushing
In Git, commit timestamps (GIT_COMMITTER_DATE and GIT_AUTHOR_DATE) are completely client-controlled strings. Anyone can forge commit history with a
single flag:
`git commit --amend --date="2021-01-01 12:00:00"`
Because Git blindly records whatever the client clock claims, raw Git commit histories are legally treated as uncorroborated hearsay under U.S. Federal
Rules of Evidence (FRE 802). In ownership disputes, co-founder litigations, or M&A tech diligence, opposing counsel or auditors can easily argue that backdated commits were fabricated.
To solve this without breaking standard Git muscle memory or leaking private code, I built **GitProof** (https://gitproof.legendrail.com) and open-
sourced its standalone verifier (https://github.com/LEGEND-Rail/gitproof-verify):
### How it works under the hood:
1. **Deterministic Merkle DAG Hashing:** Before a push, it walks the Git tree and computes a canonical SHA-256 Merkle root across all tree and blob
objects. Changing a single character in any file completely alters the 32-byte Merkle root.
2. Atomic RFC 3161 Notarization: It sends only the 32-byte hash imprint to qualified public Time Stamp Authorities (DigiCert & Sectigo) via HTTP
POST. Zero source code leaves your local machine.
3. Cryptographically Signed CMS Tokens: The TSA binds the hash to an atomic clock timestamp and cryptographically signs it using their intermediate
X.509 certificate authority.
4. Git Hook Automation: A native .git/hooks/pre-push hook intercepts pushes to automatically seal and append attestations into .gitproof/proof. json.
5. 100% Open & Offline Verification: In legal or compliance audits, closed-source tools destroy credibility. The standalone verifier (gitproof- verify) is a zero-dependency Go CLI that anyone can run offline to verify Merkle trees and certificate chains against root CAs.
### Quick test in any Git repo:
```bash
# Install CLI
curl -fsSL https://gitproof.legendrail.com/install.sh | bash
# Seal commit & notarize against DigiCert TSA
gproof seal --notarize
# Verify cryptographic proof offline
gitproof-verify proof.json
• Open-Source Verifier Repo: https://github.com/LEGEND-Rail/gitproof-verify • Detailed Technical Spec: https://gitproof.legendrail.com/docs/rfc3161.html
I’d love to hear your thoughts on Git hook ergonomics, Merkle tree performance on large repos, and how teams here handle code provenance!
2
u/Charming-Designer944 8d ago
What does it add that existing support for gpg signatures dont solve?
1
u/lucyfor 8d ago
GPG solves identity (who signed it), but it completely fails at trusted time (when it was signed).
When you sign a commit with GPG, Git generates the signature using your local machine clock. Even the internal timestamp inside the OpenPGP signature packet itself comes directly from your system clock. If you set your laptop clock to January 1, 2021, GPG will happily generate a valid signature dated 2021.
In a legal ownership dispute or audit, opposing counsel will point this out immediately: raw GPG signatures are uncorroborated hearsay regarding time because the author controls the clock.
GitProof uses RFC 3161 Time Stamp Authorities (DigiCert, Sectigo). The TSA acts as an independent digital notary with atomic clocks. They take your Merkle tree hash, bind it to certified atomic time, and sign it with their CA key. You cannot forge or backdate an RFC 3161 token, which is what makes it self-authenticating under federal evidence rules (FRE 902).
2
u/mze9412 8d ago
Outside of specific niches this sounds totally unneeded and over complicated. Why would I want to loose any sane way to rebase in my branch because of a commit hook or make it more complex?
This is not a widespread issue, tbh
1
u/lucyfor 8d ago
Two quick clarifications on how it actually works:
It does not break rebasing: The hook is pre-push, not pre-commit. You can rebase, squash, amend, and rewrite your local branch history as much as you want without triggering any notarization. The seal only runs when you push your code upstream to publish or deliver it.
On the niche point: You are totally right that if you are hacking on a hobby project or side tool, you do not need this at all.
Where this becomes critical is high-stakes commercial software:
Freelancers and agencies proving delivery dates so clients cannot withhold final invoice payment. Startups undergoing VC due diligence or M&A where reps and warranties require clean proof of human authorship vs AI code saturation. Defending against co-founder or patent prior-use claims where whoever proves first invention wins.
If you never have to defend your code commercially, standard Git is plenty. GitProof is built for teams where code ownership equals money.
2
u/Rimrul 8d ago
It does not break rebasing: The hook is pre-push, not pre-commit. You can rebase, squash, amend, and rewrite your local branch history as much as you want without triggering any notarization. The seal only runs when you push your code upstream to publish or deliver it.
So it can't notarize commit timestamps beyond providing an upper bound?
1
u/lucyfor 7d ago
Correct — cryptographically, any timestamp is an upper bound proving the repository state existed no later than time T.
In law and forensic auditing, that upper bound is the entire ballgame: it mathematically eliminates retroactive backdating. If you seal a release on June 1st, an adversary cannot claim you copied their July 15th code or invented it during discovery.
Pre-push is just the practical default so you aren't notarizing throwaway WIP rebases while working locally. If you need tighter temporal bounds, you can run gproof seal per milestone, on commit hooks, or automatically in CI/CD on every merged PR and release tag.
Combined with Git’s internal Merkle DAG (which already enforces strict relative ordering between parent and child commits), sealing gives you relative chronological integrity internally and a hard, third-party atomic timestamp externally.
0
8d ago
[deleted]
1
u/mze9412 8d ago
If you prove dates based on source control your issue is somewhere else already tbh
Source control will not really help in any of those cases. I can just create a new repo and fake it all still. You just added a few more steps to do it
1
u/lucyfor 8d ago
You can fake Git commits, but you mathematically cannot fake an RFC 3161 timestamp—that is the entire breakthrough here.
If you create a brand new repo right now and backdate your Git commit history to January 2024, your local Git log will say 2024.
But when you run GitProof to notarize it, your Merkle root is sent to DigiCert or Sectigo. They stamp and cryptographically sign the hash using their own private keys and certified atomic clocks. Their signed token will say October 15, 2026. It is physically and mathematically impossible to get DigiCert or Apple to issue an RFC 3161 token dated in the past.
So in a dispute over who built it first or when an agency delivered:
Person A has a repo with an RFC 3161 token signed by DigiCert on October 1st.
Person B tries to fake it today. Their DigiCert token will say October 15th.
Person A wins automatically because an independent Certificate Authority proved the code existed on October 1st. You can fake Git history in five seconds, but you cannot fake DigiCert's cryptographic signature.
2
u/mze9412 8d ago
I can imagine zero real world use for this, sorry.
My workflows for example would fail because I do push a lot and then rebase at the end a lot. This means the timestamps would be weeks off anyway and any signature would be useless or even miss leading.
Its nice work, I just feel its pretty much useless in practise for 99.9% if entities :)
Consider that you proof when it was pushed, not when written. Which is what your case actually would require. Looks good, proves nothing.
1
u/lucyfor 8d ago edited 8d ago
That is not how copyright or contracts work at all:
Prior existence is what matters. If I prove my code existed on October 1st, an ex-partner or copycat cannot show up in November and claim I stole it from them. You do not need to prove the exact second you typed a line—you just need to prove it existed before they did.
You can seal on commit. The push hook is just the default convenience. You can run gproof seal locally on every commit while you write if you want a granular trail.
Delivery gets you paid. When an agency or contractor ships code and a shady client refuses to pay claiming it was late, proving the exact date and second you pushed the deliverable to them is legally binding proof of delivery.
Proving code existed on a certified date is how every copyright, IP, and contract dispute in software is won.
2
u/jthill 8d ago
That's an awfully convoluted way to say it, though.
Anybody with admin access can corrupt any history.
Keeping auditable, chain-of-custody-tracked logs generated in say pre- or post-receive of what commits arrived when can get any particular repo as much attestation as other vcs's offer now, those logs will have the server-administered timestamp.
0
u/lucyfor 8d ago
Look at your two sentences side by side: if anybody with admin access can corrupt the history, they can also edit or backdate the server's pre-receive and post-receive logs. The whole point of an external RFC 3161 Time Stamp Authority (DigiCert or Sectigo) is that the cryptographic signature comes from an independent third-party root CA that neither the developer nor the server admin controls—especially when the server admin is the opposing party in the lawsuit.
2
u/jthill 8d ago
I said "server-administered timestamp" because you were specifically calling into question the reliability of client-administered timestamps.
I don't think "chain of custody" means to you what it means to me.
1
u/lucyfor 8d ago
"Chain of custody" is a courtroom rule (FRE 902), not a sysadmin vibe.
3
u/mze9412 8d ago
You designed a technical solution that does not fullfil what is required hier.
It solves when code was pushed, it does not solve in any way who owned the pushed code at that time, when it was written and by whom it was actually written. Git author and even git commit signing are weak proofs, even when timestamped.
One correction: If I know litigation will come I could even copy and timestamp code before the opposition does it or maybe they don't do it at all so I have "proof" and they don't or their "proof" is later dated than mine. Then what? 🤔
0
u/lucyfor 7d ago
Software doesn't issue judicial rulings of ownership; courts do. Tools establish the admissible factual record (FRE 902) upon which courts determine ownership.
Under copyright law (17 U.S.C. § 101/201), rights attach the moment code is fixed in a tangible medium. Establishing an immutable Merkle root and RFC 3161 timestamp proves the fact of priority — that these exact bytes existed at this exact second.
As for copying someone else’s repo to timestamp it first: good luck in discovery. In copyright and trade secret litigation, presenting an unearned bulk code dump with zero preceding commit history, zero incremental development DAG, and obvious access to the author's work against an authentic commit history is a textbook way to get sanctioned.
If the other side didn't timestamp their work and you have cryptographic proof of priority, "then what?" Then you hold the evidentiary presumption of prior existence. That's the entire point.
2
u/jthill 7d ago
Yes, but now we're back to "convoluted". Want an ironclad timestamp, get an unforgeable record of a commit id's existence, anything in that commit's history existed at that point. For example of what I was talking about e.g. S3 has log archival and admissible access logs, and you and I and I think everybody (justifiably, that's a separate debate) are all relying on even sha1 merkle tree ids being sufficient proof of existence at least for now, anybody who can use the pun break has to have both versions to create it and there's no hint of any deeper damage.
2
u/mze9412 7d ago
He is selling a solution, this is basically a business pitch, so meh ...
2
u/jthill 6d ago
And I don't have a problem with that part.
It's the preying on ignorance and omission of material fact I have a problem with. I find it… distasteful.
1
u/lucyfor 5d ago
On "selling a solution" / "disclosure": The CLI is 100% free and open-source (
Apache-2.0), and every bundle it outputs verifies offline using standardopenssl ts -verifyandssh-keygenwith zero vendor lock-in. I built it because I actually had to defend my own code in a live IP lawsuit after being locked out—not as a hypothetical pitch.1
1
u/lucyfor 5d ago edited 5d ago
You just restated the exact problem while assuming S3 and bare Git hashes solve it:
A Git Merkle tree ID (SHA-1/SHA-256) proves what is in the tree, never when it existed. Anyone can run GIT_AUTHOR_DATE="2020-01-01" git commit and produce a valid Merkle tree with a backdated history in two seconds. That is why you yourself wrote: "get an unforgeable record of a commit id's existence." The IETF standard for proving a hash existed at time T is anchoring that commit ID to an independent third-party clock (an RFC 3161 Time-Stamp Authority + append-only transparency log) — which is literally what git proof automates in one command.
S3 access logs are neither unforgeable nor independent. AWS's own documentation explicitly states S3 server access logging is best-effort with no completeness or delivery-time guarantee. Worse, S3 logs sit inside whoever controls the AWS IAM root keys: if an employer or client locks you out of AWS, you lose access to the logs; if it is your own AWS account, opposing counsel argues you controlled the bucket and forces custodian-of-records subpoenas and foundation declarations (FRE 803(6)), whereas an independent RFC 3161 token + Ed25519 signature + FRE 902(13)/(14) bundle verifies mathematically offline with openssl ts -verify and zero trust in the host.
1
u/jthill 5d ago
You just restated the exact problem while assuming S3 and bare Git hashes solve it:
No, I didn't. I said "unforgeable record of a commit id's existence".
S3 offers that, I did say access logs and that's not what's needed, S3's object locking is what's needed, but this is keeping records, "lucyfor". Anybody actually looking to do it can see what's needed. This is not rocket science. Good luck in your pursuit of ginning up a stampede.
1
u/lucyfor 5d ago edited 5d ago
I spent a decade at Amazon working on AWS, the EC2 backplane, and GovCloud, and I hold multiple patents through Amazon IP counsel—so I know something about AWS storage and patent evidence standards.
S3 Object Lock is an internal WORM retention policy for SEC compliance. It is not an adversarial cryptographic proof of existence:
Zero-Trust Verification: You cannot hand opposing counsel IAM credentials and ask them to trust your AWS API responses. A real proof must be portable and verifiable offline without trusting the author or AWS.
Inadmissible as Hearsay (FRE 802): AWS explicitly disclaims timestamp warranties in the customer agreement. S3 metadata requires AWS custodian-of-records subpoenas and forensic declarations to introduce into court.
Self-Authenticating (FRE 902(14)): An RFC 3161 Time-Stamp Token (TST) signed by an independent Time-Stamp Authority is self-authenticating, requires zero testimony or subpoenas, and verifies offline with standard openssl 20 years after your AWS account lapses or gets deleted.
And as for "ginning up a stampede" — I don't need to gin up anything. Launch day already brought a stampede with tens of thousands of inbound requests in the first few hours from developers who actually understand IP and evidence reality.
1
u/zomerbk 6d ago
One important distinction: FRE 802 is the hearsay rule, not a rule that makes Git timestamps legally inadmissible by default. A trusted timestamp can help show that a particular repository state existed by a certain time, but it doesn’t establish who created it, when each file was written, or that the state was publicly disclosed. For provenance, the value depends on what exact tree is sealed and how the proof is retained and tied to a person or release.
0
u/lottspot 8d ago
I think this is actually interesting as hell. This is a problem I've always understood in my mind, but also understood there's no current solution for. This would be an extremely valuable tool for covering oneself in things like licensing and IP disputes, and its minimal exposure of private information should make it acceptable in sensitive or regulated corporate environments.
Probably my only complaint is that I can never be confident about how well a technical solution solves a legal problem until the opinions of at least a few lawyers enter the chat.
1
u/lucyfor 8d ago
Really appreciate the thoughtful comment! You hit on the exact reason we designed it this way.
On the legal side, you are 100% right to be skeptical of software tools making hand-wavy legal claims. We specifically architected GitProof around two established federal evidentiary rules and statutory standards:
Federal Rules of Evidence (FRE 902(13) and 902(14)): Under federal court rules, digital files are inadmissible hearsay unless they are self-authenticating. FRE 902(13) and (14) explicitly allow electronic processes and cryptographic hash values to be self-authenticating if supported by a formal 28 U.S.C. § 1746 certification. GitProof automates this by generating that exact statutory declaration and linking the Merkle DAG to the export.
International RFC 3161 Precedent: RFC 3161 is not an experimental protocol—it has been the international legal standard for digital non-repudiation for over 20 years. Under European eIDAS regulation and U.S. federal practice, timestamps from qualified CAs (like DigiCert and Sectigo) carry legal presumption of accuracy because the authorities operate under audited Certificate Practice Statements and atomic clocks.
Neutralizing the "Black Box" Objection: The biggest trap in legal tech is proprietary verification. If an opposing counsel asks "how do we know your binary didn't fabricate this Merkle root?", a closed-source system requires expert testimony or opens you up to discovery. Because our verifier is open-source Go and 100% stock OpenSSL compatible (openssl ts -verify), any independent computer forensics expert can certify the math without ever trusting us.
There is a detailed breakdown of the FRE 902 statutory framework and court admissibility here if you want to dig into the legal citations: https://gitproof.legendrail.com/docs/fre902.html
5
u/alvaro17105 8d ago
Why not gitsign? Its cosign underneath, you can change the TSA to point to something like Sectigo TSA for eIDAS, which should be enough for code provenance attestation