Skip to content

feat: add CLA enforcement via contributor-assistant #10

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
4444J99 merged 1 commit into from
Apr 20, 2026
Merged

feat: add CLA enforcement via contributor-assistant #10

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions .github/workflows/cla.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
name: CLA Assistant
on:
issue_comment:
types: [created]
pull_request_target:
types: [opened, closed, synchronize]
Comment on lines +2 to +6
Copy link
Copy Markdown

@llamapreview llamapreview Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P0 | Confidence: High

The workflow is triggered by the privileged pull_request_target event. This event runs in the context of the base repository (target branch) with write permissions, not the untrusted PR source. While necessary for the contributor-assistant action to write statuses and signature files, this PR does NOT implement the required security guardrails. Malicious external contributors could submit a PR with a modified .github/workflows/ directory that runs arbitrary, privileged code in the base repository context during the pull_request_target event, potentially leading to repository compromise or secret exfiltration. The standard mitigation is to ensure the workflow if condition excludes changes to workflows, but no such condition is present.

Code Suggestion:

on:
  issue_comment:
    types: [created]
  pull_request_target:
    types: [opened, closed, synchronize]

jobs:
  CLAssistant:
    # CRITICAL: Prevent workflow injection from untrusted PRs
    if: github.event_name == 'issue_comment' || (github.event_name == 'pull_request_target' && !contains(github.event.pull_request.head.ref, '.github/workflows/'))
    runs-on: ubuntu-latest
    steps:
      - name: CLA Assistant
        ...


permissions:
actions: write
contents: write
pull-requests: write
statuses: write
Comment on lines +8 to +12
Copy link
Copy Markdown

@sourcery-ai sourcery-ai Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚨 suggestion (security): Consider tightening the permissions block to the minimal scopes required for the CLA action.

This workflow grants actions: write, contents: write, pull-requests: write, and statuses: write. For a CLA assistant that mainly updates a signatures file and comments on PRs, some of these likely don’t need write access (particularly actions and statuses). Since this runs on pull_request_target with repo secrets, trimming permissions to only what’s strictly required would meaningfully reduce risk if the workflow or a dependency is compromised.

Suggested change
permissions:
actions: write
contents: write
pull-requests: write
statuses: write
permissions:
contents: write
pull-requests: write


