DCO doesn't respect Verified status by GitHub
abitrolly opened this issue · 16 comments
Bug Report
Current Behavior
When editing docs from GitHub, the DCO creates unnecessary hassle by the need to checkout the PR and amend it with -s option. But GitHub already checked such commits and added Verified label to them.
DCO fails to validate them.
Expected behavior/code
DCO successfully detects verified commits and passes checks.
Thanks for opening this issue. A contributor should be by to give feedback soon. In the meantime, please check out the contributing guidelines and explore other ways you can get involved.
this seems like a reasonable request, but this repository is for the probot framework. there is a dedicated repository for DCO. it would be better to file this issue there
It is possible to move the issue but I have no perms.
It is possible to move the issue but I have no perms.
Done 👍🏼
I agree it's a reasonable request, happy to accept a PR with tests
The 'verified' indicator on github ensures the commit was signed with a GPG key. Signing your commit with a GPG key is not equivalent in most circles to agreeing to the DCO (in fact there was once a Probot app to enforce that alone! https://github.com/jarrodldavis/probot-gpg).
So please make sure the PR by default does not include this functionality and is opt-in only (by way of a config option in the .github/dco.yml)
GitHub
A GitHub App that enforces GPG signatures on pull requests (no longer maintained) - jarrodldavis/probot-gpg
Good to know thank you Bex!
Signing your commit with a GPG key is not equivalent in most circles to agreeing to the DCO.
Not sure how's that different from signing it with -s key. Those "most circles" can hardly serve as a reference.
@abitrolly note that @hiimbex built this app so they know a lot about the usage of DCO.
I don't see a reason not to implement it as opt-in, also given that this request didn't come up before in the past years as far as I know.
My apologizes for being mistrustful - in the past I had been bitten by a lawyer, and the disease is progressing since then. :D
No worries. Most of the guidance from this repo has come from the Linux Foundation who are heavy DCO users (and usually confer with their lawyers on these things - I am not a lawyer)
My understanding is that the DCO 'sign-off' serves as a very explicit agreement to this text: https://developercertificate.org/ and i'm not really sure GPG does the same? Probably @brianwarner could say more?
With the caveat that I'm not a lawyer and this isn't legal advice...
The current behavior is correct, because -s is about saying you have the rights to contribute the code, whereas -S is about proving who you are. The DCO is only about the first. Put differently, if I give you an apple and you ask if you can eat it, and I show you my passport in response, you would rightfully tell me I answered the wrong question. :-)
It's unfortunate that -s and -S use the same letter, because this is a common source of confusion. Now, of course, I think it's valid to say that -S enhances the DCO signoff, because not only are you making the DCO commitment you are also attesting to your identity. However, if you look to the kernel, where the DCO was developed, only the presence of the Signed-off-by line (whether written by hand, or added automatically using the -s flag) provides a valid signoff.
To summarize:
git commit -sautomatically adds theSigned-off-by: Your Name <your@email.com>line- Should always pass
git commit -Sdoes not add theSigned-off-by: Your Name <your@email.com>line, but signs the commit- Should never pass, but separately, others can verify it originated from you
git commit -Sand you manually typeSigned-off-by: Your Name <your@email.com>in the commit message- Should always pass, and separately, others can verify it originated from you
git commit -s -Sautomatically adds the signoff line and also signs the commit- Should always pass, and separately, others can verify it originated from you
Although nothing stops people from committing non-owned code either way, Even pasting it into GitHub edit form. What is important is that they've read about DCO and know what it is, so a simple checkbox on each PR should be sufficient. I think.
- I commit my own code
As for Linux kernel, I am not sure how a PR submitting interface looks like there.
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?