DEV Community: Vesmot

The Bug That Proved My Own Point: A Post-Mortem on TSA Verification

Vesmot — Tue, 04 Aug 2026 08:22:14 +0000

In my previous post, I argued that Git history is not enough as proof because timestamps and commit data can easily be rewritten. The core thesis was simple: you cannot rely on a verification model controlled by a single interested party; you need an independent, external source of truth, such as an RFC 3161 Time Stamping Authority (TSA).

Then, I broke our own verification pipeline.

This is a technical post-mortem on how a subtle bug in our verification path nearly turned a valid cryptographic proof into a false positive "tampering" alert — and why it forced us to rethink what a trusted verification system actually means.

1. What Broke: The OpenSSL Digest Trap

During the stabilization phase of Evident Ledger v1.2.0-rc1, we audited our end-to-end evidence workflow. The write path worked flawlessly:

Compute the Merkle root digest.
Send the digest to an external TSA provider (freetsa.org).
Store the resulting cryptographic timestamp token.

The trouble started on the read path during independent verification.

Our ledger architecture is content-free: we never store or pass raw file contents during verification, only the pre-calculated 32-byte binary digest (the Merkle root). That digest was being passed to OpenSSL like this:

openssl ts -verify -data merkle_root_digest -tsd token.tsr

The problem: OpenSSL's -data flag expects the original raw file content, and it automatically hashes that content internally before comparing it to the timestamp token's message imprint. We were feeding it an already-hashed 32-byte digest — so OpenSSL hashed it a second time.

expected_imprint = digest
actual_imprint   = hash(digest)

The result was a predictable, and misleading, mismatch:

Verification failed: message imprint mismatch
Expected: <digest>
Actual:   <hash of digest>

To an automated verifier or an auditor, this technical mismatch looked identical to a severe security violation: evidence tampering. The system was flagging completely valid, unmanipulated historical records as broken — simply because the verification tool was wrapping the digest a second time.

The Fix

The correction required switching OpenSSL from data mode to direct digest mode, using the correct flag:

openssl ts -verify -digest <merkle_root_hex> -tsd token.tsr

2. Why This Is Not Just a "Minor Bug"

In most software, a bug is an annoyance. In a cryptographic evidence system, a bug in the verification path is a different category of problem entirely.

There is a profound difference between not having a proof and producing a false tampering alert:

No proof means you cannot substantiate a claim.
A false tampering alert means a mathematically sound, honest record is falsely accused of being altered.

If an independent expert or technical consultant runs a verification command during a dispute and sees message imprint mismatch, the reputational and legal damage happens instantly — before anyone has time to check whether the tool, not the evidence, was at fault. A verification tool's failure mode must never mimic the failure mode of the data itself.

3. What Changed in the Release Process

Finding this issue right before tagging v1.2.0-rc1 prompted a deeper shift in how we handle releases. A "provable ledger" needs more than correct math and clean Rust code — it needs a strict operational boundary around that math.

Fail-closed startup security. In production (APP_ENV=production), the application now enforces strict startup guards. If signing keys or TSA CA trust paths are missing, it refuses to boot (exit code != 0) instead of degrading silently.
Warning classification. We audited 201 unique compiler and runtime warnings and classified every one of them, with zero hard blockers left ambiguous in the release binaries.
Evidence-driven documentation. Every security guard and fix is now tracked alongside the codebase in structured audit logs (docs/audits/), instead of living as undocumented tribal knowledge.

4. Conclusion: The Chain of Trust Is Only as Strong as Its Verification

My first article argued that you cannot trust Git history, because the tools that produce it can be manipulated. This bug taught me the corollary: you cannot trust an independent timestamp if your own verification tool interprets it incorrectly.

A trust infrastructure is not a collection of isolated guarantees — Git, GPG, TSA. It is an unbroken chain where every link, from Merkle root generation down to the exact CLI verification flag, has to be deterministic and transparent.

v1.2.0-rc1 is our first release where the code, the operational guardrails, and the audit trail are locked together as a single verifiable system.

If you're interested in the architecture or the audit documentation, the Evident Ledger repository is open.

Why Your Git History Isn't Enough as Proof

Vesmot — Sun, 19 Jul 2026 16:40:19 +0000

Every developer has said it at least once: "check the git log — it's all there." Commit date, author, diff — it looks like an irrefutable timeline of who wrote what and when.

It isn't. And if you ever need to prove authorship or priority of code — in a dispute with a former co-founder, a contested termination involving IP, a licensing or patent dispute — you'll find that git log means far less than it appears to.

Commit dates are just a field you can rewrite

git commit --date lets you set any date when creating a commit. git rebase -i, combined with manual editing or --committer-date-is-author-date, rewrites history entirely. git filter-branch and its modern replacement git filter-repo change dates and authorship across batches of commits in seconds.

