5 ms·

This is that thing where people can put anyone in as the commit author, thus impersonating the original creator right? Seems like the solution is "don't just c

This is that thing where people can put anyone in as the commit author, thus impersonating the original creator right? Seems like the solution is "don't just copy random github urls into your code" ?

macintux 4y ago
This is also a problem for enterprises. I’ve seen commits from root, ec2-user, etc: GitHub knows who’s pushing a commit even if git doesn’t, and it’s maddening that at least for enterprise accounts they don’t carry that identity into the metadata.
- iforgotpassword 4y ago
  That would change the commit hash, at least if you want it to survive a clone of the repo. Of you'd store it externally so that it would only be able to be shown in the webui then it's of limited use, but maybe better than nothing.
  - xrisk 4y ago
    I feel the commit data could be extended to include some metadata that isn’t used to compute the hash. GitHub could then make use of this data to populate whatever. (Not sure if such a field already exists in the commit blob)
    - Karellen 4y ago
      > I feel the commit data could be extended to include some metadata that isn’t used to compute the hash. That's not how git works.
      - xrisk 4y ago
        I’m somewhat familiar with how git works. In my understanding, a commit is just a blob combining the commit information and a tree blob, hashing them together to create a commit id. This design doesn’t preclude the usage of additional information in the commit blob that isn’t used to compute the hash. (Think for example how file access times do not affect its hash)
        formerly_proven 4y ago
        Git is a content-addressed object store, the address of any stored object is the hash of the object itself. So you actually can't stuff extra data into an object and not change its ID; this auxiliary data would need to go in a separate store indexed by object ID or a similar solution. The reason why file access times don't affect git hashes is because git does not store them.
        Karellen 4y ago
        If it's not part of the information that's hashed to create the commit id, it's not part of the commit. By definition.
    - jwilk 4y ago
      I think you want git-notes (or something similar): https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes "Adds, removes, or reads notes attached to objects, without touching the objects themselves."
  - macintux 4y ago
    Specifically it could be exposed through the GitHub REST API without impacting the commit itself.
stevelacy 4y ago
Correct. My suggestion for a solution is for github to add a "reject-unsigned" feature. Only allow commits signed by <my gpg key> and <my email> to be pushed to github, under any projects/org.
- szundi 4y ago
  I like it, although raises the bar for contributors to join. Also does not help that enough percentage of repo owners would accept then signed PRs to their projects. The fake accounts can be created with gpg signed fake commits too.
- irjustin 4y ago
  How does this solution solve the problem? You're just adding an extra step that's hardly going to stop someone.
  - stevelacy 4y ago
    It would only allow commits signed by me to be pushed under my email. Github uses the email as the "proof" of commit ownership. By only accepting signed commits a user would not be able to push a commit impersonating me.
    - irjustin 4y ago
      That solves impersonation, but that is not a related problem here. These repos were not taken over but cloned and made to look like another repo via similar naming. I think what you're looking for is more "all accounts must be verified via payment/identity" then you really know who is making "random clones" and "look-a-likes" w/ malware. But you've got a whole host of other problems in the process.
- bonzini 4y ago
  How would that work for past commits? Would people be forbidden to mirror a project to git just because it contains an unsigned commit of mine from 2007?
- 4y ago
jollybean 4y ago
What is the difference between a 'random' and 'non random' repo? The whole point of 'Open Source' is that we can use code which might otherwise be a bit 'random'. It's not 'Institutionalized Open Source' it's just 'Open Source' i.e. we're not all Torvalds. So, credibility etc. is a very fickle thing otherwise, this is a serious security issue and we really don't have answers. We used to think about code as 'logic that works' but now we have other criteria, I wonder if our FOSS models need to adapt bit.
- drekipus 4y ago
  It's a good point actually. I suppose the message is "read the code you're using" but that is hard for big libraries and frameworks. Obviously using one's code where they are impersonating someone else is a big red flag.
  - jollybean 4y ago
    Reading the code for functional integrity is already a big deal, but having to sleuth around for the sneacky hacks? No way. I don't know what the answer is, but the model has to be changed.

