Merging latest main to vanilla to update to the best stable state.

[timfox]

Note

Major build/CI modernization and project rename.

• Rename project and outputs: quake3e → idtech3 (idtech3, idtech3_server); default RENDERER_DEFAULT now vulkan
• Replace Makefile with CMake (min 3.24); reorganize sources under src/; add MP3 option and SKIP_IDPAK_CHECK; robust SDL2 finding; x86_64 ASM handling; linker fixes; normalized renderer plugin names (e.g., idtech3_opengl_x86_64.so)
• CI workflow rewritten to use CMake/Ninja on Win/Linux/macOS; updated matrices, artifact names/packaging, and release steps; macOS limited to Apple Silicon in CI
• Add build scripts (scripts/compile_engine.sh, scripts/compile_game.sh, macOS packaging); update BUILD.md/README.md; expand .gitignore; add SECURITY.md and CLAUDE.md

^{Written by Cursor Bugbot for commit ff9f520. This will update automatically on new commits. Configure here.}

In general, fix this by adding an explicit permissions block to the workflow so that the GITHUB_TOKEN is limited to only the scopes required. You can set it at the workflow level (applies to all jobs) or at each job. Since most jobs only need to read code and artifacts, but create-testing and update-release need to modify releases, we can set a conservative default at the top and override only for the release‑modifying jobs.

The minimal, behavior‑preserving approach is:

• Add a workflow‑level permissions block after the on: section to restrict defaults to read‑only access to contents (and nothing else).
• Add permissions blocks to the create-testing and update-release jobs to grant contents: write, which is what their release‑upload actions require to create/update release assets.
• No imports or external dependencies are involved; all changes are within .github/workflows/build.yml.

Concretely:

• After line 21 (workflow_dispatch:), insert:

permissions:
  contents: read

• In the create-testing job (around line 447), add:

    permissions:
      contents: write

right under runs-on: ubuntu-latest.

• In the update-release job (around line 479), add:

    permissions:
      contents: write

right under runs-on: ubuntu-latest.

This satisfies CodeQL’s requirement and enforces least privilege without changing how the workflow currently functions.

---

In general, the problem is fixed by explicitly defining a permissions: block so that the GITHUB_TOKEN gets only the least privileges necessary. For build and artifact upload jobs that only need to read repository contents, contents: read is sufficient. For jobs that create or update releases using GITHUB_TOKEN, contents: write is typically required. No other scopes (issues, pull-requests, etc.) are needed from what is shown.

The best way to fix this workflow without changing behavior is:

1. Add a root-level permissions: block near the top of the file (after name: and before on:) to restrict all jobs to read-only access by default:

   permissions:
     contents: read

   This is enough for checkout and general reading of repo contents.

2. Override permissions only where write access is actually needed:

   • Job create-testing uses czietz/action-automatic-releases@latest with repo_token: ${{ secrets.GITHUB_TOKEN }} to create/update a “Latest Build” release, so it needs contents: write.
   • Job update-release runs on release events (and is presumably updating release assets using GITHUB_TOKEN in omitted parts), so it should also get contents: write.

   Thus, add a permissions: block under create-testing: and update-release::

   create-testing:
     permissions:
       contents: write
     if: ...
     ...

   and

   update-release:
     permissions:
       contents: write
     if: ...
     ...

No extra imports or external dependencies are needed; this is purely a change to the workflow YAML. All edits occur within .github/workflows/build.yml at the shown regions.

In general, the fix is to explicitly declare a permissions block so the GITHUB_TOKEN has only the minimal scopes required. Since all shown jobs just check out code, build, and upload/download artifacts, they only need read access to repository contents, not write access.

The best fix without changing existing functionality is to add a single top-level permissions block (just under name: and before on:) to apply to all jobs, setting contents: read. This matches CodeQL’s suggested minimal starting point and is sufficient for actions/checkout and actions/upload-artifact. We don’t see any steps requiring other scopes (like pull-requests, issues, or packages), so there’s no need to grant them. No changes are required inside individual jobs, including macos-x86; limiting permissions at the workflow root will resolve the flagged issue and may fix similar ones on other jobs in this workflow.

Concretely, edit .github/workflows/build.yml near the top:

• After line 1 (name: build), insert:

  permissions:
    contents: read

No imports or additional definitions are needed because this is pure workflow configuration.

In general, the fix is to explicitly declare a permissions: block either at the workflow level (recommended, so all jobs inherit it) or per job, restricting the GITHUB_TOKEN to the least privileges needed. For this workflow, the jobs only appear to need read access to repository contents for actions/checkout and standard artifact uploading, which works with contents: read. No code in the snippet needs to write to the repo, issues, or pull requests.

The single best fix with minimal behavioral change is to add a root-level permissions: block after the name: (or after on:) setting contents: read. This will apply to all jobs (ubuntu-x86, ubuntu-arm, ubuntu-arm64, macos-x86, create-testing, etc.) unless they later override it, tightening GITHUB_TOKEN’s permissions without impacting build or artifact upload steps. No additional imports, tools, or structural changes to jobs/steps are required; we only add the YAML keys.

Concretely:

