4 ms·

I think it adds value. It means that the commit was created using the author's credentials (to the extent that you trust GitHub and its lack of bugs). So the au

I think it adds value. It means that the commit was created using the author's credentials (to the extent that you trust GitHub and its lack of bugs). So the author can be trusted to some extent on these commits. Although extending this signing ability to arbitrary commits via the codespaces API seems weird as the commit is no longer generated by GitHub. It seems now that you could generate some fake merge that changed data in a surprising way. Previously you knew that merges generated by GitHub would be "clean". Not that this changes much in practice.

cryptonector 3y ago
In particular it means "this was committed via the GitHub Web UI" and "the author was authenticated to GitHub". But the latter part is not really any different from who pushed the commit. And clearly there is no value in this as long as GitHub doesn't make this feature more secure. Using regexp to parse the author line then ignoring author lines that don't match... yikes.
- kevincox 3y ago
  But how do you know who pushed a given commit? I don't think it is recorded in the Git repository. I agree that "to the extent that you trust GitHub and its lack of bugs" is a big caveat. But it sill seems better to have this information than not to have it.
  - cryptonector 3y ago
    Who pushed the commit, IIRC, is metadata that's not on the Merkle hash tree -- it can't be on the Merkle hash tree without there being a commit for the push of the other commit, since anyone can push, but an authored commit is immutable.
- semiquaver 3y ago
  The badge is also displayed if the commit was signed locally by a GPG key whose public component is uploaded to GitHub by the the claimed author and committer.
  - the456gamer 3y ago
    Clicking on the badge shows a different message, however: > This commit was signed with the committer's verified signature. vs > This commit was created on GitHub.com and signed with GitHub's verified signature.
- orblivion 3y ago
  I realized there is one benefit that this offers: Github attests to the time that it happened. Supposing you're looking at a popular repository, one where a malicious commit would likely be noticed eventually. The last commit was "one month ago". What's to say someone didn't compromise the developer's computer, sign a malicious commit backdated by a month, and push it to Github? If the last commit was made via the Github UI, you have pretty good assurance (i.e. as much as you trust Github not to get hacked) that this didn't happen. Even better if the previous commit was done by the author, and the Github UI commit is trivially confirmed as safe. That way, you can confirm the author's commit locally, in case Github is the one that got hacked. If both the author and Github got hacked, :shrug: I guess that's a pretty skilled adversary. Caveat: All of the above is my own analysis. I'm curious if there are flaws in my thinking here.
kyrofa 3y ago
> It means that the commit was created using the author's credentials (to the extent that you trust GitHub and its lack of bugs). This is incorrect. If I create a merge request, and then the maintainer clicks the "squash and merge" button, that commit is associated with me, even though I'm not actually the creator of that commit at that point: the maintainer is. I believe this happens even if someone else (e.g. the maintainer) pushed commits to that merge request before squashing them together.

cryptonector 3y ago

In particular it means "this was committed via the GitHub Web UI" and "the author was authenticated to GitHub". But the latter part is not really any different from who pushed the commit. And clearly there is no value in this as long as GitHub doesn't make this feature more secure. Using regexp to parse the author line then ignoring author lines that don't match... yikes.

kevincox 3y ago
But how do you know who pushed a given commit? I don't think it is recorded in the Git repository. I agree that "to the extent that you trust GitHub and its lack of bugs" is a big caveat. But it sill seems better to have this information than not to have it.
- cryptonector 3y ago
  Who pushed the commit, IIRC, is metadata that's not on the Merkle hash tree -- it can't be on the Merkle hash tree without there being a commit for the push of the other commit, since anyone can push, but an authored commit is immutable.
semiquaver 3y ago
The badge is also displayed if the commit was signed locally by a GPG key whose public component is uploaded to GitHub by the the claimed author and committer.
- the456gamer 3y ago
  Clicking on the badge shows a different message, however: > This commit was signed with the committer's verified signature. vs > This commit was created on GitHub.com and signed with GitHub's verified signature.
orblivion 3y ago
I realized there is one benefit that this offers: Github attests to the time that it happened. Supposing you're looking at a popular repository, one where a malicious commit would likely be noticed eventually. The last commit was "one month ago". What's to say someone didn't compromise the developer's computer, sign a malicious commit backdated by a month, and push it to Github? If the last commit was made via the Github UI, you have pretty good assurance (i.e. as much as you trust Github not to get hacked) that this didn't happen. Even better if the previous commit was done by the author, and the Github UI commit is trivially confirmed as safe. That way, you can confirm the author's commit locally, in case Github is the one that got hacked. If both the author and Github got hacked, :shrug: I guess that's a pretty skilled adversary. Caveat: All of the above is my own analysis. I'm curious if there are flaws in my thinking here.

kyrofa 3y ago

> It means that the commit was created using the author's credentials (to the extent that you trust GitHub and its lack of bugs). This is incorrect. If I create a merge request, and then the maintainer clicks the "squash and merge" button, that commit is associated with me, even though I'm not actually the creator of that commit at that point: the maintainer is. I believe this happens even if someone else (e.g. the maintainer) pushed commits to that merge request before squashing them together.