Somewhere in your pipeline
there is a regular expression.
Zero to nine,
a to f,
exactly forty times.
It checks that the deploy tag
is a real commit.
Next to it,
a database column
sized to forty characters,
holding the revision
of every release you ever shipped.
And a script
that cuts a string at position forty
because that is where the hash ends.
Every one of them is correct today.
Git names everything
with SHA-1,
and a SHA-1 in hex
is forty characters long.
SHA-1 has been broken
for collisions since 2017.
Git has supported SHA-256 repositories
for years,
and its own plan
for the next major version
makes SHA-256 the default
for new repositories.
A SHA-256 hash in hex
is sixty four characters long.
Nothing will happen to you
on the day that ships.
Your existing repositories
stay as they are.
But a new repository
somebody creates next year
will hand your pipeline
a revision your regex refuses,
your column truncates,
and your script cuts in half.
The truncated one is the dangerous one,
because it does not fail.
It stores forty characters
of a sixty four character name,
and later something looks it up
and finds nothing,
or worse, guesses.
So go and look now,
while it is a search
and not an incident.
Grep for forty.
Grep for the regex.
Read every column
with revision or sha in its name.
Treat object names
as opaque strings
of whatever length Git gives you.
Ask Git
rather than parsing it.
rev-parse resolves and validates
a name for you.
Store the full name
in a column wide enough,
and keep short hashes
for humans only.
Then prove it.
Create a throwaway repository
with object format sha256,
push it through your build,
your deploy,
your changelog tool
and your release dashboard.
Write down everything that breaks.
Some of it
will be tools you do not own,
and those need asking about
before anybody needs the answer.
The length of a hash
was never a promise.
It was only the current one.
– Serguey Asael Shinder
Top comments (0)