On 2023-05-08 at 02:00:56, Felipe Contreras wrote: > brian m. carlson wrote: > > On 2023-05-02 at 23:46:02, Felipe Contreras wrote: > > > In my view one repository should be able to have part SHA-1 history, > > > part SHA3-256 history, and part BLAKE2b history. > > > > That is practically very difficult and it means that it's hard to have > > confidence in the later history because SHA-1 is weak and you have to > > rely on it to verify the SHA-256 history later. > > Why would I have to rely on SHA-1 to verify the SHA-256 history later > on? If your history contains mixed and matched hash algorithms, you'll need to be able to verify those commits to the root to have any confidence in a signed commit or tag, which means trusting SHA-1 if you have any SHA-1 commits in the repository. > > Since attacks always get better, SHA-1 will eventually be so weak that > > collisions can be computed in the amount of time we now take for MD4 > > or MD5 collisions (i.e., seconds), and with your plan, we'd have to > > retain that history forever with the resulting lack of confidence in > > part of the history. > > We have to do the same with your plan as well. > > Your plan relies on SHA-256 being interchangeable with SHA-1, so if the > Git project decided to switch *today* to SHA-256, we would have two > object ids: > > 1. 69c786637d7a7fe3b2b8f7d989af095f5f49c3a8 > 2. 2b4ebdace10518280172449c012af17b51e9d46e023a91a5d3dd3a8ad9e4a116 > > This object would refer to a tree and a parent object with SHA-1 ids, > which would be OK, because they would be interchangeable with some > corresponding SHA-256 ids. > > Isn't that your plan? For a period of time, yes. At some point, people will abandon SHA-1 and won't use it anymore for a particular repository, and then its security doesn't matter. > Therefore the SHA-1 of the parent of the commit, and the tree of the > commit would be trusted and retained forever. Nope. At some point, we just turn off SHA-1. > > This also doesn't work with various structures like trees, the index, > > and pack and index formats, which have no indication of the algorithm > > used and simply rely on fixed-size, often 4-byte aligned object IDs > > without any metadata. > > So? The index and pack objects can be regenerated, so at any point in > time they could be regenerated for SHA-1 or SHA-256. Right, and that point you've basically converted the repository over. > The tree object is a no-brainer. For an object of type "commit:256" you > require a tree of type "tree:256". Easy. That doesn't work with the pack format because there are only seven valid types of objects, and five of them are used. > > Also, we've already decided on the current design a long time ago with > > the transition plan after extensive, thoughtful discussion by many > > people. > > Who is "we"? The list members. > I've participated in many discussions in the git mailing list where the > consensus is that 99% of people decide to do something, and that > something never happens. > > The fact that "we" have decided something doesn't carry as much weight > as you seem to think it does. Jonathan Nieder decided to propose an approach for how we'd go about this, and it was discussed extensively on the list and the parts that I've implemented have almost completely conformed to that documentation. I think his approach was very thoughtful and addressed many questions about how the project was to proceed, and I appreciate that he sent it and that others contributed in a helpful way. The project wouldn't have been possible unless we had a clear decision on how to implement things. There was an opportunity at the time to comment on the approach and propose alternatives, and we didn't choose to adopt any. > Moreover, haven't "we" decided that this transitioning plan is > *tentantive*, and the SHA-256 feature is *experimental*? We've documented that it's experimental because it's not seeing wide use. I expect that will change, at which point it will no longer be experimental. The design is not tentative and there are no plans to change it. > > Very few people other than me have worked on sending patches to > > work on the hash function transition, and that work up to now has all > > been done on my personal time, without compensation of any sort, out of > > a desire to improve the project. > > Which seems to suggest if there is a need, it's not very pressing. > > Doesn't it? No, I don't agree. An approach to continue to use SHA-1 indefinitely means that Git will not be viable at many major organizations and in many major governments which have restrictions on using insecure cryptography. I think this ends the point at which I'd like to respond to your proposal further. I continue to feel that it's argumentative, unproductive, and not in the best interests of the project, and I don't think continuing here is going to shed any more light on the topic. Ultimately, I feel that my previous statement that we're not going to see eye to eye on most things continues to be correct. I also don't think arguing with you is a productive use of my time or a positive contribution to the community, and in general, I'm going to avoid commenting on your patches or proposals because I can't see a way that we can interact in a useful and helpful way on the list or elsewhere. As a result, I'll kindly ask you to refrain from CCing me on further emails to the list or otherwise emailing me for the indefinite future, and I'll do the same for you after this email. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
