Commit Signing with GPG or SMIME?
glennawatson opened this issue · comments
On the ReactiveUI project we been asking our maintainers to use ideally SMIME certificate signing with a X509 certificate, or GPG. Some of us have been using yubikeys.
This adds a extra layer of security for us since we can have extra confidence with the SMIME certificate especially that a real human is involved, and the private key in theory would only live on the local users PC so if a commit isn't signed and it's coming from a maintainer we will be immediately suspect.
Also if SMIME x509 certificate signing is done it'll allow external users to verify that at least some human has had their ID checked by the signing authority etc.
Wouldn't this be a good idea for the higher level tiers?
Does it limit external contributors?
For example coreclr/corefx/aspnet doesn't require signed commits from external contributors.
I suppose the question is can the difference between a merge commit (for PR) vs commit in PR be differentiated and enforced?
https://help.github.com/en/articles/about-required-commit-signing
So for us we just have maintainers/administrators override the signed commit requirement for non-maintainers.
Contributors on forks aren't required to have signed commits, only local branch commits.
These idea is aligned with the goals of level 4. I think it makes sense to add as a candidate that others can give feedback on. Alternatively, we could have an "optional best practices" section that maybe could inform a new level at a later date.
Agree, I like the idea of having recommended best practices and including this. It's still a little difficult to set up, and shouldn't be a blocker.
Side note: @glennawatson's GitSMimeSign is amazing, highly recommended.
I think one thing we should do for sure is:
- Ask that releases have corresponding annotated tags.
- Ask that those are signed tags.
How do you sign a tag? I use the GitHub Release task in pipelines, which creates the release and tags the source. It doesn't sign anything.
GitHub I believe bases it off the commit the tag is generated from.
Eg it will show verified if the commit is signed.
Okay, sure, I see it show verified based on the commit:
But tags in git are easily deleted and can be changed to a different commit, so I'm not sure what "signing the tag" accomplishes? All merge/squash commits from PR's from GitHub are effectively signed by GitHub anyway, so if everything is done from PR's, then wouldn't this always be true?
Well if you do merge pr you still have the commits from the other users that would ideally need to be signed.
Squash merges will be signed by GitHub if every commit inside the pr is verified.
I don't think we can enforce that commits from other users are signed, it's too high a bar for contributors. I think most maintainers are happy to get any reasonable PR, asking someone to sign their commits would discourage people.
Yep agreed hence why I would limit it just to maintainers.
I think that's also where Jon is probably right where we have a recommended best practices since having this as a requirement for all projects might not be feasible. I will open a separate issue today for a best practice repository.
Btw we been using forced signed commits for a little bit for rxui with success. External contributors fork off where signed commits aren't required then this only enforces it for users who have access to local branches sign which are the maintainers in our case. Does require someone with admin powers to merge external non signed commits though
How do you sign a tag? I use the GitHub Release task in pipelines, which creates the release and tags the source. It doesn't sign anything.
I can't talk to GitHub but in Git that's how you sign a tag:
$ git tag -s -m"tagging version 1.0" v1.
(it's the -s argument that does the signing)
The reason why you should sign tags is explained here:
The point of signing a tag is that now anyone who has your public key can prove that you have approved that particular commit as being that particular version of the program. If they happen to trust you as being the official source of releases for that package, then they know that they got an official version of that package, not some random version that might have been backdoored by an attacker or corrupted in transit.
Worth noting that Jon Galloway and some others have been using https://github.com/glennawatson/gitsmimesign