On Mon, Aug 10, 2015 at 11:44 PM, Matthias Maier <tam...@gentoo.org> wrote: >> That is, I was under the impression signing a tag only signs the >> references themselves, and then relies on SHA1 referential integrity >> beyond that. > > No, a signed tag verifies that the whole integrirty of the entire > repository, whereas a signed commit only authenticates the differences > introduced by a single commit. > > As long as there are no conflicts, a signed commit can be rebased > freely (especially also on top of malicious commits...). >
A signed commit and a signed tag are basically equivalent as far as authentication of the contents of the tree go. All a tag does is reference a commit by sha1, and a commit references the top level directory of the tree by sha1 in the state it was in when it was created. Sure, you can rebase a commit, but that doesn't actually change a commit. It creates one or more new commits in the place of a bunch of existing ones with new sha1s, and points the current head at the last one. If the old commits are no longer referenced by any other heads they will get garbage collected. If you point two heads at the same commit and do a rebase the history as seen by the other head won't change at all. Since a tag is just a label it is actually EASIER to tamper with than a commit. You can't change a commit without changing its hash. tags are referenced by name, not by hash, which is basically the whole point, so you CAN change the content of a tag and have it keep the same name. Of course, if you try to push/pull that new tag git is going to complain about the inconsistency, just as it does if you try to do a non-fast-forward push and so on. I don't think that having a bazillion tags or rewriting them constantly adds any security to the tree. What might add security for end-users is if git automatically checked the push signatures, which are the signatures that ensure that branches aren't tampered with (which is what rebasing you bring up actually does). -- Rich
