feat: add Forgejo Actions CI workflow #1

Merged

stack72 merged 18 commits from forgejo-ci into main 2026-05-26 23:48:20 +00:00

Conversation 2 Commits 18 Files changed 6 +1502

stack72 commented 2026-05-26 21:08:48 +00:00

Owner

Copy link

Port the GitHub Actions CI workflow to Forgejo Actions. Key changes:

• Replace dorny/paths-filter with git diff based change detection
• Replace github.* context with gitea.* context
• Drop Claude review jobs (to be added separately)
• Drop actions-audit job (GitHub-specific)
• All Deno check/lint/fmt/test jobs preserved with same matrix strategy

Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com

Port the GitHub Actions CI workflow to Forgejo Actions. Key changes: - Replace dorny/paths-filter with git diff based change detection - Replace github.* context with gitea.* context - Drop Claude review jobs (to be added separately) - Drop actions-audit job (GitHub-specific) - All Deno check/lint/fmt/test jobs preserved with same matrix strategy Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

stack72 added 1 commit 2026-05-26 21:08:48 +00:00

feat: add Forgejo Actions CI workflow ... 33b3a8b206

Port the GitHub Actions CI workflow to Forgejo Actions. Key changes:
- Replace dorny/paths-filter with git diff based change detection
- Replace github.* context with gitea.* context
- Drop Claude review jobs (to be added separately)
- Drop actions-audit job (GitHub-specific)
- All Deno check/lint/fmt/test jobs preserved with same matrix strategy

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

stack72 added 1 commit 2026-05-26 21:11:34 +00:00

fix: use github.* context variables for Forgejo Actions compatibility ... bad0ac8dbd

Forgejo Actions uses the github.* namespace for full GitHub Actions
compatibility, not gitea.* which is only for Gitea-specific extensions.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

stack72 added 1 commit 2026-05-26 21:14:49 +00:00

ci: trigger re-run after DEFAULT_ACTIONS_URL fix b69d92a5ae

stack72 added 1 commit 2026-05-26 21:16:54 +00:00

feat: add Forgejo Actions publish workflow ... 73abfa6a6f

Port the GitHub Actions publish workflow to Forgejo Actions.
Identical logic - detect changed manifest.yaml files, chunk into
batches of 50, publish via swamp extension push.

Requires SWAMP_API_KEY secret in Forgejo repo settings.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

stack72 added 1 commit 2026-05-26 21:18:45 +00:00

feat: add Forgejo Actions regenerate-models workflow ... 199f24dac4

Port the GitHub Actions regenerate-models workflow to Forgejo Actions.
Key changes:
- Replace gh CLI with Forgejo API (curl) for PR creation/detection
- Replace GH_TOKEN with FORGEJO_TOKEN secret
- Replace git user to forgejo-actions[bot]
- All codegen logic preserved as-is

Requires FORGEJO_TOKEN secret with contents:write and pull-requests:write
scopes in Forgejo repo settings.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

stack72 added 1 commit 2026-05-26 21:37:07 +00:00

feat: add Claude review jobs and actions-audit to Forgejo CI ... 1d75780a70

- actions-audit: check for unpinned or outdated Actions
- claude-review: Claude Code Review (sonnet) via CLI
- claude-adversarial-review: Adversarial Review (opus) for core changes
- claude-ci-security-review: CI Security Review (opus) for workflow changes
- regenerate-models: use BOT_TOKEN instead of FORGEJO_TOKEN

All Claude jobs install the CLI directly and post reviews as PR comments
via the Forgejo API, replacing anthropics/claude-code-action and gh CLI.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

stack72 added 1 commit 2026-05-26 21:49:53 +00:00

fix: rewrite Claude review jobs for sh compatibility ... 3abc997618

Write prompts to temp files instead of inline heredocs to avoid
sh syntax errors in the runner container. All steps now use
shell: bash explicitly.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

stack72 added 1 commit 2026-05-26 21:59:20 +00:00

fix: pipe Claude install script to bash, set bash as default shell ... 2601105ac7

