  > if it takes an unsigned commit and signs only its SHA-1 hash and then creates a new commit with GPG headers

It does indeed. The bytes passed to GPG when constructing a signed commit look something like:

  tree eebfed94e75e7760540d1485c740902590a00332
  parent 04b871796dc0420f8e7561a895b52484b701d51a
  author Alice <alice@example.com> 1465981137 +0000
  committer Alice <alice@example.com> 1465981137 +0000

  Headline

  Message

where the contents being signed are entirely represented by the oids of the tree object and parent commit object. This string is very similar to the content that is fed to the hash function to produce a normal git commit object id.

▲ kazinator an hour ago | parent [-]

Haha, well that is a screw up. The weak tree hash can be attacked, replacing the content that is itself not pulled into GPG.

The "bytes passed to GPG" of course get hashed by GPG, using something better than SHA-1.

All bytes that comprise the commit should be hashed by GPG, rather than depending on the content referencing hash in the object tracking system.

This is something that is possible; it is not a logically deductive necessity that we just scan the topmost object and trust the hashes it contains.

	▲	dwohnitmok an hour ago \| parent [-]
		> it is not a logically deductive necessity that we just scan the topmost object and trust the hashes it contains. It kind of is. Otherwise the whole idea of signing a commit with a backing git history (rather than just a snapshot of a working directory) collapses. The only guarantee you have that the git history is what is claimed by the cryptographic signature is some sort of Merkle tree structure. Either the original one, or you have to construct a whole new parallel one with a better hash, in which case, as I bring up in a cousin comment, why not just use a better hash in your original one?