git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Ddemerphq <demerphq@gmail.com>
Date
Jan 15, 2023, 10:09 UTC
Message-ID
<CANgJU+X0LZfpdh4HWFC6-Y=+G6Mv-wKiZWrB=JJwe6CnYKeORg@mail.gmail.com>
In-Reply-To
<Y8NB21PExmifhyeQ@tapette.crustytoothpaste.net>

On Sun, 15 Jan 2023 at 01:05, brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 11 quoted lines
>
> 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/"
Previous: Junio C HamanoNext: Hans Petter Selasky
Message 4 of 16 in “Gitorious should use CRC128 / 256 / 512 instead of SHA-1”
  1. Hans Petter SelaskyJan 13, 2023
  2. brian m. carlsonJan 14, 2023
  3. Junio C HamanoJan 15, 2023
  4. demerphqJan 15, 2023
  5. Hans Petter SelaskyJan 16, 2023
  6. Hans Petter SelaskyJan 16, 2023
  7. rsbecker@nexbridge.comJan 16, 2023
  8. Hans Petter SelaskyJan 16, 2023
  9. Junio C HamanoJan 16, 2023
  10. Michal SuchánekJan 15, 2023
  11. Hans Petter SelaskyJan 16, 2023
  12. Michal SuchánekJan 16, 2023
  13. Hans Petter SelaskyJan 16, 2023
  14. rsbecker@nexbridge.comJan 16, 2023
  15. Hans Petter SelaskyJan 16, 2023
  16. Michal SuchánekJan 16, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.