jobs:
CLAssistant:
runs-on: ubuntu-latest
steps:
- name: CLA Assistant
if: (github.event.comment.body == 'recheck' || github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA') || github.event_name == 'pull_request_target'
Comment on lines +18 to +19
Copy link
Copy Markdown

@llamapreview llamapreview Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 | Confidence: High

The if condition for the issue_comment trigger is flawed. The event payload for issue_comment on a Pull Request includes the comment body under github.event.comment.body. However, the condition uses a logical OR (||) with the pull_request_target event check, making the entire condition true for ANY pull_request_target event, which is correct. The flaw is that for an issue_comment event, the condition also becomes true if it's a pull_request_target event, which is impossible. While this doesn't cause a failure, it's logically incorrect and confusing. More importantly, the condition does not scope the issue_comment trigger to only comments on Pull Requests (as opposed to regular Issues), which could cause the CLA action to run incorrectly on Issue comments.

Code Suggestion:

- name: CLA Assistant
        # For issue_comment events, only run on PR comments with the specific signature phrase or 'recheck'.
        # For pull_request_target events, always run.
        if: |
          (github.event_name == 'issue_comment' && github.event.issue.pull_request &&
            (github.event.comment.body == 'recheck' || github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA')
          ) || github.event_name == 'pull_request_target'

uses: contributor-assistant/github-action@v2.6.1

Check warning

Code scanning / CodeQL

Unpinned tag for a non-immutable Action in workflow Medium

Unpinned 3rd party Action 'CLA Assistant' step
Uses Step
Loading
uses 'contributor-assistant/github-action' with ref 'v2.6.1', not a pinned commit hash
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
path-to-signatures: 'signatures/cla.json'
path-to-document: 'https://github.com/meta-organvm/.github/blob/main/CLA.md'
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
curl -sI -o /dev/null -w "%{http_code}\n" https://github.com/meta-organvm/.github/blob/main/CLA.md

Repository: organvm-i-theoria/recursive-engine--generative-entity

Length of output: 100

Fix the CLA URL — it returns 404 and uses an incorrect format.

The URL https://github.com/meta-organvm/.github/blob/main/CLA.md returns HTTP 404, preventing contributors from accessing the CLA. Additionally, the /blob/ format is the GitHub web interface and is not suitable for automated tools like contributor-assistant. Use the raw content URL instead:

https://raw.githubusercontent.com/meta-organvm/.github/main/CLA.md

Verify that the meta-organvm/.github repository exists and is public before updating.

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/cla.yml at line 25, Update the path-to-document value in
the CLA workflow to use the raw GitHub content URL instead of the web/blob URL;
replace 'https://github.com/meta-organvm/.github/blob/main/CLA.md' with
'https://raw.githubusercontent.com/meta-organvm/.github/main/CLA.md' in the
path-to-document field and confirm the meta-organvm/.github repository exists
and is public so the raw URL is reachable by contributor-assistant.

Copy link
Copy Markdown

@llamapreview llamapreview Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 | Confidence: High

The workflow configures the CLA assistant to read the CLA document from an external repository (meta-organvm/.github). This creates a hard, cross-repository dependency. If the CLA.md file in the external repo is moved, renamed, deleted, or has its permissions changed, the CLA check in this repository will fail for all new contributors, blocking contributions. The related_context shows this repository is part of the "organvm ecosystem", suggesting a centralized policy is intended. However, this introduces a single point of failure and operational risk. The repository's own CONTRIBUTING.md (implied by standard open-source practice, though not in provided context) would not reflect this external dependency.

Code Suggestion:

# Option 1: Host a copy locally for resilience (recommended for critical legal docs)
          path-to-document: 'https://github.com/organvm-i-theoria/recursive-engine--generative-entity/blob/main/CLA.md'
          # Option 2: Keep external reference but add a verification step or fallback in the workflow.

Evidence: path:meta-organvm/.github/CLA.md

branch: 'main'
allowlist: 'bot*,dependabot[bot],github-actions[bot],4444J99'
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Allowlist has redundant entries and a risky wildcard.

bot* is a prefix glob that already matches dependabot[bot] / github-actions[bot], so both specific entries are redundant. More importantly, bot* will also match any future/attacker-controlled username starting with bot (e.g., bot-attacker), letting them bypass the CLA. Recommend dropping the wildcard and listing only the bots you actually want to exempt.

🔒 Proposed fix 
-          allowlist: 'bot*,dependabot[bot],github-actions[bot],4444J99'
+          allowlist: 'dependabot[bot],github-actions[bot],4444J99'
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
allowlist: 'bot*,dependabot[bot],github-actions[bot],4444J99'
allowlist: 'dependabot[bot],github-actions[bot],4444J99'
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/cla.yml at line 27, The allowlist uses a risky wildcard
"bot*" that redundantly matches specific entries and could exempt
attacker-controlled usernames; update the allowlist value in the CLA workflow by
removing the "bot*" glob and keeping only the explicit safe entries (e.g.,
replace "bot*,dependabot[bot],github-actions[bot],4444J99" with
"dependabot[bot],github-actions[bot],4444J99") so only known bot accounts and
the intended ID remain exempt; edit the allowlist key in the workflow file
accordingly.

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Restrict CLA allowlist to explicit bot identities

The allowlist includes bot*, and this action treats allowlist entries as wildcard patterns, so any normal GitHub user whose login starts with bot can bypass CLA signing. That breaks the intended “all external PRs must sign” enforcement and creates a compliance gap; limit this to explicit bot accounts (for example dependabot[bot], github-actions[bot]) instead of a broad prefix wildcard.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown

@llamapreview llamapreview Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 | Confidence: Medium

The user 4444J99 is allowlisted. The related_context from README.md confirms this is the project author. However, the allowlist uses a glob pattern (bot*) for bots but lists specific names for dependabot[bot] and github-actions[bot]. The pattern bot* is broad and could accidentally allowlist any GitHub user whose login begins with "bot", which is a potential (though low-risk) security oversight. It is more precise and secure to list the specific bot logins.

Code Suggestion:

allowlist: 'dependabot[bot],github-actions[bot],4444J99'
          # If other generic bots are needed, add them explicitly, e.g., 'renovate[bot]'

Evidence: path:README.md|search:4444J99

custom-notsigned-prcomment: |
Thank you for your contribution to **recursive-engine--generative-entity**! Before we can merge this PR, we need you to sign our [Contributor License Agreement](https://github.com/meta-organvm/.github/blob/main/CLA.md).

To sign, please comment on this PR with:

> I have read the CLA Document and I hereby sign the CLA

This is a one-time requirement that covers all future contributions to the ORGANVM ecosystem.
custom-pr-sign-comment: 'I have read the CLA Document and I hereby sign the CLA'
1 change: 1 addition & 0 deletions signatures/cla.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
[]
Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

The pull request is incomplete as it lacks the GitHub Actions workflow file (e.g., .github/workflows/cla.yml) required to actually perform the CLA enforcement. While the storage file signatures/cla.json is present, the logic to trigger the check, verify signatures, and apply the allowlist mentioned in the description is missing.

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

This change introduces a new governance protocol but does not include the required documentation updates. According to the repository style guide (Logos Documentation Layer, lines 181-194), significant changes to the project's state or community standards should be recorded in the docs/logos/ directory. Please update docs/logos/pragma.md and docs/logos/receptio.md to reflect the implementation of CLA enforcement.

References
  1. The Logos Documentation Layer requires a narrative record of the system's state and polis in docs/logos/. (link)

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Remove manually created CLA signature seed file

The workflow is wired to contributor-assistant/github-action@v2.6.1, whose setup expects to create the signatures file itself; pre-creating signatures/cla.json can make CLA processing fail when contributors sign. If this file is seeded manually, the CLA check can fail for valid contributors and block merges until the file is removed.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown

@llamapreview llamapreview Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 | Confidence: High

The initial signatures/cla.json is an empty array. While correct for bootstrapping, the PR's test plan is manual. There is no automated test to verify the workflow's core function: writing a valid signature to this file. A regression in the CLA assistant action or a permissions issue could cause the file to remain empty or be written in an invalid format, breaking the enforcement system silently. The repository has existing Python tests (test (3.11) passes per CI). A simple integration test should be added to verify the signature file structure after a mock signing event, perhaps in a separate workflow that runs on push to main.

Loading