Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1

[demerphq <demerphq@gmail.com>]

On Sun, 15 Jan 2023 at 01:05, brian m. carlson
<sandals@crustytoothpaste.net> 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/"