Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
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
102 changes: 102 additions & 0 deletions .github/workflows/build-and-push.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,102 @@
name: build & deploy

on:
push:
branches:
- main
- '*'
paths:
- 'script/deploy/safe/ExecutePendingTimelock.Dockerfile'
- 'script/deploy/safe/execute-pending-timelock-tx.ts'
- 'package.json'
- 'package-lock.json'
pull_request:
branches:
- main
paths:
- 'script/deploy/safe/ExecutePendingTimelock.Dockerfile'
- 'script/deploy/safe/execute-pending-timelock-tx.ts'
- 'package.json'
- 'package-lock.json'

env:
context: .
dockerfile: script/deploy/safe/ExecutePendingTimelock.Dockerfile

jobs:
build:
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
Comment on lines +30 to +33
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Second job misses explicit permissions block — tighten token scope
Static analysis flagged this. Add a minimal permissions block to build-branch-dockerfile for parity and least-privilege:

runs-on: ubuntu-latest
permissions:
  contents: read
🤖 Prompt for AI Agents
In .github/workflows/build-and-push.yaml around lines 30 to 33, the second job
named build-branch-dockerfile lacks an explicit permissions block, which reduces
security by granting broader token scopes than necessary. Add a minimal
permissions block under the build-branch-dockerfile job specifying "contents:
read" to restrict token permissions to the least privilege required, matching
the pattern used in the first job.

- name: Checkout repository
uses: actions/checkout@v4

- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
role-session-name: github-actions-role-session
aws-region: ${{ secrets.AWS_REGION }}

- name: Amazon ECR login
id: login-ecr
uses: aws-actions/amazon-ecr-login@v2
with:
mask-password: "true"

- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3

- name: Set current date as env variable
shell: bash
run: echo "UNIQ_ID=$(date +'%y%m%d')-${GITHUB_SHA:0:7}" >> $GITHUB_ENV

- name: Docker meta
id: meta
uses: docker/metadata-action@v5
with:
images: ${{ secrets.ECR_REGISTRY }}/${{ secrets.TIMELOCK_IMAGE_NAME }}
tags: |
type=raw,value=${{ env.UNIQ_ID }}-main
type=ref,event=branch
type=ref,event=branch,prefix=${{ env.UNIQ_ID }}-
type=raw,value=latest
- name: Build and push Docker image
uses: docker/build-push-action@v5
with:
context: ${{ env.context }}
file: ${{ env.dockerfile }}
push: true
platforms: linux/arm64
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}

- name: Inspect image
run: |
docker buildx imagetools inspect ${{ secrets.ECR_REGISTRY }}/${{ secrets.TIMELOCK_IMAGE_NAME }}:${{ env.UNIQ_ID }}-main
build-branch-dockerfile:
if: github.ref != 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- name: checkout code
uses: actions/checkout@v4

- name: set up docker buildx
uses: docker/setup-buildx-action@v3

- name: get short sha
id: vars
run: echo "sha_short=$(git rev-parse --short HEAD)" >> "$GITHUB_OUTPUT"

- name: build docker image (test only)
run: |
docker buildx build \
--no-cache \
--platform linux/arm64 \
-f script/deploy/safe/ExecutePendingTimelock.Dockerfile \
-t image-test:${{ steps.vars.outputs.sha_short }} .
Comment on lines +83 to +102

Check warning

Code scanning / CodeQL

Workflow does not contain permissions Medium

Actions job or workflow does not limit the permissions of the GITHUB_TOKEN. Consider setting an explicit permissions block, using the following as a minimal starting point: {contents: read}

Copilot Autofix

AI 4 months ago

To fix the issue, add a permissions block to the build-branch-dockerfile job. Since this job does not require elevated permissions, the permissions block should specify contents: read as the minimal privilege required. This ensures that the GITHUB_TOKEN is limited to read-only access to repository contents.

The changes will be made in the .github/workflows/build-and-push.yaml file, specifically within the build-branch-dockerfile job definition.


Suggested changeset 1
.github/workflows/build-and-push.yaml

Autofix patch

Autofix patch
Run the following command in your local git repository to apply this patch
cat << 'EOF' | git apply
diff --git a/.github/workflows/build-and-push.yaml b/.github/workflows/build-and-push.yaml
--- a/.github/workflows/build-and-push.yaml
+++ b/.github/workflows/build-and-push.yaml
@@ -84,2 +84,4 @@
     runs-on: ubuntu-latest
+    permissions:
+      contents: read
     steps:
EOF
@@ -84,2 +84,4 @@
runs-on: ubuntu-latest
permissions:
contents: read
steps:
Copilot is powered by AI and may make mistakes. Always verify output.
2 changes: 1 addition & 1 deletion .husky/pre-commit
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ fi
echo ""
echo ""
echo "Running 'bun lint-staged' now:"
bun lint-staged
# bun lint-staged

Comment on lines 15 to 17
Copy link
Contributor

Choose a reason for hiding this comment

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

💡 Verification agent

🧩 Analysis chain

Disabling lint-staged removes an important safety net — reconsider or gate behind an env flag
Commenting out bun lint-staged turns off all staged-file linting/formatting checks, so style or even minor type issues will now reach CI instead of being caught pre-commit. If the motivation is performance or local tool availability, consider:

-# bun lint-staged
+if [ -z "$SKIP_LINT" ]; then
+  bun lint-staged
+fi

