Comment by ramses0 | Hacker News Reader

Comment by ramses0 | Hacker News Reader

Parent Full thread

Dude... please bow out gracefully...

The attack is I pre-author `Makefile => foo: echo "hello"; bar: echo "world"` along with `Makefile => foo: echo "hello"; bar: rm -rf / ; /* $ELDRITCH_SHA1_SPIRITS_GO_HERE */` that both hash to `ff1234...`

I then prepopulate the repo with `echo "hello"`, wait 6-9 months, then submit a commit for `echo "hello" ; echo "world"` and keep (in my back pocket) the alternate implementation that also includes $ELDRITCH_SPIRITS to force a collision and MY predetermined change in functionality.

I then have free choice as to whether I serve them "hello world" or "hello && rm -rf", and THAT's the plausible problem to avoid: the ability to "cloak" content anywhere within the repo if you have enough $ELDRITCH_SPIRITS and GPU's.

You have _really_ good points, but are woefully confused. The proper answer is (would have been) to include `tree ff12354...` along with `tree-sha256 abc123456789...` for another 20 years along with a `[git.hash_strictness]: default/lazy/strict`, and some oddball `git-rerere` type packfile extension which lets you map `sha1:ff1234... => sha256:abc123456789...` "transparently" rather than the horrific situation you're laying out (correctly!) that forks the ecosystem in to "longhash" and "shorthash" when most repos don't even care in the end.

> woefully confused

Yes, I didn't understand that the GPG signing just operates on the top level object in the commit and trusts the SHA-1 hashes contained in it.

The signing process doesn't recursively traverse the bytes of the commit to pull them into GPG, like you would expect.

It's like, imagine you made a "bill of materials" of your project's files consisting of their names and CRC-32 checksums, and then signed this file, and called your project securely signed, LOL.

This aspect can be fixed without foisting new hashing scheme into the content tracker. In fact, it must be fixed; users on SHA-1-based repos deserve secure signing.

It's really sneaky that the SHA-1 business (not intended to be a security mechanism) was embroiled into the signing implementation; that GPG is demoted to the strength of SHA-1.

Was that just to save some cycles? It's certainly faster just to sign the commit object!

signatures are basically always computed over hashes. The only problem here is that the hashes are not secure. And this is being fixed.

No, but, the hashes are features of the content tracking system that hook it together. There is no reason that a signing scheme must rely on and trust those hashes!

We can round up the bits that make up a commit in a SHA-1-based repo, and sign those bits securely; this is a thing that is possible.

> We can round up the bits that make up a commit in a SHA-1-based repo, and sign those bits securely; this is a thing that is possible.

Yes but as my other comment explains, this is not particularly useful in and of itself.

It represents an increment in security which doesn't require switching to a SHA-256 repo.

Remember: bow out gracefully

you're arguing a position which indicates you don't know git's physical (textual) commmit structure.

Spend some quality time with:

    git cat-file -p HEAD

You'll get something like:

    tree ff1234...
    parent ccddef...

    fix(BUG-1245): my ai fixed it

Continue to `cat-file -p $TREE` and you'll get:

    file efef12... Makefile
    tree a1b2c3... src/
    file f0ea12... README.md

...and then it's turtles all the way down. It is (was!) safe to sign $HEAD (and only head!) because... it's turtles all the way down. Signing HEAD attaches IDENTITY (eg; torvalds@linux.com) to CONTENT (eg: src/@a1b2c3...) and TRANSITIVELY all the way down.

Your homework is to go run:

    time (
      git ls-files | xargs -n 1 sha256sum
    ) | sha256sum

...and then make a commit (nee: tag/note) containing that content as the commit message.

Your INSTINCT isn't wrong, your mechanics run counter to the practicalities of how git is designed to work, and the practicalities of the crucial defense that git-core is trying to divert: the ability to arbitrarily alter the signed(!!!) past, signed by third parties, with $ELDRITCH_SHA1 attacks.

You _still_ have to trust that GitHub.com or kernel.org won't get popped and start erroneously serving "signed but faulty" files and trees, but the urgency of moving to sha256 is about preventing faulty commits in the first place, which removes the requirement of "trust me bro!" relationship with the serving provider (or MITM).

> you're arguing a position which indicates you don't know git's physical (textual) commmit structure.

That is false; hopefully everyone here understands that it's a graph linked by hash "pointers", such as SHA-1. I have not seen evidence otherwise.

