4 ms·

Should SHA-1 be phased out of git, too? I understand that it's more of an issue for certs, but it's still a bit of an issue for anything that uses SHA-1. I'm ju

by SiVal 10y ago

Should SHA-1 be phased out of git, too? I understand that it's more of an issue for certs, but it's still a bit of an issue for anything that uses SHA-1. I'm just asking, not advocating, because the answer will depend on both benefits and costs, and I don't know enough about either in the case of git.

kevincox 10y ago
I don't think git's use was really intended for security. That being said it would be interesting to upgrade it and achieve security.
- petertodd 10y ago
  Regardless of whether or not it was intended for security, it is used for security now, via signed git commits and git tags. Lots of projects rely on them, and there aren't good alternatives yet; using third-party services like GitHub without signed git commits is very foolish. Fortunately it's only becoming possible for attackers to create pairs of messages that have the same SHA1 hash; an attacker still can't create a collision between a message of their choosing and an arbitrary SHA1 hash, and that type of attack is probably a long way off. But that's not much safety margin!
  - ploxiln 10y ago
    A scheme to generate (and sign) a SHA512 hash that more directly incorporates the full state of the repo was invented, and is used by some projects incl. nodejs https://github.com/cgwalters/git-evtag https://github.com/cgwalters/git-evtag https://github.com/nodejs/node/issues/7579 https://github.com/nodejs/node/issues/7579 I personally think it's overkill
    - petertodd 10y ago
      Oh, interesting! I do something not unlike that with my OpenTimestamps git commit signing: https://petertodd.org/2016/opentimestamps-git-integration https://petertodd.org/2016/opentimestamps-git-integration I don't describe it in that post unfortunately, as I still consider the git tree "rehashing" support to be alpha-level, but I'll look into git-evtag.
- OskarS 10y ago
  Still, I would hope that this is a planned-for possibility, that git might switch hash functions some day. Though it would create repositories that older versions of git can't use, and I don't know if they ever have made a backwards-compatibility breaking change like that.
majewsky 10y ago
In addition to what others said, I'm really skeptical as to whether it is possible at all to upgrade to something else. The hash is the object ID for all objects stored in Git, most prominently for commits which are referenced by their commit ID (i.e., the SHA-1 hash) all over the place, from internal datastructures to Github URLs. Rewriting to e.g. SHA-3 would therefore break a lot of references all over the place. Some can be rewritten automatically, some can't (e.g. commit IDs manually entered into commit messages).

by SiVal 10y ago

kevincox 10y ago

I don't think git's use was really intended for security. That being said it would be interesting to upgrade it and achieve security.

petertodd 10y ago
Regardless of whether or not it was intended for security, it is used for security now, via signed git commits and git tags. Lots of projects rely on them, and there aren't good alternatives yet; using third-party services like GitHub without signed git commits is very foolish. Fortunately it's only becoming possible for attackers to create pairs of messages that have the same SHA1 hash; an attacker still can't create a collision between a message of their choosing and an arbitrary SHA1 hash, and that type of attack is probably a long way off. But that's not much safety margin!
- ploxiln 10y ago
  A scheme to generate (and sign) a SHA512 hash that more directly incorporates the full state of the repo was invented, and is used by some projects incl. nodejs https://github.com/cgwalters/git-evtag https://github.com/cgwalters/git-evtag https://github.com/nodejs/node/issues/7579 https://github.com/nodejs/node/issues/7579 I personally think it's overkill
  - petertodd 10y ago
    Oh, interesting! I do something not unlike that with my OpenTimestamps git commit signing: https://petertodd.org/2016/opentimestamps-git-integration https://petertodd.org/2016/opentimestamps-git-integration I don't describe it in that post unfortunately, as I still consider the git tree "rehashing" support to be alpha-level, but I'll look into git-evtag.
OskarS 10y ago
Still, I would hope that this is a planned-for possibility, that git might switch hash functions some day. Though it would create repositories that older versions of git can't use, and I don't know if they ever have made a backwards-compatibility breaking change like that.

majewsky 10y ago

In addition to what others said, I'm really skeptical as to whether it is possible at all to upgrade to something else. The hash is the object ID for all objects stored in Git, most prominently for commits which are referenced by their commit ID (i.e., the SHA-1 hash) all over the place, from internal datastructures to Github URLs. Rewriting to e.g. SHA-3 would therefore break a lot of references all over the place. Some can be rewritten automatically, some can't (e.g. commit IDs manually entered into commit messages).