Thanks for this, you answered my questions thoroughly. I'm not entirely convinced by this though:
> [A signed commit] doesn't guarantee anything about the contents of that commit if the repository has been tampered with.
I think most people would intuitively expect the signed commit to guarantee the contents of the tree being signed. The idea that you could "git pull" a repo from a compromised machine, verify the signed commit, but not actually have a guarantee about the tree matching the one that was signed would run counter to most people's expectations, I suspect.
In other words, this to me seems like a "technically, we don't guarantee" statement about something that is de facto thought to be guaranteed.
I did a bit of quick reading on this and at first glance my description of how git tagging works appears to be on point, i.e. all it guarantees is that a particular user asserts that tag X points to commit with SHA1 Y.
I'm not sure that it says anywhere in the documentation that it guarantees anything more than that, but I agree that a significant proportion of developers would intuitively expect that the entire content of the tree to be signed rather than just the SHA1.
> I'm not sure that it says anywhere in the documentation that it guarantees anything more than that, but I agree that a significant proportion of developers would intuitively expect that the entire content of the tree to be signed rather than just the SHA1.
I agree that they do assume that, but fail to see what connection that has to the actual workings of git. AFAIK the behaviour of software doesn't change in accordance with how developers think it works.
I'm no expert but as far as I understand, the signature would be valid as long as the hash stays the same. If the commit has been tampered with in such a way that the hash does not change, the signature would still appear valid.
> [A signed commit] doesn't guarantee anything about the contents of that commit if the repository has been tampered with.
I think most people would intuitively expect the signed commit to guarantee the contents of the tree being signed. The idea that you could "git pull" a repo from a compromised machine, verify the signed commit, but not actually have a guarantee about the tree matching the one that was signed would run counter to most people's expectations, I suspect.
In other words, this to me seems like a "technically, we don't guarantee" statement about something that is de facto thought to be guaranteed.