Hacker News Reader

Comment by sverhagen | Hacker News Reader

As the README.md acknowledges, the usefulness may be limited, except for the fun in experimentation. What may not be obvious to basic Git users is that, while it may take 2^28 commits to fill up the entire address space of the 7-character shorthash, they are not designed to be unique (they are just the first part of the longer, unique hash). As a result, even relatively small repositories often already have _some_ duplicate shorthashes. And people scripting around their Git shorthashes must be prepared to deal with larger shorthashes, like 8-characters, 9, 10, 11, whatever it takes to disambiguate. My random Git repository of a mere 16865 commits (well, that's just "master") that I'm looking at over here, nothing out of the ordinary, needs shorthashes up to 11 characters to disambiguate all of them. (Not all the clashes may be on the same or main branch.)

View on HN

Does anyone use short hashes for scripting? If the computer is dealing with it, might as well use the whole thing. I only use a short hash for human searching type activities where I sanity check the commit message (I’m probably reviewing code or doing some sort of blame exercise)

I have a few places where the shorthash becomes the Docker tag. But you make a good point nonetheless.

If you're keeping that many docker images around you have other problems to worry about.

You can have two colliding short hashes in a row.

You can have two colliding full length hashes in a row, too. It's just not very likely.

7-8 character shorthashes are perfectly reasonable for tracking a few thousand objects without much chance of collision. There's a tradeoff between the uniqueness guarantee and the friendliness if humans ever need to see the identifier.

Of course, sequential identifiers can be even shorter and friendlier, but they are more troublesome in several ways than hash-derived ones.

It's usually a shorthand reference to figure out what commit your image is built from. Unless you're implying something else

I generally use the build number from ci for the tag, and add the git commit and repo URL as a label/annotation (following https://github.com/opencontainers/image-spec/blob/main/annot...)

Exactly this. Short hash to identify builds, generally, seems to a pattern (and one that usually works fine in practice).

It gets a bit dicy once you setup CI to start generating builds/images off every commit to master, and then off every push to every branch. In practice, though, I haven't seen it bite of the projects I've been on. Usually something will break and then you just update the scripts to use N+1 characters.

In theory, a short-sighted script without safeties could do something wacky like deploy an image that's several months/years old. Running the numbers suggests something so catastrophic is quite unlikely.

Docker tags are also themselves not cryptographically secure - the repository owner can replace a tag. Better is to use

    org/imagename@sha256:<hash>

The point is to link the docker image to the git commit, that just identifies the image by the image's own hash. Not the same thing.

I'm not the parent commenter, but I'm sure they know that.

I think their point is that the image which a tag refers to can be changed in the repository, so if you're concerned someone might generate a Git commit with a colliding hash and produce another build with the same hash, there is in fact a much simpler attack scenario: replace the container image in the repository with any different image with the same tag.

The syntax they provided identifies the image by its own hash, so producing a different image with the same hash is _much_ more difficult.

I would worry about a scenario where I grab the shorthash at some point in time, and it later becoming ambiguous.

According to the Birthday Problem rule of thumb, you would expect collisions starting around sqrt(2^28) = 2^14 = 16384 commits. About the size of your repo!

Reply on news.ycombinator.com