Observation
The app currently accepts a Signed-off-by: trailer using a GitHub @users.noreply.github.com address.
On the ordinary pull request path, index.js loads pull request commits and passes them to getDCOStatus() (index.js lines 52-63). If getDCOStatus() returns no failures, the check reports success (index.js lines 89-95).
In lib/dco.js, the explicit sign-off parser accepts any Signed-off-by: Name <email> trailer (lib/dco.js lines 125-133). The only email validation is email-validator syntax validation of the commit author/committer email (lib/dco.js lines 4 and 51-56). Identity matching then lower-cases the commit author/committer names and emails (lib/dco.js lines 59-66) and requires the sign-off name and email to match one of those values (lib/dco.js lines 72-79 for one sign-off, and lines 82-95 for multiple sign-offs).
I did not find any handling of users.noreply.github.com, noreply, or anonymity/pseudonymity checks in lib/ or index.js.
The practical result is that a commit authored as:
Some Name <12345+login@users.noreply.github.com>
with a matching trailer:
Signed-off-by: Some Name <12345+login@users.noreply.github.com>
passes today.
Why it matters
The DCO is a certification of origin. The DCO 1.1 legal text itself does not contain a no-pseudonyms sentence, but the Linux kernel guidance that presents the DCO in Documentation/process/submitting-patches.rst says to sign off using a known identity (sorry, no anonymous contributions.).
As commonly applied, the sign-off is meant to record a real, attributable identity. A <id>+<login>@users.noreply.github.com address is a GitHub-provided noreply address tied to an account rather than a directly contactable personal or work mailbox, so a sign-off using it arguably does not carry the attribution the DCO is meant to provide.
How this surfaced
This came up while investigating #311, where DCO was failing in merge queues.
The connection is specific: GitHub's merge queue builds a new commit whose author identity comes from the GitHub account. If that account has email privacy enabled, the merge queue commit author can be the account's pseudonymous noreply address.
A real example from servo/servo is merge queue commit 1ed1def72fa6d08b11ba7041c8eebb3e8c501b35, whose author is:
amittenak47 <55721729+amittenak47@users.noreply.github.com>
while the carried-over trailer is:
Signed-off-by: Amit Anilkumar <aanilkumar30@gatech.edu>
Under today's behavior, the only way such a contributor passes the merge queue check is to sign off as the anonymous noreply address. In other words, the current behavior actively pushes contributors toward anonymized sign-offs in that path.
PR #313 addresses that specific inversion by evaluating the pull request's own commits, which carry the real git identity. This issue is the separate, pre-existing question of whether noreply sign-offs should be accepted at all on the ordinary pull request path.
This would be a breaking policy change
Many contributors legitimately use noreply addresses today, often because their employer or their own privacy preference requires it. Rejecting them would newly fail pull requests that currently pass, and because checks can be re-run, it could also flip previously-green pull requests to red.
Any change here needs a deliberate rollout decision, not a silent tightening.
Options to consider
- Leave as-is and document explicitly that noreply sign-offs are accepted.
- Add an opt-in
dco.yml configuration flag, default OFF to preserve current behavior, allowing a repository to require non-noreply addresses.
- Reject noreply sign-offs unconditionally. This is the most disruptive option.
- Accept noreply sign-offs but surface an advisory note in the check output without failing.
No code change is proposed yet. This needs a maintainer policy decision first.
Observation
The app currently accepts a
Signed-off-by:trailer using a GitHub@users.noreply.github.comaddress.On the ordinary pull request path,
index.jsloads pull request commits and passes them togetDCOStatus()(index.jslines 52-63). IfgetDCOStatus()returns no failures, the check reports success (index.jslines 89-95).In
lib/dco.js, the explicit sign-off parser accepts anySigned-off-by: Name <email>trailer (lib/dco.jslines 125-133). The only email validation isemail-validatorsyntax validation of the commit author/committer email (lib/dco.jslines 4 and 51-56). Identity matching then lower-cases the commit author/committer names and emails (lib/dco.jslines 59-66) and requires the sign-off name and email to match one of those values (lib/dco.jslines 72-79 for one sign-off, and lines 82-95 for multiple sign-offs).I did not find any handling of
users.noreply.github.com,noreply, or anonymity/pseudonymity checks inlib/orindex.js.The practical result is that a commit authored as:
with a matching trailer:
passes today.
Why it matters
The DCO is a certification of origin. The DCO 1.1 legal text itself does not contain a no-pseudonyms sentence, but the Linux kernel guidance that presents the DCO in
Documentation/process/submitting-patches.rstsays to sign off using aknown identity (sorry, no anonymous contributions.).As commonly applied, the sign-off is meant to record a real, attributable identity. A
<id>+<login>@users.noreply.github.comaddress is a GitHub-provided noreply address tied to an account rather than a directly contactable personal or work mailbox, so a sign-off using it arguably does not carry the attribution the DCO is meant to provide.How this surfaced
This came up while investigating #311, where DCO was failing in merge queues.
The connection is specific: GitHub's merge queue builds a new commit whose author identity comes from the GitHub account. If that account has email privacy enabled, the merge queue commit author can be the account's pseudonymous noreply address.
A real example from servo/servo is merge queue commit
1ed1def72fa6d08b11ba7041c8eebb3e8c501b35, whose author is:while the carried-over trailer is:
Under today's behavior, the only way such a contributor passes the merge queue check is to sign off as the anonymous noreply address. In other words, the current behavior actively pushes contributors toward anonymized sign-offs in that path.
PR #313 addresses that specific inversion by evaluating the pull request's own commits, which carry the real git identity. This issue is the separate, pre-existing question of whether noreply sign-offs should be accepted at all on the ordinary pull request path.
This would be a breaking policy change
Many contributors legitimately use noreply addresses today, often because their employer or their own privacy preference requires it. Rejecting them would newly fail pull requests that currently pass, and because checks can be re-run, it could also flip previously-green pull requests to red.
Any change here needs a deliberate rollout decision, not a silent tightening.
Options to consider
dco.ymlconfiguration flag, default OFF to preserve current behavior, allowing a repository to require non-noreply addresses.No code change is proposed yet. This needs a maintainer policy decision first.