3 ms·

> When I'm signing a commit, I'm vouching that I am responsible for applying this set of changes to a given state of a repo. It says nothing about my belief in

by hdhzy 9y ago

> When I'm signing a commit, I'm vouching that I am responsible for applying this set of changes to a given state of a repo. It says nothing about my belief in the validity of changes to the repo made before it. Then you should be signing a diff not a commit. Signing a commit represents something different, because commit references both the current tree (all files) and parent commit you're basically vouching for all history and all files. For reference, git commit structure [0]: $ git cat-file -p ca82a6dff817ec66f44342007202690a93763949 tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 author Scott Chacon <schacon@gmail.com> 1205815931 -0700 committer Scott Chacon <schacon@gmail.com> 1240030591 -0700 changed the version number [0]: https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protocols https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protoc...

Sean1708 9y ago
How do you just a diff in git?
- hdhzy 9y ago
  That's workflow similar to what Linux Kernel uses: http://www.vflare.org/2009/09/linux-kernel-workflow-with-git.html http://www.vflare.org/2009/09/linux-kernel-workflow-with-git...
Ajedi32 9y ago
That's ridiculous. If I signed a statement saying "The file with this hash is malware: <hash here>" would you say that "you're basically vouching for that file" just because my statement contained the file's hash? Similarly, if I sign a commit containing `parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7`, that says nothing about whether I consider all previous commits to be valid. It only says that the commit I just signed was created based off of that parent commit, and that in order to see the changes I actually made you'll need to diff against that parent. (Which `git show <my commit id>` will do automatically.)
- hdhzy 9y ago
  I think I used the word vouch incorrectly. When you sign a commit you indicate that your changes can be applied only on that particular parent even if all files or diffs were bit for bit identical. If it didn't work like that someone could take your work and place it in a completely different project and claim it was signed by you. Note that even with signed commits there are same gaps in the system. For example without signed pushes someone can take your signed commit from branch "test" an push it to "master".
stouset 9y ago
Signing a diff by itself is useless, because there's no attestation to what exactly is being diffed. Just because a signing a commit can be construed as the author attesting to the authenticity of every single bit in the a repo's entire commit history doesn't mean it should, doesn't mean it's what the signing party actually intended, and doesn't mean that such an inference even remotely sane. Such an expectation is utterly absurd on its face for any repo with more than a handful of commits and/or authors. Further, git does not have a mechanism for signing either diffs or diffs plus the `tree` of the prior commit plus all of the other commit metadata. Even if it did, there's now the problem that by excluding the prior commit, you now have no way of ensuring that signed commits are properly ordered if they happen to share `tree`s (e.g., in the case of a revert). This is a patently terrible property from a cryptographic perspective. Given the above, there is literally no native way in git to achieve the semantics of signing a singular diff. Combined with the complete absurdity of assuming a signed commit is attesting to tens of thousands of commits or more from dozens of authors or more preceding it, signing commits is the most natural way to express the useful semantic of "I made this change to this tree". The semantics you suggest are totally unrealistic and virtually useless in practice, so what exactly is the point of your argument?

by hdhzy 9y ago

Sean1708 9y ago

How do you just a diff in git?

hdhzy 9y ago
That's workflow similar to what Linux Kernel uses: http://www.vflare.org/2009/09/linux-kernel-workflow-with-git.html http://www.vflare.org/2009/09/linux-kernel-workflow-with-git...

Ajedi32 9y ago

That's ridiculous. If I signed a statement saying "The file with this hash is malware: <hash here>" would you say that "you're basically vouching for that file" just because my statement contained the file's hash? Similarly, if I sign a commit containing `parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7`, that says nothing about whether I consider all previous commits to be valid. It only says that the commit I just signed was created based off of that parent commit, and that in order to see the changes I actually made you'll need to diff against that parent. (Which `git show <my commit id>` will do automatically.)

hdhzy 9y ago
I think I used the word vouch incorrectly. When you sign a commit you indicate that your changes can be applied only on that particular parent even if all files or diffs were bit for bit identical. If it didn't work like that someone could take your work and place it in a completely different project and claim it was signed by you. Note that even with signed commits there are same gaps in the system. For example without signed pushes someone can take your signed commit from branch "test" an push it to "master".

stouset 9y ago

Signing a diff by itself is useless, because there's no attestation to what exactly is being diffed. Just because a signing a commit can be construed as the author attesting to the authenticity of every single bit in the a repo's entire commit history doesn't mean it should, doesn't mean it's what the signing party actually intended, and doesn't mean that such an inference even remotely sane. Such an expectation is utterly absurd on its face for any repo with more than a handful of commits and/or authors. Further, git does not have a mechanism for signing either diffs or diffs plus the `tree` of the prior commit plus all of the other commit metadata. Even if it did, there's now the problem that by excluding the prior commit, you now have no way of ensuring that signed commits are properly ordered if they happen to share `tree`s (e.g., in the case of a revert). This is a patently terrible property from a cryptographic perspective. Given the above, there is literally no native way in git to achieve the semantics of signing a singular diff. Combined with the complete absurdity of assuming a signed commit is attesting to tens of thousands of commits or more from dozens of authors or more preceding it, signing commits is the most natural way to express the useful semantic of "I made this change to this tree". The semantics you suggest are totally unrealistic and virtually useless in practice, so what exactly is the point of your argument?