4 ms·

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

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?
TheDong 4y ago
Let me ask a few questions about this scheme: 1. What happens when someone needs to resolve a merge conflict involving your commit? Let's say I maintain a fork of an open source repo to add some feature, and I periodically merge back in upstream changes... that necessarily involves resolving conflicts. By default, git retains author ownership, and now the commit is unsigned, but it's really your work. What do we do? Do I have to use a custom merge flow that also rewrites authorship from "Alice <alice@gmail.com>" to "Alice <alice@gmail.com.fake.unsigned.suffix>"? 2. What happens if your gpg key is compromised or expires? Are all your previous repos now invalid? I can't fork it because it contains a commit authored by you, but with a revoked or expired gpg key? 3. What happens to previous commits if I enable this feature? Can all my unsigned commits no longer be pushed to github? I made a commit in a project at work 5 years ago with my email, but didn't sign it.. if that company wants to open source that project on github, do they now have to rewrite history to change the author on my unsigned commits? 4. What does the "squash merge" button on github PRs do for your PRs?
- eurasiantiger 4y ago
  And now we’re on the fast track to adopt a blockchain as a tamper evident mechanism.
  - jhugo 4y ago
    git is effectively a blockchain. Trying to use a blockchain for this has many of the same problems as described in GP's comment.
    - deleted 4y ago
      [deleted]
    - 3np 4y ago
      A blockchain could be useful for proving a commit was not done significantly before or after the claimed timestamp, and (depending on how you do it) non-repudiation. IMO I don't see how this is desirable enough to be worth it. Wider adoption of GPG signatures would be much more impactful. It could make sense to use a blockchain for key distribution/key discovery/revocation, effectively as a replacement of PKI, though.
pilif 4y ago
They have something under Settings > SSH and GPG keys where you can enable Vigilant mode. While that still allows pushing unsigned commits, it will flag them with a warning batch. I had this on for a while, but unfortunately as some open source projects tend to rebase commits before pushing them, this was causing warnings to be shown (as the rebase breaks my signature), so I turned it off again as to not scare people when looking at the commit history of a project and seeing warnings after my contributions were merged in.
- stevelacy 4y ago
  Good to know, I was not aware. The squash/rebase issue is definitely problematic, though a tree of signatures could be appended to each commit. Now... this does break how commits are currently signed.
  - eurasiantiger 4y ago
    Would this be a problem if commits were stored in a blockchain? Rebase would effectively fork the chain.
    - pilif 4y ago
      a git repo is practically a blockchain. Fixing this will require how git treats signatures, but no additional parallel architecture needs to be created.
denismi 4y ago
I lost a Yubikey, so I revoked the subkeys on it. Github didn't let me update the existing pubkey, so I had to remove and re-enter it. Now all things signed by the revoked key, despite being before the revoke date, come up as unverified. I'm not sure if it's a me issue or a PGP issue or a GitHub issue, but it's a pretty broken system.

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?

TheDong 4y ago

Let me ask a few questions about this scheme: 1. What happens when someone needs to resolve a merge conflict involving your commit? Let's say I maintain a fork of an open source repo to add some feature, and I periodically merge back in upstream changes... that necessarily involves resolving conflicts. By default, git retains author ownership, and now the commit is unsigned, but it's really your work. What do we do? Do I have to use a custom merge flow that also rewrites authorship from "Alice <alice@gmail.com>" to "Alice <alice@gmail.com.fake.unsigned.suffix>"? 2. What happens if your gpg key is compromised or expires? Are all your previous repos now invalid? I can't fork it because it contains a commit authored by you, but with a revoked or expired gpg key? 3. What happens to previous commits if I enable this feature? Can all my unsigned commits no longer be pushed to github? I made a commit in a project at work 5 years ago with my email, but didn't sign it.. if that company wants to open source that project on github, do they now have to rewrite history to change the author on my unsigned commits? 4. What does the "squash merge" button on github PRs do for your PRs?

eurasiantiger 4y ago
And now we’re on the fast track to adopt a blockchain as a tamper evident mechanism.
- jhugo 4y ago
  git is effectively a blockchain. Trying to use a blockchain for this has many of the same problems as described in GP's comment.
  - deleted 4y ago
    [deleted]
  - 3np 4y ago
    A blockchain could be useful for proving a commit was not done significantly before or after the claimed timestamp, and (depending on how you do it) non-repudiation. IMO I don't see how this is desirable enough to be worth it. Wider adoption of GPG signatures would be much more impactful. It could make sense to use a blockchain for key distribution/key discovery/revocation, effectively as a replacement of PKI, though.

pilif 4y ago

They have something under Settings > SSH and GPG keys where you can enable Vigilant mode. While that still allows pushing unsigned commits, it will flag them with a warning batch. I had this on for a while, but unfortunately as some open source projects tend to rebase commits before pushing them, this was causing warnings to be shown (as the rebase breaks my signature), so I turned it off again as to not scare people when looking at the commit history of a project and seeing warnings after my contributions were merged in.

stevelacy 4y ago
Good to know, I was not aware. The squash/rebase issue is definitely problematic, though a tree of signatures could be appended to each commit. Now... this does break how commits are currently signed.
- eurasiantiger 4y ago
  Would this be a problem if commits were stored in a blockchain? Rebase would effectively fork the chain.
  - pilif 4y ago
    a git repo is practically a blockchain. Fixing this will require how git treats signatures, but no additional parallel architecture needs to be created.

denismi 4y ago

I lost a Yubikey, so I revoked the subkeys on it. Github didn't let me update the existing pubkey, so I had to remove and re-enter it. Now all things signed by the revoked key, despite being before the revoke date, come up as unverified. I'm not sure if it's a me issue or a PGP issue or a GitHub issue, but it's a pretty broken system.