4 ms·

A lot of statements but with an important convoluted point: git signing happens with a public key that nobody knows how to verify properly. So should we sign th

by klabb3 3y ago

A lot of statements but with an important convoluted point: git signing happens with a public key that nobody knows how to verify properly. So should we sign them today, without being able to verify yet? Well, that isn’t 100% true. GitHub knows. But relying on GitHub is a good reason to not use the feature at all, imo. A bit stallmanesque perhaps? Maybe. I have absolutely no idea about your ssh keys, which goes back to decentralized self-sovereign identity being an unsolved problem (socially and administratively, not technically). Add commit signing to the giant list of use cases, I guess.

fmajid 3y ago
It’s not a GitHub feature, it’s a git one. The question is, how do you manage your web of trust in a distributed environment? Users set up the keys they trust for signatures using GitHub’s admin UI. GitHub exposes public keys via https://api.github.com/users/fazalmajid/keys https://api.github.com/users/fazalmajid/keys but it doesn’t tell you which keys are access and which are signing. There is also no way to see what the list was at a specific point in time, e.g. when the commit was signed. The second question is how do you ensure key revocation, which is a hard problem involving verified timestamps. If you are in a closed environment like proprietary software development you can and should build their own PKI, but in an open open-source workflow the author has a point, these last-mile issues make signed commits incomplete for trust purposes.
- klabb3 3y ago
  > It’s not a GitHub feature, it’s a git one. Yes, I know. That’s part of my answer. The point is that signing is a ritualistic useless dance if there’s nobody on the other side verifying that the signature belongs to someone (ie trusts it). > Users set up the keys they trust for signatures using GitHub’s admin UI. Yeah, that’s fine. But that’s between me and GitHub. > GitHub exposes public keys[…] Exactly. I agree with your points about security. But even so, it’s still a proprietary system relying on centralized identity. It ties projects to GitHub, and offloads trust to them. This is not git anymore - it’s the same as signing in with Yahoo or WeChat. It’s a way for Microsoft to put themselves on the critical path for virtually all today’s OSS dev. > If you are in a closed environment like proprietary software development you can and should build their own PKI I don’t know about this. Operate PKI? Maybe. Build? Aside from dedicated expert teams at mega-corps, no thanks. PKI is closely related to the decentralized identity problem - which is what I really hope we will solve. We really, really need it.
  - fmajid 3y ago
    My point is that even making calls to the GitHub API and archiving the results (signed by the fetcher, of course :-) can't produce an audit trail and artifacts you can use to reconstruct the commit signature validity history. Now if you merge a PR, it will be signed by the person who committed the merge (or rebase). Thus the problem is simpler than full-blown distributed PKI (at which point some salivating shill will of course trot out the blockchain as universal panacea). You need to ensure the signature keys of all committers (a much smaller problem than the universe of all possible contributors) and their timestamped history are known and kept somewhere in the repo. One solution would be to define a standardized file format similar to the SBOM standards CycloneDX or SPDX) to record this log (I suppose its generation and maintenance could be automated by a GitHub action), and signed by a comitter. This file can then be used to validate all the signatures even if GitHub falls off the face of the Earth. There is a bootstrap problem for how the many committers on a project trust each other, but that is handled by GitHub or whatever mechanism was used to convene the committers together in the first place.
seba_dos1 3y ago
I have a keyring of my teammates' public keys at work. I can verify whether their commits come from them with a single local command - and so can our CI. You can download my public key from my website and I can tell you in person or over any other channel you trust whether it's correct. At this point, you can verify all my commits with a single local command. Where does GitHub come into all this? I don't even use GitHub (unless contributing to a project that does).
- klabb3 3y ago
  That's really nice. What tools are you using? How do you manage adding and removing keys? How many people and devices are involved? > Where does GitHub come into all this? To maintain verification dynamically for team members. Maintaining lists are otherwise (and in your example, I think) a N^2 maintenance task. Everyone needs to update their pubkey list when a team member adds or removes a device.
  - seba_dos1 3y ago
    The tool where keys are stored is called "a git repo". If you need to update your local copy of the keyring, you pull it.

by klabb3 3y ago

fmajid 3y ago

It’s not a GitHub feature, it’s a git one. The question is, how do you manage your web of trust in a distributed environment? Users set up the keys they trust for signatures using GitHub’s admin UI. GitHub exposes public keys via https://api.github.com/users/fazalmajid/keys https://api.github.com/users/fazalmajid/keys but it doesn’t tell you which keys are access and which are signing. There is also no way to see what the list was at a specific point in time, e.g. when the commit was signed. The second question is how do you ensure key revocation, which is a hard problem involving verified timestamps. If you are in a closed environment like proprietary software development you can and should build their own PKI, but in an open open-source workflow the author has a point, these last-mile issues make signed commits incomplete for trust purposes.

klabb3 3y ago
> It’s not a GitHub feature, it’s a git one. Yes, I know. That’s part of my answer. The point is that signing is a ritualistic useless dance if there’s nobody on the other side verifying that the signature belongs to someone (ie trusts it). > Users set up the keys they trust for signatures using GitHub’s admin UI. Yeah, that’s fine. But that’s between me and GitHub. > GitHub exposes public keys[…] Exactly. I agree with your points about security. But even so, it’s still a proprietary system relying on centralized identity. It ties projects to GitHub, and offloads trust to them. This is not git anymore - it’s the same as signing in with Yahoo or WeChat. It’s a way for Microsoft to put themselves on the critical path for virtually all today’s OSS dev. > If you are in a closed environment like proprietary software development you can and should build their own PKI I don’t know about this. Operate PKI? Maybe. Build? Aside from dedicated expert teams at mega-corps, no thanks. PKI is closely related to the decentralized identity problem - which is what I really hope we will solve. We really, really need it.
- fmajid 3y ago
  My point is that even making calls to the GitHub API and archiving the results (signed by the fetcher, of course :-) can't produce an audit trail and artifacts you can use to reconstruct the commit signature validity history. Now if you merge a PR, it will be signed by the person who committed the merge (or rebase). Thus the problem is simpler than full-blown distributed PKI (at which point some salivating shill will of course trot out the blockchain as universal panacea). You need to ensure the signature keys of all committers (a much smaller problem than the universe of all possible contributors) and their timestamped history are known and kept somewhere in the repo. One solution would be to define a standardized file format similar to the SBOM standards CycloneDX or SPDX) to record this log (I suppose its generation and maintenance could be automated by a GitHub action), and signed by a comitter. This file can then be used to validate all the signatures even if GitHub falls off the face of the Earth. There is a bootstrap problem for how the many committers on a project trust each other, but that is handled by GitHub or whatever mechanism was used to convene the committers together in the first place.

seba_dos1 3y ago

I have a keyring of my teammates' public keys at work. I can verify whether their commits come from them with a single local command - and so can our CI. You can download my public key from my website and I can tell you in person or over any other channel you trust whether it's correct. At this point, you can verify all my commits with a single local command. Where does GitHub come into all this? I don't even use GitHub (unless contributing to a project that does).

klabb3 3y ago
That's really nice. What tools are you using? How do you manage adding and removing keys? How many people and devices are involved? > Where does GitHub come into all this? To maintain verification dynamically for team members. Maintaining lists are otherwise (and in your example, I think) a N^2 maintenance task. Everyone needs to update their pubkey list when a team member adds or removes a device.
- seba_dos1 3y ago
  The tool where keys are stored is called "a git repo". If you need to update your local copy of the keyring, you pull it.