Re:Welp, there go my Git signatures
by stouset on Wednesday October 25, 2017 @03:08PM
(#15553146)
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?
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?