The Claude install script uses bash syntax but was being piped to sh.
Also set workflow-level defaults.run.shell to bash for all steps.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

stack72 added 1 commit 2026-05-26 22:13:18 +00:00

fix: symlink claude CLI to /usr/local/bin for PATH visibility 3834c4b4b9

stack72 added 1 commit 2026-05-26 22:23:59 +00:00

fix: store Claude review prompts as files, restore full prompt content ... 5ae733466c

Move all three Claude review prompts to .forgejo/prompts/ as standalone
markdown files with complete, unmodified review checklists. Workflow
steps read prompts via cat, eliminating all shell escaping issues.

- .forgejo/prompts/review.md - full code review checklist
- .forgejo/prompts/adversarial.md - full adversarial review checklist
- .forgejo/prompts/ci-security.md - full CI security review checklist

Also adds defaults.run.shell: bash to publish and regenerate-models
workflows to prevent sh compatibility issues.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

stack72 added 1 commit 2026-05-26 22:31:34 +00:00

fix: claude installs to ~/.local/bin, not ~/.claude 3c7e682a76

stack72 added 1 commit 2026-05-26 22:43:46 +00:00

fix: explicitly instruct Claude to execute commands, not print them e4fc984498

stack72 added 1 commit 2026-05-26 22:45:19 +00:00

fix: separate Claude review from PR comment posting ... f77d8cb845

Claude now only writes review to /tmp/review-body.md. A separate
workflow step reads the file and posts it via Forgejo API. This:
- Removes curl from Claude's allowed tools (security concern)
- Keeps secrets out of Claude's environment
- Makes the review step pure analysis, posting step pure infrastructure

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

stack72 added 1 commit 2026-05-26 22:55:45 +00:00

fix: post review step was skipped due to hashFiles not working on /tmp e72b975bf0

stack72 added 1 commit 2026-05-26 22:58:30 +00:00

security: fix all 3 CI security review findings ... 4b307521cf

1. CRITICAL: Replace curl|bash with pinned Claude CLI download + sha256
   checksum verification (v2.1.150)
2. HIGH: Add workflow-level permissions: contents: read
3. HIGH: Remove Write tool and Bash(cat:*) from Claude's allowed tools.
   Scoped to Bash(tee /tmp/review-body.md:*) and Bash(touch /tmp/review-failed)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

stack72 added 1 commit 2026-05-26 23:09:05 +00:00

fix: use python3 instead of jq for JSON encoding (not in base image) 931a3cc47b

stack72 added 1 commit 2026-05-26 23:20:11 +00:00

fix: use -d @file for curl payload, show HTTP error on failure d44a90003b

stack72 added 1 commit 2026-05-26 23:31:36 +00:00

ci: trigger re-run e17898ed49

stack72 commented 2026-05-26 23:40:52 +00:00

Author

Owner

Copy link

CI Security Review

Critical / High

None found.

Medium

1. .forgejo/workflows/publish.yml: Missing explicit permissions declaration

   • File: .forgejo/workflows/publish.yml (workflow level, between lines 3-9)
   • Vulnerability: No permissions: block at the workflow level. Depending on Forgejo server configuration, the default GITHUB_TOKEN may have broader permissions than needed (e.g., contents: write, packages: write). The jobs only need contents: read.
   • Risk: If a step is compromised or a dependency in the publish pipeline has a vulnerability, the token could be used for unintended write operations against the repository.
   • Mitigating factor: This workflow only triggers on push to main, so only already-reviewed code runs here.
   • Fix: Add permissions: contents: read at the workflow level (matching the GitHub variant which has it at job level).

2. .github/workflows/auto-response.yml:8-9: Workflow-level permissions instead of job-level

   • File: .github/workflows/auto-response.yml, lines 8-9
   • Vulnerability: issues: write and contents: read are set at the workflow level. Currently there is only one job, so this is functionally equivalent to job-level. However, if a second job is added later, it will inherit issues: write unnecessarily.
   • Risk: Low — single-job workflow makes this a theoretical concern. Flagging as a best-practice gap.
   • Fix: Move the permissions: block into the automove job definition.

