How to Timestamp a Software Release
By BlockchainSignPublished
Version control gives you an excellent history and a weak date. Anchoring a release fixes the second problem in about a minute per release.
Why git dates are not enough
Commit timestamps are written by the committing machine. An interactive rebase, a clock change, or the ordinary --date flag will produce any history you like, and the result looks completely normal.
That is fine internally. As evidence it is thin, and the weakness runs both ways — it is equally unhelpful when you are defending against a claim rather than making one.
A hosted platform's own timestamps are better, but they belong to the platform, they vanish with the account, and an outsider cannot verify them independently.
What to anchor
Not the working tree. A deterministic artefact whose bytes you can reproduce later:
git archive --format=tar.gz -o release-v1.4.0.tar.gz v1.4.0
or a bundle, which captures history as well as content:
git bundle create release-v1.4.0.bundle v1.4.0
or the build output itself, if your build is reproducible.
Then hash that file and timestamp the hash.
The steps
- Create the artefact from the tag, not from your working directory.
- Hash it — shasum -a 256, or the in-browser tool, which produces identical output.
- Timestamp the hash. The file is hashed in your browser and only the hash is transmitted, which matters when the code is proprietary.
- Store the certificate with the release, and record which tag it corresponds to.
- Keep the artefact, byte for byte. Regenerating it later may not reproduce identical bytes, since archive formats store timestamps and ordering.
That last point catches people out. A tar.gz rebuilt from the same tag on a different machine is frequently a different file. Keep the one you hashed.
Making it reproducible, if you want to skip step 5
Deterministic archives are achievable with effort — fixed modification times, sorted entries, a pinned compression level. If your build is already reproducible, hashing the output means anyone can regenerate and check it independently, which is stronger than asking them to trust your stored copy.
If it is not, keeping the artefact is entirely reasonable and much cheaper than making the build deterministic for this purpose alone.
What this gives you
| Question | Answered by |
|---|---|
| What did we ship? | The artefact |
| When did we ship it? | The timestamp |
| Who wrote it? | Signed commits and tags |
| Has it changed since? | The timestamp |
| Is it authentic? | A signed tag, plus the timestamp |
Signing and timestamping compose well and answer different questions. A signed tag proves who created it and that the contents are unmodified; the signature's date is still whatever the signer's machine claimed. Timestamping fixes the time independently. Do both for releases that matter.
When it is worth doing
Public releases where the date might matter in a licensing or infringement question.
Before an audit, escrow deposit or acquisition — a dated record of exactly what was handed over.
Before disclosing code to a client or partner, which is also the moment the code is most exposed as a trade secret. See trademark vs copyright for source code.
When you use a permissive licence and want a record of your version predating a fork's claims.
Not worth it for every commit. The point is a small number of dated anchors around states that might need defending, not ceremony on ordinary work.
For the wider version of this argument, see blockchain timestamping for software teams.