4 ms·

I've actually worked on git internals and I'm in the same boat. As part of a security-related project some years ago, my team and I hacked jgit to use SHA256,

I've actually worked on git internals and I'm in the same boat. As part of a security-related project some years ago, my team and I hacked jgit to use SHA256, which required changing the length of pretty much every on-disk data structure. Sadly, there was (probably still is) no HASH_LEN constant, just a lot of magic offsets strewn throughout the code. I had to compare lengths against the git spec at every step. And yet I still scramble for stackoverflow every time something goes slightly amiss.

sam_lowry_ 5y ago
What a pointless project! U hope you were paid well, at least.
- stickfigure 5y ago
  I was. But it wasn't quite as pointless as it sounds - the tool was a sort of tripwire-like system, with changes shipped to an append-only log, that itself was checkpointed in an early blockchain-ish structure. The threat model was "nation state actor" so the client wouldn't accept SHA1. It was actually a pretty cool system. I don't think it was ever sold though.
  - unknown_error 5y ago
    Man, I thought zero days and secret backdoors were bad enough. Now we have to worry about manufactured hash collisions in all our repos' files dating back forever?
    - simonelnahas 5y ago
      That seems like an overkill. Couldn't you combine the hash together with the date to obtain uniqueness?
      - unknown_error 5y ago
        The date isn't really meaningful since it can be set to anything on a file. But if you can force two dissimilar files to have the same hash, you can combine that with some other attack to inject it into some sort of chain of trust, whether it's git or some other type of checksum based system. Then combine that with a SolarWinds like attack and even if they try to revert to something from years earlier, they can't guarantee that the rollback files are still unaltered unless they had multiple hashes to compare it to or diffed it manually. But multiply that by X thousand files over Y commits during Z years and it would be very difficult to detect.
  - sam_lowry_ 5y ago
    I do not remember jgit internals, but its API is pretty bad. I always assumed it was some kind of throwaway PoC suddenly turned popular.
    - stickfigure 5y ago
      > some kind of throwaway PoC suddenly turned popular Wow, that description feels spot on.
davvid 5y ago
There's an ongoing effort to rework core Git so that the hash implementation can be swapped out for eg. SHA256. [1] jGit is actually a separate project from core Git, but once it gets adopted into core Git we can expect that jGit will follow suite, given that it's critical to Gerrit and other projects. [1] https://lore.kernel.org/git/20191223011306.GF163225@camp.crustytoothpaste.net/ https://lore.kernel.org/git/20191223011306.GF163225@camp.cru...

sam_lowry_ 5y ago

What a pointless project! U hope you were paid well, at least.

stickfigure 5y ago
I was. But it wasn't quite as pointless as it sounds - the tool was a sort of tripwire-like system, with changes shipped to an append-only log, that itself was checkpointed in an early blockchain-ish structure. The threat model was "nation state actor" so the client wouldn't accept SHA1. It was actually a pretty cool system. I don't think it was ever sold though.
- unknown_error 5y ago
  Man, I thought zero days and secret backdoors were bad enough. Now we have to worry about manufactured hash collisions in all our repos' files dating back forever?
  - simonelnahas 5y ago
    That seems like an overkill. Couldn't you combine the hash together with the date to obtain uniqueness?
    - unknown_error 5y ago
      The date isn't really meaningful since it can be set to anything on a file. But if you can force two dissimilar files to have the same hash, you can combine that with some other attack to inject it into some sort of chain of trust, whether it's git or some other type of checksum based system. Then combine that with a SolarWinds like attack and even if they try to revert to something from years earlier, they can't guarantee that the rollback files are still unaltered unless they had multiple hashes to compare it to or diffed it manually. But multiply that by X thousand files over Y commits during Z years and it would be very difficult to detect.
- sam_lowry_ 5y ago
  I do not remember jgit internals, but its API is pretty bad. I always assumed it was some kind of throwaway PoC suddenly turned popular.
  - stickfigure 5y ago
    > some kind of throwaway PoC suddenly turned popular Wow, that description feels spot on.

davvid 5y ago

There's an ongoing effort to rework core Git so that the hash implementation can be swapped out for eg. SHA256. [1] jGit is actually a separate project from core Git, but once it gets adopted into core Git we can expect that jGit will follow suite, given that it's critical to Gerrit and other projects. [1] https://lore.kernel.org/git/20191223011306.GF163225@camp.crustytoothpaste.net/ https://lore.kernel.org/git/20191223011306.GF163225@camp.cru...