On Sun, 15 Jan 2023 at 01:05, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > This is a problem in every Merkle tree-like system. Most repositories > have some sort of code review or access control that prevents people > from generally pushing inappropriate content. For example, if somebody > proposed to push any sort of pornography or other inappropriate content > (e.g., a racist screed) to one of my repositories or one of my > employer's, I'd refuse to approve or merge such a change, because > that wouldn't be appropriate for the repository. > > I don't feel this is enough of a problem that using a Merkle tree-like > construction is a bad idea, given the benefits it offers. [resend in plain text] It isn't clear to me why this needs to be a problem at all. If the Merkele tree contains data later in its chain that says "replace Object X with Y", provided the replacement mechanism doesn't touch commit objects, only blobs, then you can replace files in the history with other files without altering the commit history. Provided the toolchain validates that it has found a proper "replacement instruction" in the history, it should be possible to safely replace blobs without a full history rewrite. The replacement mechanism could be structured so that you can only "nuke" a file, eg, replace it with a zero byte blob, making it somewhat less open to abuse, or it could allow arbitrary blobs to be mapped to each other. So long as the mapping data is in the commit history it should be as secure as the original mapping no? Git could be taught to warn the user "Checking out a rewritten blob X as Y, see 012deadbeef for the rewrite instruction." when it happened. Again, provided this does not touch the *commit* tree, just raw blobs, I dont see why you can't have an object replacement facility. Am I missing something? Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