Nothing in git itself prevents you from creating a commit today with a date stamped "three months ago." Git is a version control system, not a proof-of-time system. It was never designed for this — and that's fine, as long as you understand what it actually guarantees.

Force-push erases history without a trace

If a repository isn't protected by explicit branch protection rules, git push --force overwrites the remote history completely. What was in main yesterday may simply not exist today — no warning, no record of the fact anywhere else.

GitHub keeps a reflog for a while, but that's not a guarantee — reflogs get cleaned up, forks may be out of sync, and if a dispute ends up in court, "it might still be somewhere in GitHub's logs" isn't something you want to rely on.

Anyone with write access can rewrite history after the fact

This is the key issue in priority disputes: if two people have access to the same repository — co-founders, a team — both of them physically have the ability to rewrite the shared history. Git doesn't verify "who came up with this first"; it only verifies "what's currently in the database," and that database is mutable by anyone with push access.

When the dispute is real — not hypothetical — the question "whose git log is more trustworthy" becomes part of the dispute itself, not a way to resolve it.

GPG-signed commits solve only part of the problem

Signed commits (git commit -S) genuinely prove that a specific person with a specific key confirmed specific content. That's valuable — but it doesn't solve the time question. A signature doesn't carry an independently verified timestamp; it confirms what, not when it was actually created, if the commit date itself — the very field you can rewrite — was set before signing.

What you actually need to prove priority

To make date and content genuinely unfalsifiable, you need a timestamp that neither party to the dispute controls — an independent third party that recorded a hash of the content at a specific moment, before there was any reason to falsify it.

This is exactly what notaries used to do with paper documents, and what an RFC 3161 Time-Stamping Authority (TSA) does for digital data — an independent, cryptographically verified timestamp over a content hash, issued by a party with no stake in the outcome of your dispute.

In practice, this means keeping an independent record — alongside your git repository, not instead of it — of key milestones: releases, critical commits, the state of your codebase on dates that matter, anchored to an external, immutable source of truth.

Not paranoia, just basic hygiene

Most repositories will never need this — if a dispute never arises, git log does its normal job perfectly well. But for developers working in startups with multiple co-founders, freelancers handing off code to clients, teams protecting their own algorithms as trade secrets — the cost of one unresolvable authorship dispute is usually far higher than the few minutes it takes to independently anchor an important commit ahead of time.

It's cheaper to record it once, before you need it, than to try to prove anything after the fact with tools that were never built for that purpose.

Evident Ledger — independent cryptographic file anchoring with an external RFC 3161 timestamp. Local utility, open verification model, free base tier.

Evident: Proving Digital Ownership Without Revealing Your Content

Vesmot — Wed, 08 Jul 2026 20:31:10 +0000

In the era of AI-generated content, copyright disputes, and data leaks, proving that a specific file existed at a specific time is a significant challenge. Traditional methods often require uploading your files to third-party servers, compromising your privacy and security.We are changing that. Introducing Evident, a privacy-first utility designed to provide legally binding proof of existence while keeping your data strictly on your device.The Core Philosophy: "Zero-Knowledge Proof of Existence"At Evident, we believe your files belong to you. Our architecture is built on a simple premise: the server never touches your files.Instead of uploading documents, the Evident utility computes a cryptographic hash locally on your machine. This hash—a unique "digital fingerprint"—is the only thing sent to our infrastructure.How It Works:Local Hash Calculation: You select a file and a project. The utility generates a hash locally.Server Ledger & TSA: We receive only the hash and metadata. We then record the event in a secure ledger, attaching a Time Stamping Authority (TSA) signature.Local Audit Trail: Your device stores the proof package, the ledger link, and the TSA data.Verification: Our local and public verifiers generate professional PDF reports that serve as verifiable evidence of existence at a specific point in time.Scalable Trust: From Base to EnterpriseWe provide a tiered model to match your security and legal requirements:TierFocusBest ForBaseHash + Ledger + Free TSAPersonal projects & basic tracking.LegalJurisdictional-Compliant TSALegal disputes and intellectual property.EnterpriseEncrypted Audit StorageCorporate data compliance.IdentityUser-Owned Keys & Digital SignaturesHigh-security identity verification.(Note: Audit recovery is available as a paid service tier.)Why This Matters for the Global MarketWhether you are a developer protecting your code, an artist securing your digital art, or a lawyer managing client documents, Evident provides a neutral, blockchain-based timestamping layer that is independent and transparent.Our public verifier allows anyone to input a hash and verify the project’s history, providing auditability without ever exposing the underlying file content.Get StartedWe are open-source and committed to transparency. You can find our release, source code, and documentation on GitHub.We invite developers, privacy advocates, and legal-tech enthusiasts to test Evident, contribute to the repo, and help us build a standard for decentralized data integrity.