89
Git 3.0's upcoming SHA-256 default will be a costly mistake (blog.gitbutler.com)
submitted 4 days ago by to c/programming@programming.dev
25 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 3 days ago (4 children)

Worth to keep in mind though that the gpg signature basically only signs the (git) hashes of the contained objects, so the choice of hash function is indeed important for security.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 3 days ago* (last edited 3 days ago) (3 children)

    Indeed it is still relevant. I am wondering what does it sign for tags.

    EDIT: Are you sure about that? signing the hash felt logical but digging about it this seems a false assumption. git is signing the whole commit object.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 3 points 3 days ago (2 children)

    Yes, but the "commit object" is just a bunch of metadata that refers to the tree by its hash:

    % git cat-file commit 6de20f6092
tree 5cb21f9acf8c31ce1a8f6bb0bbc3b9e4e8607ce8
parent c679abf7d2c0f3f4ee623e0882a50964e9b100cc
author Junio C Hamano <gitster@pobox.com> 1791306800 -0700
committer Junio C Hamano <gitster@pobox.com> 1791306812 -0700

The 4th batch

Signed-off-by: Junio C Hamano <gitster@pobox.com>

    And the tree in turn refers to the files (or subfolders) by their hashes:

    % git cat-file -p 5cb21f9acf8c31ce1a8f6bb0bbc3b9e4e8607ce8 | head
100644 blob fd4fb56b6d56789369d4824ad10999369127f5c7	.b4-config
100644 blob 8168d8a10b3a9e14f6c019e8ffbe5a71dc307d8b	.b4-cover-template
100644 blob fef04a38402fee6465a6a4225374d493b47421c0	.cirrus.yml
100644 blob 86b4fe33e5cd98e2a347944559c345419824c245	.clang-format
100644 blob 82e121a41754b536611c9ce9b2b4aba349e7ed9d	.editorconfig
100644 blob 26490ad60a74d0968eaf2f77abffcb21d78b18e3	.gitattributes
040000 tree 5f898fc5ec3429058fd21072db170fff9e49eab4	.github
100644 blob 0209bd16f209c232748734d911099b37be80fc12	.gitignore
100644 blob 3f2483550038f6aabb2f8b858b4ee7b29a66072a	.gitlab-ci.yml
100644 blob cbeebdab7a5e2c6afec338c3534930f569c90f63	.gitmodules

    If you can produce a hash collision, you can therefore have two repositories with the same signed commit but different file content.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 days ago (1 child)

    Yes you are right, damned! Why git isn't signing the diff (patch)? This is so wrong on so many level, signing already hash the content, we can sign multiple GiB without any issue.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 2 days ago

    Hm, I wouldn't call it wrong on many levels, I think it's quite elegant. It's a form of a Merkle Tree, and knowing the hash of a commit does not just allow you to verify its content, but also the whole history up to that point (as the commit contains the hash of its parent, which in turn contains hashes of its content and parents). I guess that's not too unimportant if you consider scenarios where you pull code from distributed repositories (like forks), as you can ensure that the parts of the history you know are actually what they claim to be. And if you accept hash-then-sign as being secure, this is just as secure for signed commits (assuming the hash function is secure).

    I think the only unfortunate part here is that git ended up using SHA-1 as a hash function, which 20 years ago might or might not have been a reasonable choice -- I don't know how "broken" it was regarded back then, or how widespread SHA-256 use was.

  • permalink
  • fedilink
  • source
  • parent