Developers can then opt-out with SKIP_LINT=1 git commit …, keeping the default safe.


🏁 Script executed:

#!/bin/bash
# Search for any use of lint-staged in code, config, and scripts
rg -n "lint-?staged"
# Check for lint-staged configuration files
fd -HI ".lintstagedrc*"
fd -HI "lint-staged.config.js"
# Inspect the beginning of the pre-commit hook to confirm context
sed -n '1,30p' .husky/pre-commit

Length of output: 2142


Re-enable lint-staged in pre-commit hook or gate behind an env flag
Commenting out bun lint-staged disables all staged-file lint/format checks. Since you already have a lint-staged config in package.json, it’s better to run it by default and allow opt-out when needed:

• File: .husky/pre-commit (around line 17)
• Update the snippet to:

- echo "Running 'bun lint-staged' now:"
- # bun lint-staged
+ if [ -z "$SKIP_LINT" ]; then
+   echo "Running 'bun lint-staged' now:"
+   bun lint-staged
+ fi

Developers can skip the hook with:

SKIP_LINT=1 git commit …
🤖 Prompt for AI Agents
In .husky/pre-commit around lines 15 to 17, the command `bun lint-staged` is
commented out, disabling lint and format checks on staged files. Re-enable this
command by uncommenting it and add a conditional check to skip running it if an
environment variable like SKIP_LINT is set. This allows lint-staged to run by
default while giving developers the option to bypass it by setting SKIP_LINT=1
before committing.

echo ""
echo ""
Expand Down
36 changes: 36 additions & 0 deletions script/deploy/safe/ExecutePendingTimelock.Dockerfile
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
FROM ubuntu:24.04

WORKDIR /app

# Copy the repo
COPY . .

# Install deps including nodejs (for better compatibility)
RUN apt-get update && apt-get install -y \
build-essential \
python3 \
nodejs \
npm \
libudev-dev \
libusb-1.0-0-dev \
curl \
jq \
sudo \
unzip \
git \
&& rm -rf /var/lib/apt/lists/*

# Install Bun
RUN curl -fsSL https://bun.sh/install | bash
ENV PATH="/root/.bun/bin:$PATH"

Comment on lines +23 to +26
Copy link
Contributor

Choose a reason for hiding this comment

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

💡 Verification agent

❓ Verification inconclusive

Remote install script executed without checksum ⇒ supply version pin or signature check
Piping curl into bash from https://bun.sh/install gives the build root-level code execution with no integrity guarantee. At minimum pin to a specific release tag and verify checksum; ideally fetch the release tarball directly:

ARG BUN_VERSION=1.0.17
RUN curl -fsSL https://bun.sh/install | bash -s -- --version $BUN_VERSION --yes \
 && echo "$BUN_SHA256  /root/.bun/bin/bun" | sha256sum -c -

Pin Bun installer and verify checksum in Dockerfile
Piping the installer script directly from bun.sh without version pinning or integrity checks exposes the build to supply-chain attacks. Please update the Dockerfile as follows:

• Define build arguments for the Bun version and its expected SHA-256 checksum
• Invoke the installer with the --version flag
• Verify the binary’s checksum immediately after installation

Example snippet:

# Install Bun (pinned version + checksum verification)
ARG BUN_VERSION=1.0.17
ARG BUN_SHA256=<insert-official-sha256-here>

RUN curl -fsSL https://bun.sh/install \
      | bash -s -- --version "$BUN_VERSION" --yes \
 && echo "$BUN_SHA256  /root/.bun/bin/bun" | sha256sum -c -

ENV PATH="/root/.bun/bin:$PATH"

– Replace <insert-official-sha256-here> with the checksum published by the Bun maintainers.
– This ensures you’re installing a known, unaltered release.

🤖 Prompt for AI Agents
In script/deploy/safe/ExecutePendingTimelock.Dockerfile around lines 23 to 26,
the Bun installer is run by piping the script directly from the URL without
version pinning or checksum verification, which risks supply-chain attacks. Fix
this by adding build arguments for the Bun version and its SHA-256 checksum,
modifying the install command to specify the version explicitly, and verifying
the installed binary's checksum immediately after installation. Replace the
placeholder checksum with the official one from Bun maintainers to ensure the
installed binary is authentic and unaltered.

# Install Foundry
RUN curl -L https://foundry.paradigm.xyz | bash
ENV PATH="/root/.foundry/bin:$PATH"

RUN foundryup
Comment on lines +27 to +31
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Same integrity concern for Foundry install
For consistency and supply-chain safety, pin the Foundry commit and verify the binary checksum instead of pulling foundryup HEAD each build.

🤖 Prompt for AI Agents
In script/deploy/safe/ExecutePendingTimelock.Dockerfile around lines 27 to 31,
the Foundry installation pulls the latest version without pinning a specific
commit or verifying the binary checksum, which poses a supply-chain security
risk. Modify the Dockerfile to download a specific, fixed commit or release
version of Foundry and include a step to verify the checksum of the downloaded
binary before installation. This ensures consistent builds and improves security
by preventing unverified code execution.

RUN bun install --frozen-lockfile --production
RUN bun run typechain
RUN forge install

ENTRYPOINT ["bun", "run", "script/deploy/safe/execute-pending-timelock-tx.ts"]
20 changes: 0 additions & 20 deletions script/deploy/safe/ExecutePendingTimelockDockerfile

This file was deleted.

Loading