feature: Workflow to release new versions to S3 automatically

[sfc-gh-ddas]

No description provided.

To fix this, explicitly declare minimal GITHUB_TOKEN permissions for the workflow. The simplest, least-disruptive way is to add a permissions block at the top (workflow) level, right after the on: block, so it applies to all jobs. None of the shown steps need to write to the repo, manage PRs, or interact with other GitHub APIs, so contents: read is sufficient.

Concretely:

• Edit .github/workflows/release.yml.
• After the on: section (after line 12), insert:

permissions:
  contents: read

This will restrict the automatically provided GITHUB_TOKEN for all jobs in this workflow to read-only access to repository contents, satisfying CodeQL’s requirement while preserving existing functionality.

In general, fix this by explicitly restricting the GITHUB_TOKEN permissions in the workflow using a permissions block, either at the workflow root (applies to all jobs unless overridden) or per job. Since all shown jobs just check out code, build artifacts, configure AWS, and upload artifacts, they only need read access to repo contents; no write or additional scopes are required.

The best minimal change is to add a workflow-level permissions block right after the name: and before on: in .github/workflows/release.yml:

• Set permissions: contents: read at the top level so all jobs, including build-and-upload-linux-aarch64 (line 50), inherit this restriction.
• This does not alter any of the existing steps or their behavior, because they only require reading the repository.
• No imports or additional methods are needed; this is a pure YAML configuration change.

Concretely:

• Edit .github/workflows/release.yml around lines 1–4.
• Insert:

  permissions:
    contents: read

  between name: Build and Upload Release and the on: block.

In general, the fix is to add a permissions: block that constrains the GITHUB_TOKEN to the minimum needed, either at the root of the workflow (to apply to all jobs) or at each job that needs special permissions. Since none of the shown jobs needs to write to the repository, setting contents: read at the workflow level is sufficient and safest.

The single best fix without changing functionality is: at the top of .github/workflows/release.yml, add a root‑level permissions: block right after the name: line (and before on:). This will apply to all jobs (build-and-upload-linux-x86_64, build-and-upload-linux-aarch64, build-and-upload-macos, build-and-upload-windows, verify-upload, etc.) that do not override permissions. The minimal secure starting point suggested by CodeQL is contents: read, which is enough for actions/checkout@v4 to work and does not interfere with AWS credentials or artifact uploads, since those use secrets and separate services rather than GITHUB_TOKEN.

No additional imports, methods, or other definitions are needed; only the YAML permissions: stanza must be added.

In general, to fix this class of issue you add an explicit permissions: block at the workflow level (affecting all jobs) or at specific jobs, reducing the GITHUB_TOKEN to the minimal scopes required. For pure build/test/upload workflows that don’t need to write to the repo or to PRs, contents: read is usually sufficient.

For this specific file, none of the jobs perform repository write operations via GITHUB_TOKEN; they only check out code, configure AWS using secrets, run build scripts, and upload artifacts to S3 and as build artifacts. actions/checkout@v4 works with contents: read. Therefore the safest and simplest fix is to add a single workflow-level permissions: block with contents: read. This will apply to all jobs (build-and-upload-linux-*, build-and-upload-macos, build-and-upload-windows, and verify-upload) without changing their intended behavior.

Concretely:

• Edit .github/workflows/release.yml.
• Insert a workflow-level permissions: section after the name: (line 1) and before the on: block (line 3).
• Set contents: read as the only permission. No additional imports or dependencies are required.

To fix the issue, explicitly define minimal GITHUB_TOKEN permissions for this workflow so that jobs do not inherit potentially broad repository defaults. The safest and simplest approach is to add a top-level permissions: block that applies to all jobs. These jobs only need to read the repository (for actions/checkout) and do not push, modify issues, or interact with pull requests, so contents: read is sufficient. Adding this block immediately under the workflow name: (before on:) keeps behavior unchanged while constraining the token.

Concretely:

• Edit .github/workflows/release.yml.
• After line 1 (name: Build and Upload Release), insert a permissions: block:
  • contents: read
• No other changes are required; no job-specific blocks are necessary because the root-level block will apply to all jobs that do not override it.
• No imports or additional definitions are needed, since this is purely a YAML configuration change.

[semgrep-app-snowflakedb]

Semgrep identified an issue in your code:
Using variable interpolation ${{...}} with github context data in a run: step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. github context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with env: to store the data and use the environment variable in the run: script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

To resolve this comment:

✨ Commit Assistant fix suggestion

Suggested change

	run: |
	if [[ "${{ github.ref }}" == refs/tags/* ]]; then
	VERSION=${GITHUB_REF#refs/tags/v}
	else
	VERSION="${{ github.event.inputs.version }}"
	fi
	echo "version=$VERSION" >> $GITHUB_OUTPUT
	echo "Checking for version: $VERSION"
	env:
	VERSION_INPUT: ${{ github.event.inputs.version }}
	run: |
	if [[ "${{ github.ref }}" == refs/tags/* ]]; then
	VERSION=${GITHUB_REF#refs/tags/v}
	else
	VERSION="$VERSION_INPUT"
	fi
	echo "version=$VERSION" >> $GITHUB_OUTPUT
	echo "Checking for version: $VERSION"

View step-by-step instructions

1. Move the usage of ${{ github.event.inputs.version }} into an environment variable by adding it under env: in the step.
2. Reference that environment variable inside your shell script with double quotes, e.g., "$VERSION_INPUT", instead of using the GitHub context directly in run:.
3. Update the script so that the assignment in the else clause uses VERSION="$VERSION_INPUT".

For example:

• Add VERSION_INPUT: ${{ github.event.inputs.version }} under env:.
• Update the step like this:

  run: |
    if [[ "${{ github.ref }}" == refs/tags/* ]]; then
      VERSION=${GITHUB_REF#refs/tags/v}
    else
      VERSION="$VERSION_INPUT"
    fi
    echo "version=$VERSION" >> $GITHUB_OUTPUT
    echo "Checking for version: $VERSION"
  

This change prevents user-controlled input from being interpreted directly by the shell, reducing the risk of shell injection vulnerabilities.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by run-shell-injection.

_{You can view more details about this finding in the Semgrep AppSec Platform.}