{"thread":{"id":"63742","subject":"Question: how will sha256sum be implemented in git","startedAt":"2025-07-04T11:18:15Z","lastAt":"2025-07-05T07:09:30Z","messageCount":3,"participants":["Aditya Garg","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"521310","messageId":"PN3PR01MB9597524FAEAA3B26B15804B9B842A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM","threadId":"63742","inReplyTo":null,"subject":"Question: how will sha256sum be implemented in git","fromName":"Aditya Garg","fromEmail":"gargaditya08@live.com","sentAt":"2025-07-04T11:18:12Z","receivedAt":"2025-07-04T11:18:15Z","isPatch":false,"sender":{"key":"gargaditya08@live.com","avatar":"https://avatars.githubusercontent.com/u/85610623?v=4"},"body":"Hi all\n\nI just read that git aims to transition to SHA256 by default, and conversion from SHA1 to SHA256 is needed for old\nrepos. I was just curious how will that be achieved.\n\nDumb idea, but maybe we can just encode the existing SHA1 sums' string to SHA256?\n\nEg: \n\n$ echo -n 8994f255af5451b6cd1db01ee16d8cf15b9df81e | sha256sum\nbf8d6d915848377db81ee47e883c0a683b3d86a49ab120191ea1c3d76a30c33f *-\n\nso bf8d6d915848377db81ee47e883c0a683b3d86a49ab120191ea1c3d76a30c33f will be our new commit hash.\n\nI think we can do that since sha256sum is chosen due to negligible collisions right?\n"},{"id":"521332","messageId":"aGgrIWSitF1NsN2L@fruit.crustytoothpaste.net","threadId":"63742","inReplyTo":"PN3PR01MB9597524FAEAA3B26B15804B9B842A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM","subject":"Re: Question: how will sha256sum be implemented in git","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-07-04T19:27:29Z","receivedAt":"2025-07-04T19:27:37Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-07-04 at 11:18:12, Aditya Garg wrote:\n> Hi all\n> \n> I just read that git aims to transition to SHA256 by default, and conversion from SHA1 to SHA256 is needed for old\n> repos. I was just curious how will that be achieved.\n> \n> Dumb idea, but maybe we can just encode the existing SHA1 sums' string to SHA256?\n> \n> Eg: \n> \n> $ echo -n 8994f255af5451b6cd1db01ee16d8cf15b9df81e | sha256sum\n> bf8d6d915848377db81ee47e883c0a683b3d86a49ab120191ea1c3d76a30c33f *-\n> \n> so bf8d6d915848377db81ee47e883c0a683b3d86a49ab120191ea1c3d76a30c33f will be our new commit hash.\n\nThis would unfortunately still be vulnerable to collisions in SHA-1,\nwhich is the problem we're trying to avoid.  For instance, if I can\ncreate two blobs with that SHA-1 hash, then I can also create two blobs\nwith the corresponding SHA-256 value, since the input in this case is\njust the SHA-1 value.\n\nThe way we do the transition is pretty simple.  Blobs don't change; we\njust hash them with either SHA-1 or SHA-256.  For trees, we re-write all\nof the entries to use the SHA-256 object IDs instead of the SHA-1 object\nIDs and then we hash the result with SHA-256.  And for commits and tags,\nthe headers that represent objects (tree, parent, and object) are\nconverted in a similar manner and then, again, hashed with SHA-256.\n\nYou can actually see how the conversion operates in\n`object-file-convert.c`.  `repo_oid_to_algop` converts an object from\none format to another based on the loose object map outlined in\n`Documentation/technical/hash-function-transition.adoc`, or the v3 pack\nindex functionality which is not yet upstream but is available in my\n`sha256-interop` branch.  In general, the hash function transition\ndocument explains a lot of the decision behind why we're doing what\nwe're doing and how it works.  I have to give credit to Jonathan Nieder\nfor writing the document and to many people on the list for helping to\ncontribute to it, and I encourage you to read it: it's not too complex.\n\nSo with this approach, the SHA-256 object ID is computed totally\nindependently of the SHA-1 object ID but in the exact same way, just\nwith SHA-256 object IDs inside.  We already have support for\nSHA-256-only repositories right now: you can do `git init\n--object-format=sha256` and create one, although not all forges and\ntools currently support them.\n\nThe process of the conversion when we're in interoperability mode means\nthat we can take a repository that's in SHA-1, convert it to SHA-256,\ncontinue to interoperate with the old SHA-1 version if we like, and\nthen, when we no longer want to use SHA-1, simply stick with the SHA-256\nversion and avoid using SHA-1 at all.  That's part of what I'm working\non right now, and I'm pleased to report that I'm making a good amount of\nprogress.  If you're able to attend Git Merge this year, either in\nperson or remotely, I'll be giving a talk on this topic.\n\nI'm also planning to open a discussion on the list within the next\ncouple days or weeks about some protocol extensions that will be\nnecessary to let us fetch, clone, and push all repositories in\ninteroperability mode, so please feel free to follow along for that.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"521341","messageId":"PN0PR01MB95888ED474AD92298DD290A3B84DA@PN0PR01MB9588.INDPRD01.PROD.OUTLOOK.COM","threadId":"63742","inReplyTo":"aGgrIWSitF1NsN2L@fruit.crustytoothpaste.net","subject":"Re: Question: how will sha256sum be implemented in git","fromName":"Aditya Garg","fromEmail":"gargaditya08@live.com","sentAt":"2025-07-05T07:09:19Z","receivedAt":"2025-07-05T07:09:30Z","isPatch":false,"sender":{"key":"gargaditya08@live.com","avatar":"https://avatars.githubusercontent.com/u/85610623?v=4"},"body":"\n\nOn 5 July 2025 12:57:29 am IST, \"brian m. carlson\" <sandals@crustytoothpaste.net> wrote:\n>On 2025-07-04 at 11:18:12, Aditya Garg wrote:\n>> Hi all\n>> \n>> I just read that git aims to transition to SHA256 by default, and conversion from SHA1 to SHA256 is needed for old\n>> repos. I was just curious how will that be achieved.\n>> \n>> Dumb idea, but maybe we can just encode the existing SHA1 sums' string to SHA256?\n>> \n>> Eg: \n>> \n>> $ echo -n 8994f255af5451b6cd1db01ee16d8cf15b9df81e | sha256sum\n>> bf8d6d915848377db81ee47e883c0a683b3d86a49ab120191ea1c3d76a30c33f *-\n>> \n>> so bf8d6d915848377db81ee47e883c0a683b3d86a49ab120191ea1c3d76a30c33f will be our new commit hash.\n>\n>This would unfortunately still be vulnerable to collisions in SHA-1,\n>which is the problem we're trying to avoid.  For instance, if I can\n>create two blobs with that SHA-1 hash, then I can also create two blobs\n>with the corresponding SHA-256 value, since the input in this case is\n>just the SHA-1 value.\n>\n>The way we do the transition is pretty simple.  Blobs don't change; we\n>just hash them with either SHA-1 or SHA-256.  For trees, we re-write all\n>of the entries to use the SHA-256 object IDs instead of the SHA-1 object\n>IDs and then we hash the result with SHA-256.  And for commits and tags,\n>the headers that represent objects (tree, parent, and object) are\n>converted in a similar manner and then, again, hashed with SHA-256.\n>\n>You can actually see how the conversion operates in\n>`object-file-convert.c`.  `repo_oid_to_algop` converts an object from\n>one format to another based on the loose object map outlined in\n>`Documentation/technical/hash-function-transition.adoc`, or the v3 pack\n>index functionality which is not yet upstream but is available in my\n>`sha256-interop` branch.  In general, the hash function transition\n>document explains a lot of the decision behind why we're doing what\n>we're doing and how it works.  I have to give credit to Jonathan Nieder\n>for writing the document and to many people on the list for helping to\n>contribute to it, and I encourage you to read it: it's not too complex.\n>\n\nI'll have a look\n\n>So with this approach, the SHA-256 object ID is computed totally\n>independently of the SHA-1 object ID but in the exact same way, just\n>with SHA-256 object IDs inside.  We already have support for\n>SHA-256-only repositories right now: you can do `git init\n>--object-format=sha256` and create one, although not all forges and\n>tools currently support them.\n>\n>The process of the conversion when we're in interoperability mode means\n>that we can take a repository that's in SHA-1, convert it to SHA-256,\n>continue to interoperate with the old SHA-1 version if we like, and\n>then, when we no longer want to use SHA-1, simply stick with the SHA-256\n>version and avoid using SHA-1 at all.  That's part of what I'm working\n>on right now, and I'm pleased to report that I'm making a good amount of\n>progress.  If you're able to attend Git Merge this year, either in\n>person or remotely, I'll be giving a talk on this topic.\n\nI'll see if remotely is possible. I neither have a US visa for in person, nor it suits my budget.\n\n>\n>I'm also planning to open a discussion on the list within the next\n>couple days or weeks about some protocol extensions that will be\n>necessary to let us fetch, clone, and push all repositories in\n>interoperability mode, so please feel free to follow along for that.\n\nGreat!\n"}]}