Hacker News Reader

Comment by Vogtinator | Hacker News Reader

I treat "signed by GitHub's verified signature" equivalent to unsigned. It's not the author's signature, just some third party's.

View on HN

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.

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.

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.

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.

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.

Clicking on the badge shows a different message, however:

> This commit was signed with the committer's verified signature.

> This commit was created on GitHub.com and signed with GitHub's verified signature.

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.

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

One should treat git itself as insecure. When you sign a commit, the signature is based on the commit message and commit metadata including tree object_id and parent object_id. But if sha1 is used to generate commit hashes, one can theoretically forge a commit. This means that in an elaborate supply chain attack, one could spoof a commit with a valid signature. That signature would then still appear valid for the spoofed commit and probably make it seem more legitimate than it is.

For people who might be wondering why git hasn't moved to sha256 yet, here's a lwn article on it: https://lwn.net/Articles/898522/

For a more recent bit of info on it (I remembered this thread from the latter half of last year on the mailing list):

https://lore.kernel.org/git/2f5de416-04ba-c23d-1e0b-83bb6558...

The important snippet from this thread is:

> On 6/29/23 07:59, Junio C Hamano wrote:

> > Adam Majer <adamm@zombino.com> writes:

> > > Is sha256 still considered experimental or can it be assumed to be stable?

> > I do not think we would officially label SHA-256 support as "stable" until we have good interoperability with SHA-1 repositories, but the expectation is that we will make reasonable effort to keep migration path for the current SHA-256 repositories, even if it turns out that its on-disk format need to be updated, to keep the end-user data safe.

> That could be a different definition of stable. But I'm satisfied that current sha256 repositories will not end up incompatible with some future version of git without migration path (talking about on-disk format).

> So maybe my question should be reworded to "is sha256 still considered early stage, for testing purposes only with possible data-loss or can it be relied on for actual long lived repositories?"

> > So while "no-longer-experimental" patch is probably a bit premature, the warning in flashing red letters to caution against any use other than testing may want to be toned down.

> Agreed. I think it should be clear that SHA256 and SHA1 repositories cannot share data at this point. The scary wording should be removed though, as currently it sounds like "data loss incoming and it's your fault" if one chooses sha256

> - Adam

TLDR: SHA256 works well and can be considered "beta". It's viable but you can't really share data between a SHA1 and SHA256 repo. So if your repo doesn't need to merge to/from existing sha1 repos and you aren't dealing with subtrees or anything fancy like that, you should be able to use SHA256. It is not expected to break your repo, it's reasonably well supported, and in the event a migration needs to occur, there will be support for that as well.

So if you want to jump on the SHA256 train you absolutely can provided you are following a pretty normal/boring use case.

Note that while SHA1 itself is broken, git specifically has a code to detect attempts at collisions and prevent them, see all the sha1dc stuff [0]

[0] https://news.ycombinator.com/item?id=17825441

Yeah I've always found that to be frustrating. Someone squashes and merges MY commits, and github still shows them as validly signed, even though they aren't the commits I created. Sadly it's hard to actually filter those out: the UI makes them all look the same.

Reply on news.ycombinator.com