Handle verified prior CLA signatures when hosted status is missing
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start with .github/workflows/cla-required.yml and inspect the CLA provider’s status behavior for synchronized pull request heads, using PRs #1922 and #1945 as reproductions. Establish the authoritative signoff source and identity policy before choosing a provider configuration or repository-owned fallback. Done means tests cover exact-head verification and failure cases, and prior-head success alone cannot pass the gate.
Written by the indexing model from the issue text.
Description
Scope
Determine why the hosted CLA provider omits license/cla on synchronized pull request heads and make strict signoff verification reliable for each current PR head. Prefer configuring the provider to publish the status on every synchronized head. If that is not reliable or supported, implement a repository-owned verification path backed by an authoritative, durable signoff source keyed to immutable GitHub account identities and matching the repository's existing contributor policy.
Keep the gate fail-closed for missing or unknown identity proof, newly required unsigned identities, revoked or invalid agreements, explicit provider failure, and provider/API errors. An ancestor commit's green status alone is never evidence that the current PR head satisfies policy. Do not add a manual bypass or weaken OWNER behavior. Timeout and rerun diagnostics may be improved as supporting work.
Discovery context
PR #1922 (da73004bbc08d172d54a5d392d96d964cf38c21f) was authored by a repository member. Its license/cla status was missing for the full 300-second bounded wait, so .github/workflows/cla-required.yml correctly failed closed. An earlier SHA (a4c7c622daa3b7247378acf71a74b7f40f4ff556) had license/cla=success with the description “Contributor License Agreement is signed,” associated with PR #1903. Membership alone is not evidence of a signed CLA, and the provider's handling of synchronized heads was not established.
PR #1945 reproduced the same gap: its author had a successful license/cla status on the previous head (c90f4af), but the synchronized head (b3f3ecb) had no hosted CLA status. The exact-head workflow waited 300 seconds and failed closed. Architect and Critic confirmed this is the same underlying issue as the PR #1922 report; #1946's stricter requirements and discovery context are consolidated here. Prior-head status alone must not be reused.
Acceptance criteria
- Identify and document why the provider omits the status and the authoritative source of signature evidence; configure reliable per-head publication where supported.
- After a validly signed contributor updates a PR from head A to head B, the gate verifies every identity required by policy and passes for B within a documented service-level bound.
- A successful status on A alone cannot make the gate pass for B. If a repository-owned fallback is needed, accept evidence only when an authoritative durable source proves valid signoff for the same immutable contributor identity and this repository.
- A newly required unsigned or unknown identity, missing or revoked agreement, explicit provider failure, or provider/API error keeps the gate failing.
- Tests cover exact synchronized-head success, missing/pending/failure states, durable verified signoff evidence, proof that prior-head status alone is insufficient, and required identity coverage.
- Keep bounded polling and actionable remediation for missing provider status. Do not add a blanket OWNER, MEMBER, or COLLABORATOR exemption, fabricate statuses, or create a general bypass; unsigned external contributors remain rejected, and existing OWNER handling remains unchanged.
- Dominant language
- C
- Stars
- 18
- Forks
- 2
- Avg merge
- 9h 45m
- Merged PRs (30d)
- 162
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from semantic-reasoning/wirelog
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
semantic-reasoning/wirelog#2229 ·
Maintainers usually reply within 1 day
-
Doc: insert executor and incremental consolidation leave sorted runs, not globally sorted headsOpen
Difficulty 1/5 Under an hour Newbie friendliness 83/100
semantic-reasoning/wirelog#2133 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
semantic-reasoning/wirelog#2042 ·
Maintainers usually reply within 1 day
-
p2-medium
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
semantic-reasoning/wirelog#1914 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 22/100
semantic-reasoning/wirelog#2329 · 1 comment ·
Maintainers usually reply within 1 day
All issues in semantic-reasoning/wirelog
Similar issues
-
bug core p3
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
RunanywhereAI/runanywhere-sdks#1258 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
rolotrealanis98/open-apollo#126 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
cython/cython#8110 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
onehumanbeing/esp32-iphone-agent#62 ·
Maintainers usually reply within 1 day
-
ai-driven-fuzzing bug claude Minor
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
linagora/open-bastion#425 ·
Maintainers usually reply within 1 day