5 ms·

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 i

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.)

quickthrower2 5y ago
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)
- sverhagen 5y ago
  I have a few places where the shorthash becomes the Docker tag. But you make a good point nonetheless.
  - alex_young 5y ago
    If you're keeping that many docker images around you have other problems to worry about.
    - tedunangst 5y ago
      You can have two colliding short hashes in a row.
      - mlyle 5y ago
        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.
        deleted 5y ago
        [deleted]
    - afrodc_ 5y ago
      It's usually a shorthand reference to figure out what commit your image is built from. Unless you're implying something else
      - mnahkies 5y ago
        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/annotations.md#pre-defined-annotation-keys https://github.com/opencontainers/image-spec/blob/main/annot...)
  - tobyjsullivan 5y ago
    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.
  - sneak 5y ago
    Docker tags are also themselves not cryptographically secure - the repository owner can replace a tag. Better is to use org/imagename@sha256:<hash>
    - infogulch 5y ago
      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.
      - jhugo 5y ago
        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.
  - im3w1l 5y ago
    I would worry about a scenario where I grab the shorthash at some point in time, and it later becoming ambiguous.
kevinventullo 5y ago
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!

quickthrower2 5y ago

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)

sverhagen 5y ago
I have a few places where the shorthash becomes the Docker tag. But you make a good point nonetheless.
- alex_young 5y ago
  If you're keeping that many docker images around you have other problems to worry about.
  - tedunangst 5y ago
    You can have two colliding short hashes in a row.
    - mlyle 5y ago
      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.
      - deleted 5y ago
        [deleted]
  - afrodc_ 5y ago
    It's usually a shorthand reference to figure out what commit your image is built from. Unless you're implying something else
    - mnahkies 5y ago
      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/annotations.md#pre-defined-annotation-keys https://github.com/opencontainers/image-spec/blob/main/annot...)
- tobyjsullivan 5y ago
  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.
- sneak 5y ago
  Docker tags are also themselves not cryptographically secure - the repository owner can replace a tag. Better is to use org/imagename@sha256:<hash>
  - infogulch 5y ago
    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.
    - jhugo 5y ago
      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.
- im3w1l 5y ago
  I would worry about a scenario where I grab the shorthash at some point in time, and it later becoming ambiguous.

kevinventullo 5y ago

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!