Feature Request: git verify-commit

[mohamedhafez]

It would be great if in our Gemfile when we specify a gem from a git source, if we could have an option to have bundler run git verify-commit <commit version> on the revision pulled in, as a safeguard against this type of exploit.

[simi]

@mohamedhafez hello, can you elaborate a little more how this should work? For example what about unverified commits? Feel free to open RFC (https://github.com/rubygems/rfcs) with more info added as well.

[mohamedhafez]

I was thinking when you have a line like

gem 'mygem', git: 'git@github.com:/whatever/mygem.git', branch: 'mybranch'

if you know that only certain people are responsible for publishing that gem, and you know they always sign their commits or releases with their GPG keys, and you have their public keys, then in that situation you could have the option add a verify_commit: true option to the end of that line. Then, any time the tip of mybranch fails git verify-commit <revision>, bundler would fail with an exit code. This would include when the tip of the branch is an unsigned commit, or a commit signed by an author for whom you don't have their public key in your gpg keyring. For example, I'd like to use this option on my company's forks of a couple gems.

This would add another optional layer of security to protect against things like Github breaches, or an unauthorized person in whatever way making what, from your perspective, is basically a release of that gem. Obviously this option would have to default to false since the situation I described isn't going to be the common case.

Sorry I didn't realize there was a separate RFC page, would you prefer that I move this discussion to there?

[simi]

@mohamedhafez I don't understand where to get all the info needed to verify the commits. Would you like to keep this responsibility on the client side as you mentioned (and you have their public keys)?

PS: Regarding GitHub breach - at that time it would be probably possible to do the same even with signed commits since attacker would be possible able to add also keys to another users due to that problem.

[mohamedhafez]

@simi, yes definitely keep the responsibility on the client side, as in they have added the author's public keys to their gpg keyring and trusted them. The client would be responsible for making git verify-commit pass for authors they wanted to accept. Bundler's only responsibility would be to run that command and nothing more.

In this case, we'd be safe in the case of a Github breach - even if the the attacker adds GPG keys to user's Github profile, they won't be in our server's gpg keyring, and thus anything signed by the attacker's keys or left unsigned will be rejected

[simi]

The client would be responsible for making git verify-commit pass for authors they wanted to accept. Bundler's only responsibility would be to run that command and nothing more.

Clear, maybe it can start as a plugin introducing new commang bundler git-verify. Feel free to take a look at https://bundler.io/guides/bundler_plugins.html.

In this case, we'd be safe in the case of a Github breach - even if the the attacker adds GPG keys to user's Github profile, they won't be in our server's gpg keyring, and thus anything signed by the attacker's keys or left unsigned will be rejected

Ahh, thanks for clarity. You're right.

[deivid-rodriguez]

I moving this to "Ideas" because I don't think there's something actionable for us yet. If there's a plugin out there that works fine and proves useful for people, then we can consider introducing it by default.