> time (

Of course I understand that it's (possibly vastly) more expensive to digest the content than just a top-level node. So what? Maybe someone would pay that, if they had the option.

> There is no reason that a signing scheme must rely on and trust those hashes!

Not "must", but it would be stupid to use two sets of hashes without a compelling reason.

Two hashes are already used now: GPG isn't using a SHA-1 digest, but it's signing something that is using SHA-1 digests to refer to other objects.

(Inside GPG, there are configurable choices. It's possible to be using SHA-512, so in a SHA-256 git repo, you can still be using two hashes.)

You are again talking about a fictional alternate reality in which git commit signatures do something like GPG_Sign(GPG_Signature_Hash(git commit || all objects referenced by commit))), instead of ours where it's GPG_Sign(GPG_Signature_Hash(git commit))), and the git commit is in turn some metadata and a git hash of a bunch of objects.

In our reality, the git hash is load bearing. You can disagree with that design choice, but you can't pretend to live in that alternate reality and design your solutions for this reality according to that.

> You are again talking about a fictional alternate reality

> can't pretend to live in that alternate reality

Discussions about solutions that don't exist or requirements not implemented are everyday occurrences and necessary.

I mean, if you're talking with a contractor about how your bathroom should look, that is a "fictional alternate reality", but you're not pretending to be living in it now.

I don't understand the purpose of the above engagement style, but it doesn't look like a great fit for HackerNews.

There's a difference between talking about a hypothetical path forward and a hypothetical different past. The latter can be intellectually interesting but is rarely part of normal project planning.

One difference is that I'm talking about the one and not the other. I have no interest in a hypothetical different past. This is a real issue; woulda coulda been talk, or told-you-so, etc, is what people engage in when they don't have any stake in something.

As far as git is concerned, GPG is a black box and git feeds it normal git hashes, of which there is only one kind. This design makes sense.

For anything else, it depends on the exact scheme:

If git sent GPG the bits for the current commit specifically because it expects a better hash to be used, that would be silly to design on purpose (git should use a hash that meets all requirements). And it wouldn't protect history, which matters.

If git rounded up the bits of history, that would perform unacceptably badly.

If git used a better hash to secure history for signing purposes, and still had the normal hash elsewhere, that would be very silly to design on purpose because it should use the better hash for everything.

But is "commit" in this context a full snapshot or a delta? Because what you describe will only work for the former.

Regardless, commit hashes should be a security mechanism IMO. And not just commits. I should be able to treat _any_ content addressing system as having secure addresses. If you can engineer collisions you need to patch your system.

(Note that the above does not necessarily imply support for unconditionally forcing a fork of the entire git ecosystem.)

> There is no reason that a signing scheme must rely on and trust those hashes!

Yes, but git's signing scheme(s) do, as do many third-party ones, so what are you arguing for, exactly?

The non-necessity of a fix in an alternate reality in which nobody uses git as documented? One in which git launched with a big disclaimer of "never trust our cryptographically secure hash function to be cryptographically secure" in its documentation and CLI outputs?

Because one thing is certainly a big no-go in our reality: git walking back these explicit and implicit (Hyrum's law) contracts because fixing a load-bearing hash function is hard.

Improving a signing scheme in the same repository format is less disruptive. It may not hit all the checkboxes, but it seems worth doing.

> The signing process doesn't recursively traverse the bytes of the commit to pull them into GPG, like you would expect.

No I wouldn't expect this. If by recursive you mean traversing the entirety of git history, that would be prohibitively expensive performance-wise (imagine rehashing the entire multi-gigabyte history of the Linux kernel every time to sign and verify a commit) and destroy git functionality such as shallow clones and blob-less clones.

If you by recursive you are only referring to the current working directory, as I lay out here https://news.ycombinator.com/item?id=49930048 it doesn't work. Indeed, without attestation of parent commits, a malicious attacker can actively frame any pre-existing vulnerability as someone else's handiwork by simply inserting a new commit that purports to be the parent of another commit that does not contain the vulnerability, which then makes the original commit look like the source of the vulnerability.

"I didn't introduce the vulnerability, he did! Look I can even prove it with my signed commit!"

>"I didn't introduce the vulnerability, he did! Look I can even prove it with my signed commit!"

I misspoke. It's worse. "I didn't introduce the vulnerability, he did! Look I can even prove it with his signed commit!"

Well, no, you cannot because under this system, you can't prove anything about some other commit; the history is not trusted.

You can produce two commits that have the same SHA-1 and hash them. One has the vulnerability and one doesn't.

Then someone else bases a new commit on the one with the vulnerability, which has yours as the parent. You then swap in the one without the vulnerability and now it looks like the child is introducing that change.

Their only defenses are (1) plausible deniability (we don't trust parent hashes) and (2) still having the original commit they based theirs on to show that a swizzle took place and that the real original already had the vuln.

> It's like, imagine you made a "bill of materials" of your project's files consisting of their names and CRC-32 checksums, and then signed this file, and called your project securely signed, LOL.

If you are arguing that CRC-32 is a cryptographically secure hash function you might.

SHA-1 is (or rather, used to be) one, so you actually can. This is literally how git works.

> It's really sneaky that the SHA-1 business (not intended to be a security mechanism) was embroiled into the signing implementation; that GPG is demoted to the strength of SHA-1.

What's sneaky about it? It's a completely reasonable design decision, making git orders of magnitude more efficient than the counterfactual you're arguing for.

> Was that just to save some cycles? It's certainly faster just to sign the commit object!

Sure, "just" read potentially gigabytes of data, potentially over the network, and send them through your cryptographic hash function as opposed to just the objects you're touching in your commit. Absolutely the same effort.

Also, note that you can just sign "hello world" and "hello && rm -rf", then serve whichever you want. In the absence of a hash, then everyone has to trust you not to do that. With SHA-256 git, and a one-time audit of the code, they would need neither your public key nor to trust that the code didn't change.

Reply on news.ycombinator.com