Stefan Beller <sbeller@xxxxxxxxxx> writes: > What is the difference between signed commits and tags? > (Not from a technical perspective, but for the end user) When you "commit -s", you are signing the bytes in the commit object, which means that you are attesting the fact that the tree you wanted to record is one of the 47 other colliding tree objects that happen to share that 40-hex hash value, and also the fact that the commits you wanted to record as its parents have certain SHA-1 hash values. As you are relying on the resistance to preimage attack against SHA-1 at least locally around that signed commit, there wouldn't be meaningful difference between a 50-commit series each of which is individually signed with "commit -s", such a 50-commit series, only the top of which is signed with "commit -s", and the same 50-commit series, on the top of which is signed with "tag -s". "tag -s" also has the benefit of being retroactive. You can create commit, think about it for a week and then later tag it. And ask others to also tag the same one. You cannot do so with "commit -s". > A signed push can certify that a given payload (consisting > of multiple commits on possibly multiple branches) was transmitted > to a remote, which can be recorded by the remote as e.g. a proof > of work. A signed push is _NOT_ about certifying the objects in the history DAG. It is about certifying the _intent_ of pointing _REFS_ into points in the object graph. "This is a commit I made to add feature frotz" is something you might say with "commit -s" and "these commits behind this point are for upcoming 2.13 release" is something you might say with "tag -s v2.13-rc0". But "I made it" and "I made it for this purpose" are different things. I may not want the "feature frotz" commit included in the maintenance track, so it would be a mistake for push a history that contains it to update refs/heads/maint ref. A push certificate can protect hosting sites like GitHub, when I complain to them saying "you guys are pointing at a wrong commit with refs/heads/maint", by allowing them to respond with "well, you made the push to perform that update and here is what you GPG signed". > Off list I was told gpg-signed commits are a "checkbox feature", > i.e. no real world workflow would actually use it. (That's a bold > statement, someone has to use it as there was enough interest > to implement it, no?) I'd agree with that "checkbox" description, except that you need to remember that a project can enforce _any_ workflow to its developer, even if it does not make much sense, and at that point, the workflow would become a real-world workflow. The word "real world workflow" does not make any assurance if that workflow is sensible. Historically, "tag -s" came a lot earlier. When a project for whatever reason wants signature for each and every commit so that they somehow can feel good, without "commit -s", it would have made us unnecessary work to scale tag namespace only because there will be tons of pointless tags. "commit -s" was a remedy for that.