4 ms·

> 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

by 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.

by klabb3 3y ago

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.