3 ms·

> I don't validate an entire codebase every time I commit. Linus' point is that you don't need to validate the entire code base, if you have one signed commit

by hdhzy 9y ago

> I don't validate an entire codebase every time I commit. Linus' point is that you don't need to validate the entire code base, if you have one signed commit then everything that is "below" is also (implicitly) signed. For example you can have a feature branch that has many small commits and one merge commit that joins feature branch with master and you just need to sign the merge commit to make sure all of these small commits are OK.

CaliforniaKarl 9y ago
In our group's use case, we're not after the "implicitly-signed" property. We are trying to ensure that the person who is listed as doing the commit actually did the commit. We then have a server-side hook script, which ensures each new commit has been signed by a key kept in a local keyring.
- hdhzy 9y ago
  Just out of curiosity do you somehow update the local keyring? So that one can update their key information (for example to add revocations and new keys).
  - CaliforniaKarl 9y ago
    There's a single-digit number of people who can update the local keyring. Which works right now, given that the number of people who push to the repos concerned is in the double-digit range. Our PGP keys don't really change that often.
stouset 9y ago
> Linus' point is that you don't need to validate the entire code base, if you have one signed commit then everything that is "below" is also (implicitly) signed. And Linus is missing the point entirely. Yes, signing a commit implicitly signs the repo all the way back to its beginning. But when I'm actually performing the action of signing this commit, I am not actually going back through every commit and verifying them. The fact that you can use the properties of commit hashes to verify a chain all the way back to the origin of the repo is irrelevant, because that's not what someone actually signing a commit is intending or should be expected to do. 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.
- amazingman 9y ago
  >> For example you can have a feature branch that has many small commits and one merge commit that joins feature branch with master and you just need to sign the merge commit to make sure all of these small commits are OK. The above example still makes sense, even given your point about the mild absurdity of the idea that the entire repo is implicitly trusted.
  - stouset 9y ago
    While this is technically true, what's the point in making the whole thing more complicated? Say you relax the restrictions such that only the first parent of every commit must be signed. While this might make sense for a small branch edited by one person, what if it was a long-lived branch modified by multiple people? The only case I can see for such a system is if you're doing a pull-request based workflow where your code review tool (GHE, Bitbucket, whatever) is the only tool capable of updating `master` and produces signed merge commits whenever a branch passes code review. Then you can at least (in theory) attest that all commits to master have been reviewed. But if not that, and people are signing their commits to master anyway (which you can automate in your `~/.gitconfig`, why allow exemptions to commits on branches?
- 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...

by hdhzy 9y ago

CaliforniaKarl 9y ago

In our group's use case, we're not after the "implicitly-signed" property. We are trying to ensure that the person who is listed as doing the commit actually did the commit. We then have a server-side hook script, which ensures each new commit has been signed by a key kept in a local keyring.

hdhzy 9y ago
Just out of curiosity do you somehow update the local keyring? So that one can update their key information (for example to add revocations and new keys).
- CaliforniaKarl 9y ago
  There's a single-digit number of people who can update the local keyring. Which works right now, given that the number of people who push to the repos concerned is in the double-digit range. Our PGP keys don't really change that often.

stouset 9y ago

> Linus' point is that you don't need to validate the entire code base, if you have one signed commit then everything that is "below" is also (implicitly) signed. And Linus is missing the point entirely. Yes, signing a commit implicitly signs the repo all the way back to its beginning. But when I'm actually performing the action of signing this commit, I am not actually going back through every commit and verifying them. The fact that you can use the properties of commit hashes to verify a chain all the way back to the origin of the repo is irrelevant, because that's not what someone actually signing a commit is intending or should be expected to do. 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.

amazingman 9y ago
>> For example you can have a feature branch that has many small commits and one merge commit that joins feature branch with master and you just need to sign the merge commit to make sure all of these small commits are OK. The above example still makes sense, even given your point about the mild absurdity of the idea that the entire repo is implicitly trusted.
- stouset 9y ago
  While this is technically true, what's the point in making the whole thing more complicated? Say you relax the restrictions such that only the first parent of every commit must be signed. While this might make sense for a small branch edited by one person, what if it was a long-lived branch modified by multiple people? The only case I can see for such a system is if you're doing a pull-request based workflow where your code review tool (GHE, Bitbucket, whatever) is the only tool capable of updating `master` and produces signed merge commits whenever a branch passes code review. Then you can at least (in theory) attest that all commits to master have been reviewed. But if not that, and people are signing their commits to master anyway (which you can automate in your `~/.gitconfig`, why allow exemptions to commits on branches?
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...