This is that thing where people can put anyone in as the commit author, thus impersonating the original creator right? Seems like the solution is "don't just copy random github urls into your code" ?

macintux 4y ago

This is also a problem for enterprises. I’ve seen commits from root, ec2-user, etc: GitHub knows who’s pushing a commit even if git doesn’t, and it’s maddening that at least for enterprise accounts they don’t carry that identity into the metadata.

iforgotpassword 4y ago
That would change the commit hash, at least if you want it to survive a clone of the repo. Of you'd store it externally so that it would only be able to be shown in the webui then it's of limited use, but maybe better than nothing.
- xrisk 4y ago
  I feel the commit data could be extended to include some metadata that isn’t used to compute the hash. GitHub could then make use of this data to populate whatever. (Not sure if such a field already exists in the commit blob)
  - Karellen 4y ago
    > I feel the commit data could be extended to include some metadata that isn’t used to compute the hash. That's not how git works.
    - xrisk 4y ago
      I’m somewhat familiar with how git works. In my understanding, a commit is just a blob combining the commit information and a tree blob, hashing them together to create a commit id. This design doesn’t preclude the usage of additional information in the commit blob that isn’t used to compute the hash. (Think for example how file access times do not affect its hash)
      - formerly_proven 4y ago
        Git is a content-addressed object store, the address of any stored object is the hash of the object itself. So you actually can't stuff extra data into an object and not change its ID; this auxiliary data would need to go in a separate store indexed by object ID or a similar solution. The reason why file access times don't affect git hashes is because git does not store them.
      - Karellen 4y ago
        If it's not part of the information that's hashed to create the commit id, it's not part of the commit. By definition.
  - jwilk 4y ago
    I think you want git-notes (or something similar): https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes "Adds, removes, or reads notes attached to objects, without touching the objects themselves."
- macintux 4y ago
  Specifically it could be exposed through the GitHub REST API without impacting the commit itself.

stevelacy 4y ago

Correct. My suggestion for a solution is for github to add a "reject-unsigned" feature. Only allow commits signed by <my gpg key> and <my email> to be pushed to github, under any projects/org.

szundi 4y ago
I like it, although raises the bar for contributors to join. Also does not help that enough percentage of repo owners would accept then signed PRs to their projects. The fake accounts can be created with gpg signed fake commits too.
irjustin 4y ago
How does this solution solve the problem? You're just adding an extra step that's hardly going to stop someone.
- stevelacy 4y ago
  It would only allow commits signed by me to be pushed under my email. Github uses the email as the "proof" of commit ownership. By only accepting signed commits a user would not be able to push a commit impersonating me.
  - irjustin 4y ago
    That solves impersonation, but that is not a related problem here. These repos were not taken over but cloned and made to look like another repo via similar naming. I think what you're looking for is more "all accounts must be verified via payment/identity" then you really know who is making "random clones" and "look-a-likes" w/ malware. But you've got a whole host of other problems in the process.
bonzini 4y ago
How would that work for past commits? Would people be forbidden to mirror a project to git just because it contains an unsigned commit of mine from 2007?
4y ago

jollybean 4y ago

What is the difference between a 'random' and 'non random' repo? The whole point of 'Open Source' is that we can use code which might otherwise be a bit 'random'. It's not 'Institutionalized Open Source' it's just 'Open Source' i.e. we're not all Torvalds. So, credibility etc. is a very fickle thing otherwise, this is a serious security issue and we really don't have answers. We used to think about code as 'logic that works' but now we have other criteria, I wonder if our FOSS models need to adapt bit.

drekipus 4y ago
It's a good point actually. I suppose the message is "read the code you're using" but that is hard for big libraries and frameworks. Obviously using one's code where they are impersonating someone else is a big red flag.
- jollybean 4y ago
  Reading the code for functional integrity is already a big deal, but having to sleuth around for the sneacky hacks? No way. I don't know what the answer is, but the model has to be changed.