DCO: AGENTS.md promises identity enforcement that neither the hook nor CI does
Los mantenedores suelen responder en 1 día
@jiwenc-nv ya está trabajando en esto.
Desde el 25/8/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
Two things to settle: a doc claim that is currently false, and — if we want to make it true — which rule survives contact with how the repo is actually used.
The gap
AGENTS.md § Commits states:
The name and e-mail must match the committer's git identity (
git config user.name/git config user.email).A
commit-msgpre-commit hook enforces this.
Neither half is enforced:
scripts/check_dco_signoff.pymatches^Signed-off-by: \S.*<\S+>and stops. It never reads git config; the identity requirement appears only inside its own error text..github/workflows/dco.ymlchecks the trailer is present and well-formed. No identity comparison.
So Signed-off-by: Anybody <[email protected]> passes locally and in CI. That matters because a sign-off certifies that you have the right to submit the work — a trailer naming someone else certifies nothing.
Why the obvious fix is wrong
I wrote the strict version (compare against GIT_COMMITTER_IDENT, require at least one matching trailer), and it passed every case I could invent. Then I ran it against six months of real history:
| count | share | |
|---|---|---|
non-merge commits on main |
586 | |
| sign-off matches author | 155 | 26% |
| no sign-off at all | 405 | 69% |
| sign-off present, does not match | 26 | 4% |
The 405 are largely an artifact — 229 carry a (#NNN) subject, i.e. squash merges, where the message is rewritten and the trailer is dropped. What lands on main says little about what the contributor committed.
The 26 real mismatches are the problem, because they are not abuse:
author=farbod-nv <[email protected]>
signed=Farbod Motlagh <[email protected]> same address; the git name is a GitHub handle
author=rwiltz <[email protected]>
signed=Rafael Wiltz <[email protected]> GitHub noreply vs corporate address
Both are arguably more DCO-correct than the git identity is: the DCO asks for a real legal name, and git author names are routinely the GitHub handle. A strict name comparison would have blocked at least three contributors mid-workflow to close a gap nobody is exploiting. I closed #1013 for that reason.
What to decide
1. Do we want identity enforcement at all? If not, the fix is one line — stop claiming it in AGENTS.md, keep presence-only checking. That is a legitimate answer; the DCO's force comes from the act of signing, not from a machine verifying the name.
2. If yes, which rule? Candidates, roughly in order of how much they would disrupt:
| rule | catches | breaks |
|---|---|---|
| e-mail only, ignore name | wrong person entirely | noreply-vs-corporate users |
e-mail, with *[email protected] → corporate mapping |
same | nothing visible in the sample |
| warn, do not block | nothing, but surfaces it | nothing |
| full name + e-mail | everything | at least 3 current contributors |
3. Local, CI, or both? The hook is commit-msg, so --no-verify bypasses it and CI sees nothing. dco.yml is the only place a guarantee can actually hold — but that changes what CI rejects for everyone, which is why this is an issue and not a PR.
Notes
- A working strict implementation exists on
ivany-nv/dco-identity-check(d132e9a37) if a variant of it turns out to be wanted. Do not merge it as-is. - Whatever we pick,
AGENTS.mdanddco.ymlshould end up saying the same thing. Today they disagree with each other and with the hook.
cc @jiwenc — you own AGENTS.md § Commits and both DCO checks.
- Lenguaje dominante
- Python
- Estrellas
- 412
- Forks
- 97
- Merge medio
- 1 d 23 h
- PR fusionados (30 d)
- 157
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de NVIDIA/IsaacCapture
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
NVIDIA/IsaacCapture#910 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
NVIDIA/IsaacCapture#891 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
NVIDIA/IsaacCapture#1368 ·
Los mantenedores suelen responder en 1 día
-
Expose per-glove health and data freshness in the Avatar SDK and Isaac Teleop pluginPosiblemente ocupada @zihanjiang321 la tomó hace 1 día. Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
NVIDIA/IsaacCapture#1319 ·
Los mantenedores suelen responder en 1 día
-
Add OneRobotics A1 asset and Isaac Teleop examplePosiblemente ocupada @WangXuechun-woan la tomó hace 8 días. Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
NVIDIA/IsaacCapture#1291 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de NVIDIA/IsaacCapture
Issues similares
-
backlog
Dificultad 1/5 Menos de una hora Aptitud para principiantes 91/100
EchoTools/nevr-runtime#1108 ·
Los mantenedores suelen responder en 1 día
-
parse names a key after a top-level multi() threshold Bitcoin Core v31.1 refuses as not validAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
btclib-org/btclib-wallet#587 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Judgment-Pack/judgment-pack-spec#275 ·
Los mantenedores suelen responder en 1 día