• Edit .github/workflows/build.yml.
• Insert:

  permissions:
    contents: read

  just after the name: build line (line 1–2 region), before the on: block. This ensures CodeQL sees explicit restrictions and that all jobs in the workflow inherit these permissions.

In general, the fix is to explicitly set permissions for the GITHUB_TOKEN either at the workflow root (applies to all jobs without their own override) or per job. Since this workflow is build‑only and uses standard actions that require at most read access to repository contents, we can safely set contents: read as a minimal, least‑privilege baseline.

The best way to fix this, without changing any existing behavior, is to add a single permissions: block at the top level of .github/workflows/build.yml, directly under the name: build (or at the same level as on: and jobs:). This will apply to all jobs in the workflow, including ubuntu-arm, ubuntu-arm64, windows-msvc, ubuntu-x86, etc. We’ll set:

permissions:
  contents: read

No steps in the provided snippet need any additional scopes like pull-requests: write or issues: write, and no job is pushing code or creating releases, so contents: read is sufficient. There is no need for new imports or any changes inside individual jobs or steps; only the workflow YAML header is updated.

Concretely:

• Edit .github/workflows/build.yml.
• Insert a permissions: block after line 1 (name: build) and before line 3 (on:), with two spaces indentation for the contents key to match YAML style.
• Do not modify any other lines.

To fix this, explicitly declare minimal GITHUB_TOKEN permissions in the workflow. Since no job in the provided snippet needs to write to the repository, a workflow-level permissions: contents: read is appropriate. This both satisfies CodeQL and follows least-privilege.

The best, least intrusive fix is:

• Add a permissions: block at the top level of .github/workflows/build.yml, after the name: and before on:.
• Set contents: read so actions/checkout@v4 can read the repository, but no write permissions are granted to repo contents.
• No per-job permissions overrides are necessary unless other, unseen jobs require more access.

Concretely, edit .github/workflows/build.yml around the top of the file (lines 1–4 in the snippet) to insert:

permissions:
  contents: read

between name: build and on:. No additional methods, imports, or external packages are needed.

In general, the fix is to explicitly declare a minimal permissions: block in the workflow so that the GITHUB_TOKEN used by all jobs (including windows-msvc) has only the access it needs. Since the workflow checks out code and uploads artifacts, it only needs read access to repository contents; it does not appear to need to write to contents, issues, or pull requests.

The best targeted fix without changing functionality is to add a root-level permissions: section near the top of .github/workflows/build.yml, before the on: block. This applies to all jobs that do not have their own permissions block, including windows-msvc, and resolves the CodeQL warning. We set:

permissions:
  contents: read

No other modifications to jobs or steps are required, and no additional libraries or actions are needed.

Concretely: in .github/workflows/build.yml, between line 1 (name: build) and line 3 (on:), insert a root-level permissions: block with contents: read, keeping indentation consistent with YAML top-level keys.

In general, the fix is to explicitly specify a permissions block in the workflow so that the automatically provided GITHUB_TOKEN has only the minimal required privileges. Since the entire workflow only needs to read repository contents (for checkout) and upload artifacts (which does not require repository write permissions), the safest minimal starting point is permissions: contents: read at the workflow root. This will apply to all jobs that do not override permissions, including windows-msys, windows-msvc, ubuntu-x86, and ubuntu-arm.

The best way to fix this without changing existing functionality is to add a root-level permissions block just after the on: section and before jobs:. That way we do not need to touch each job individually, and all current steps (checkout, build, upload-artifact) continue to work. No additional imports or dependencies are required; this is pure YAML configuration. Concretely, in .github/workflows/build.yml, insert:

permissions:
  contents: read

between the workflow_dispatch: line and the jobs: key. No other changes are necessary.

[cursor]

Cursor Bugbot has reviewed your changes and found 3 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

This PR is being reviewed by Cursor Bugbot

Details

You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[cursor]

CMake targets used before creation on unsupported architectures

Medium Severity

The TARGET_COMPILE_DEFINITIONS calls on qcommon and qcommon_ded at lines 48-49 execute before these targets are created at lines 74 and 77. When CMAKE_SYSTEM_PROCESSOR doesn't match x86, x86_64, aarch64, or arm patterns, CMake configuration will fail with "Cannot specify compile definitions for target which is not built by this project."

Additional Locations (1)

• CMakeLists.txt#L73-L77

 

[cursor]

Release workflow expects non-existent macOS x86_64 artifact

High Severity

The update-release job expects a macos-x86_64 artifact directory, but the macos-x86 job only builds arch: [aarch64] and produces artifact named macos-aarch64. When a release is published, the workflow will fail trying to create idtech3-macos-x86_64.zip from a non-existent directory.

Additional Locations (1)

• .github/workflows/build.yml#L378-L379

 

[cursor]

BUILD_SERVER option not implemented but used in CI

Medium Severity

The CI workflow passes -DBUILD_SERVER=OFF expecting to skip building the dedicated server, but CMakeLists.txt doesn't define this option and always builds the server unconditionally. CMake silently ignores unknown -D options. The idtech3_server binary is built anyway and copied to artifacts via the cp -f build-*/idtech3* bin/ wildcard, including files the CI explicitly intended to exclude.

Additional Locations (1)

• .github/workflows/build.yml#L71-L72