4 ms·

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

sureglymop 3y ago
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.
- Anunayj 3y ago
  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/ https://lwn.net/Articles/898522/
  - CuriousCosmic 3y ago
    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-83bb655829a7@zombino.com/t/#u 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.
- theamk 3y ago
  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 https://news.ycombinator.com/item?id=17825441
kevincox 3y ago
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.
kyrofa 3y ago
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.

sureglymop 3y ago

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.

Anunayj 3y ago
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/ https://lwn.net/Articles/898522/
- CuriousCosmic 3y ago
  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-83bb655829a7@zombino.com/t/#u 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.
theamk 3y ago
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 https://news.ycombinator.com/item?id=17825441

kevincox 3y ago

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.

kyrofa 3y ago

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.