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