Low

1. .forgejo/workflows/ci.yml:39-41: Direct expression interpolation of SHAs in run: block
   • File: .forgejo/workflows/ci.yml, lines 39-41
   • Expression: BASE_SHA=${{ github.event.pull_request.base.sha }} and HEAD_SHA=${{ github.event.pull_request.head.sha }}
   • Context: Git SHAs are 40-character hex strings and cannot contain shell metacharacters, so this is not exploitable. However, the defensive pattern is to pass values via env: rather than direct interpolation, to avoid establishing a pattern that could be copied for attacker-controlled fields.
   • Fix (optional): Pass via environment variables:

     env:
       BASE_SHA: ${{ github.event.pull_request.base.sha }}
       HEAD_SHA: ${{ github.event.pull_request.head.sha }}
     run: |
       CHANGED=$(git diff --name-only "${BASE_SHA}...${HEAD_SHA}")
     

Positive Security Observations

• Prompt hardening: All three LLM prompt files (.forgejo/prompts/review.md, adversarial.md, ci-security.md) and all inline prompts in .github/workflows/ci.yml include security preambles instructing the model to treat PR content as untrusted and ignore embedded instructions.
• Tightly scoped LLM tools: All Claude review jobs restrict tools to Read,Glob,Grep,Bash(git diff:*),Bash(git log:*),Bash(tee /tmp/review-body.md:*),Bash(touch /tmp/review-failed) (Forgejo) or Read,Glob,Grep,Bash(gh pr review:*),Bash(gh pr view:*),Bash(gh pr diff:*),Bash(touch /tmp/review-failed) (GitHub). No broad Bash(*) or Bash(curl:*) access.
• Supply chain pins: Third-party actions use SHA pins (dorny/paths-filter@fbd0ab8...) or tag pins from trusted publishers (actions/*, anthropics/*, denoland/*, systeminit/*). The Forgejo Claude binary download uses SHA256 checksum verification.
• Job-level permissions: The GitHub CI workflow uses job-level permissions throughout. The Forgejo CI uses a restrictive workflow-level default (contents: read) with job-level overrides only where needed.
• No dangerous triggers: No pull_request_target usage. The issues: [opened] trigger in auto-response.yml properly handles attacker-controlled content via JSON.stringify (no string interpolation injection) and validates the external API response before constructing URLs.
• No prompt injection via expression interpolation: LLM prompts do not interpolate attacker-controlled event fields (issue.title, issue.body, pull_request.body, etc.). The Forgejo variant reads prompts from repo files; the GitHub variant uses inline YAML strings with only safe expressions (github.repository, github.event.pull_request.number).
• Secret scoping: Secrets are passed only to steps that need them (ANTHROPIC_API_KEY to Claude steps, BOT_TOKEN/SWAMP_API_KEY to their respective steps).
• workflow_dispatch input validation: The regenerate-models workflow uses type: choice with a fixed option set, preventing arbitrary input injection.

Verdict

PASS — No critical or high severity findings. The workflow security posture is strong, with well-scoped permissions, hardened LLM prompts, pinned dependencies, and proper handling of untrusted input. Two medium findings are best-practice improvements that don't represent exploitable vulnerabilities.

## CI Security Review ### Critical / High None found. ### Medium 1. **`.forgejo/workflows/publish.yml`: Missing explicit permissions declaration** - **File**: `.forgejo/workflows/publish.yml` (workflow level, between lines 3-9) - **Vulnerability**: No `permissions:` block at the workflow level. Depending on Forgejo server configuration, the default GITHUB_TOKEN may have broader permissions than needed (e.g., `contents: write`, `packages: write`). The jobs only need `contents: read`. - **Risk**: If a step is compromised or a dependency in the publish pipeline has a vulnerability, the token could be used for unintended write operations against the repository. - **Mitigating factor**: This workflow only triggers on `push` to `main`, so only already-reviewed code runs here. - **Fix**: Add `permissions: contents: read` at the workflow level (matching the GitHub variant which has it at job level). 2. **`.github/workflows/auto-response.yml:8-9`: Workflow-level permissions instead of job-level** - **File**: `.github/workflows/auto-response.yml`, lines 8-9 - **Vulnerability**: `issues: write` and `contents: read` are set at the workflow level. Currently there is only one job, so this is functionally equivalent to job-level. However, if a second job is added later, it will inherit `issues: write` unnecessarily. - **Risk**: Low — single-job workflow makes this a theoretical concern. Flagging as a best-practice gap. - **Fix**: Move the `permissions:` block into the `automove` job definition. ### Low 1. **`.forgejo/workflows/ci.yml:39-41`: Direct expression interpolation of SHAs in `run:` block** - **File**: `.forgejo/workflows/ci.yml`, lines 39-41 - **Expression**: `BASE_SHA=${{ github.event.pull_request.base.sha }}` and `HEAD_SHA=${{ github.event.pull_request.head.sha }}` - **Context**: Git SHAs are 40-character hex strings and cannot contain shell metacharacters, so this is not exploitable. However, the defensive pattern is to pass values via `env:` rather than direct interpolation, to avoid establishing a pattern that could be copied for attacker-controlled fields. - **Fix** (optional): Pass via environment variables: ```yaml env: BASE_SHA: ${{ github.event.pull_request.base.sha }} HEAD_SHA: ${{ github.event.pull_request.head.sha }} run: | CHANGED=$(git diff --name-only "${BASE_SHA}...${HEAD_SHA}") ``` ### Positive Security Observations - **Prompt hardening**: All three LLM prompt files (`.forgejo/prompts/review.md`, `adversarial.md`, `ci-security.md`) and all inline prompts in `.github/workflows/ci.yml` include security preambles instructing the model to treat PR content as untrusted and ignore embedded instructions. - **Tightly scoped LLM tools**: All Claude review jobs restrict tools to `Read,Glob,Grep,Bash(git diff:*),Bash(git log:*),Bash(tee /tmp/review-body.md:*),Bash(touch /tmp/review-failed)` (Forgejo) or `Read,Glob,Grep,Bash(gh pr review:*),Bash(gh pr view:*),Bash(gh pr diff:*),Bash(touch /tmp/review-failed)` (GitHub). No broad `Bash(*)` or `Bash(curl:*)` access. - **Supply chain pins**: Third-party actions use SHA pins (`dorny/paths-filter@fbd0ab8...`) or tag pins from trusted publishers (`actions/*`, `anthropics/*`, `denoland/*`, `systeminit/*`). The Forgejo Claude binary download uses SHA256 checksum verification. - **Job-level permissions**: The GitHub CI workflow uses job-level permissions throughout. The Forgejo CI uses a restrictive workflow-level default (`contents: read`) with job-level overrides only where needed. - **No dangerous triggers**: No `pull_request_target` usage. The `issues: [opened]` trigger in `auto-response.yml` properly handles attacker-controlled content via `JSON.stringify` (no string interpolation injection) and validates the external API response before constructing URLs. - **No prompt injection via expression interpolation**: LLM prompts do not interpolate attacker-controlled event fields (`issue.title`, `issue.body`, `pull_request.body`, etc.). The Forgejo variant reads prompts from repo files; the GitHub variant uses inline YAML strings with only safe expressions (`github.repository`, `github.event.pull_request.number`). - **Secret scoping**: Secrets are passed only to steps that need them (`ANTHROPIC_API_KEY` to Claude steps, `BOT_TOKEN`/`SWAMP_API_KEY` to their respective steps). - **`workflow_dispatch` input validation**: The `regenerate-models` workflow uses `type: choice` with a fixed option set, preventing arbitrary input injection. ### Verdict **PASS** — No critical or high severity findings. The workflow security posture is strong, with well-scoped permissions, hardened LLM prompts, pinned dependencies, and proper handling of untrusted input. Two medium findings are best-practice improvements that don't represent exploitable vulnerabilities.

stack72 commented 2026-05-26 23:42:23 +00:00

Author

Owner

Copy link

Code Review

Blocking Issues

1. Command injection in cve/dirtyfrag/extensions/models/dirtyfrag_detect.ts:176

   checkConnectivity() interpolates the user-supplied host string directly into a bash -c
   command string. host originates from GlobalArgsSchema.targetHost (a plain string field).
   The only pre-check filters localhost/127.0.0.1/::1. Any value containing shell
   metacharacters executes on the local machine. port is typed as number so it is safe.

   Fix: replace the bash invocation with Deno.connect wrapped in a try/catch so that TCP
   reachability is tested without spawning a shell at all.

2. Overly broad catch blocks in codegen/commands/generate.ts:326 and :631

   Both blocks silently swallow every error including permission-denied and disk-full,
   which should abort generation. The code following each block calls Deno.remove on
   orphaned model files, so a masked write-permission error could silently skip pruning
   and leave stale generated files in the output tree.

   Fix: re-throw unless the error is Deno.errors.NotFound. The correct pattern is already
   used in codegen/scripts/bump-versions.ts -- apply it to both catch sites in generate.ts.

Suggestions

1. codegen/aws/enrichments/parser.ts:11 and codegen/gcp/enrichments/parser.ts:11 --
   unhandled Deno.readTextFile failure. Wrap in try/catch and re-throw with the source
   file path appended so codegen failures are easier to diagnose.

2. datastore/gcs/extensions/datastores/_lib/gcs_client.ts -- bodyPreview included in
   401/403 error messages. GCS auth-failure bodies rarely contain credentials, but
   omitting the preview from those paths is a cheap defence-in-depth improvement.

## Code Review ### Blocking Issues 1. Command injection in cve/dirtyfrag/extensions/models/dirtyfrag_detect.ts:176 checkConnectivity() interpolates the user-supplied host string directly into a bash -c command string. host originates from GlobalArgsSchema.targetHost (a plain string field). The only pre-check filters localhost/127.0.0.1/::1. Any value containing shell metacharacters executes on the local machine. port is typed as number so it is safe. Fix: replace the bash invocation with Deno.connect wrapped in a try/catch so that TCP reachability is tested without spawning a shell at all. 2. Overly broad catch blocks in codegen/commands/generate.ts:326 and :631 Both blocks silently swallow every error including permission-denied and disk-full, which should abort generation. The code following each block calls Deno.remove on orphaned model files, so a masked write-permission error could silently skip pruning and leave stale generated files in the output tree. Fix: re-throw unless the error is Deno.errors.NotFound. The correct pattern is already used in codegen/scripts/bump-versions.ts -- apply it to both catch sites in generate.ts. ### Suggestions 1. codegen/aws/enrichments/parser.ts:11 and codegen/gcp/enrichments/parser.ts:11 -- unhandled Deno.readTextFile failure. Wrap in try/catch and re-throw with the source file path appended so codegen failures are easier to diagnose. 2. datastore/gcs/extensions/datastores/_lib/gcs_client.ts -- bodyPreview included in 401/403 error messages. GCS auth-failure bodies rarely contain credentials, but omitting the preview from those paths is a cheap defence-in-depth improvement.

stack72 merged commit 59115b574b into main 2026-05-26 23:48:20 +00:00

stack72 deleted branch forgejo-ci 2026-05-26 23:48:20 +00:00

stack72 referenced this pull request from a commit 2026-05-26 23:48:22 +00:00

feat: add Forgejo Actions CI workflow (#1)

stack72 referenced this pull request 2026-05-27 20:45:14 +00:00

fix(kubernetes): prevent kubectl flag injection in pod exec #6

stack72 referenced this pull request 2026-05-28 20:47:46 +00:00

feat(codegen/hetzner): vault-wireable token auth and paginated list method #12

stack72 referenced this pull request 2026-06-03 13:02:53 +00:00

feat(issue-lifecycle): add platform type to IssueType Zod schema #27

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

swamp-club/swamp-extensions!1

No description provided.