-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sign commits with PGP #1047
Comments
I have reservations, but am open to the idea. If we do this, we should not allow the github key that it uses for squash-and-merge. Only developer keys. |
Let's express the pros and cons of each alternative:
I don't know if GH allows to have branch protection enabled per-contributor. If that was the case, we could have it enabled for you, @hallyn (and @ikerexxe if he wants it too) , since you often contribute from your job laptop. And I could have no branch protection, since I always carry my personal laptop, and would be able to use the key.
For sure; the github key would be basically saying that it was done via the github API, which adds no safety compared to the current status quo (which is a stronger guarantee that it was done via the GH API, and thus with valid GH credentials). |
Is this ticket still valid? If so, what are the consequences for the contributors, will their commits also have to be signed, or only the maintainers? |
There's no pressure, as we haven't been owned. :-) But I would still like to be able to sign my own commits, if it doesn't cause significant problems to you and @hallyn. So, it depends on that.
The signature of a commit is made by the committer, not by the author. Since contributors don't have committer rights, they don't need to sign anything. If branch protection can be enabled per user, I'd like to not have branch protection for myself, if you both agree. If branch protection must be enabled or disabled for the entire project, let's keep it, since Serge doesn't seem convinced. |
@alejandro-colomar well certainly nothing should stop you from signing your own commits, right? That shouldn't break anything for anyone. I'd like to say that we should encourage contributors to sign their commits. However, if someone manages to take over someone's github account so as to be able to post a PR from there, then they can just as well upload new gpg keys, so in a sense I guess it doesn't do much for us. |
I do sign them all. But since I cannot manually push, I need to push via github webUI. And then we have a rebase rule on GH, which obliterates my signatures. :-) If I could fast-forward my commits, they'd be signed. In fact, look at the latest PR you merged from me: All the commits in the PR are signed; yet the commits on master aren't signed. So, we need a way to
Agree.
Someone with GH credentials can upload new gpg keys, which would lie to GH. However, it wouldn't lie to your local keyring (unless you download that key blindly). Here's for example what I see in the 4.15.x branch:
(That's too noisy; I have some compact view:)
The To impersonate me properly, one would have to make you believe that new key is my new key. Please don't trust anyone claiming to say a new key is mine. If I ever get a new PGP key, be assured that it will be certified (not signed) with my current (master) key; and most likely, I'll also publish a revocation of the current master together with it. I have many backups of that master, so I don't think I'll ever lose the key (hopefully). |
See also: #1042
I propose signing all commits with PGP.
See git-commit(1):
Currently, the stable branches have all commits signed, since I push to them manually. However, since we apply PRs by rebasing them with the GH web UI, any signatures on the commits are discarded.
Having signatures on the commits would require that a malicious actor that wants to insert a commit in the master branch needs to have access to the PGP signing key of the impersonated author (or the bad commit would be easy to spot).
Cc: @ikerexxe , @hallyn , @thesamesam , @floppym
The text was updated successfully, but these errors were encountered: