Provide authoritative current-version CLA verification for missing commit statuses

Open
  • Is something wrong?
#1,924 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
c, github-actions
Domain
ci-cd, security

Research direction

Start by reviewing the required workflow’s CLA gate and the CLA Assistant provider’s supported authenticated verification interface; the issue does not name specific files or tests. Determine whether a least-privilege, provider-authenticated proof can bind the exact GitHub login, repository, and active CLA version. Done means the gate fails closed for every invalid or unavailable state, tests cover the stated positive and negative cases, and documentation explains setup and remediation.

Written by the indexing model from the issue text.

Description

Discovery context

While investigating #1923, PR #1922 had no license/cla status on head da73004bbc08d172d54a5d392d96d964cf38c21f when the gate's 300-second bounded wait expired; later PR head SHAs did receive success statuses. A prior success on PR #1903 head a4c7c622daa3b7247378acf71a74b7f40f4ff556 says “Contributor License Agreement is signed” and links to that PR, but GitHub's status response contains no trusted creator, CLA document version, or revocation state. The CLA Assistant current-signature endpoint (getLastSignature) requires authenticated provider access that the workflow's GITHUB_TOKEN does not have. Architect and Critic agreed that a historical commit status cannot safely authorize the missing current-head gate.

Scope

Identify and implement a least-privilege, provider-supported verification bridge for CLA Assistant (or another authoritative source) that the required workflow can call. Authenticate provider provenance and verify current signature state bound to the exact GitHub login, semantic-reasoning/wirelog, and active CLA document/version. Do not add association-based bypasses or accept generic historical commit statuses. If no safe provider access is available, document supported remediation and keep missing/pending status fail-closed.

Acceptance criteria

  • Successful proof is provider-authenticated and explicitly binds contributor login, repository, and current CLA version.
  • Missing, stale-version, revoked, mismatched-login/repository, malformed, unauthorized, and unavailable responses fail closed.
  • Credentials are least-privilege, protected from PR-controlled code and logs, and exposed only to the gate.
  • Tests cover valid proof and each negative binding/state.
  • OWNER and MEMBER contributors both require qualifying proof.
  • Documentation explains setup/remediation and states that missing or pending status alone never passes.
Dominant language
C
Stars
18
Forks
2
Avg merge
9h 44m
Merged PRs (30d)
162

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from semantic-reasoning/wirelog

All issues in semantic-reasoning/wirelog

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.