Skip to content
Closed
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
16 changes: 16 additions & 0 deletions .github/workflows/devkit-power-on.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
name: Devkit Power On

on:
pull_request:
branches: ['main']
paths:
- '.github/workflows/devkit-power-on.yml'

Comment on lines +3 to +8
Copy link

Choose a reason for hiding this comment

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

Bug: The workflow is configured to trigger only on changes to its own file, making it impossible to run after the initial pull request is merged.
Severity: HIGH

Suggested Fix

Replace the pull_request trigger with workflow_dispatch. This will allow users to manually run the workflow from the GitHub Actions UI whenever the devkit needs to be powered on, aligning the trigger mechanism with its operational purpose.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: .github/workflows/devkit-power-on.yml#L3-L8

Potential issue: The `devkit-power-on.yml` workflow is configured to trigger on
`pull_request` events with a `paths` filter that only includes its own file. This means
the workflow will run once when this pull request is merged, but it will become
impossible to trigger again in the future. Since the workflow's purpose is to power on a
devkit—an operational task that needs to be performed on-demand—this trigger
configuration renders it non-functional for its intended use after the initial merge.
The commit message suggests the `workflow_dispatch` trigger was intended but was
replaced for testing.

Did we get this right? 👍 / 👎 to inform future reviews.

jobs:
power-on:
name: Power on devkit
runs-on: [self-hosted, playstation, windows, x64]
timeout-minutes: 10

steps:
- run: prospero-ctrl power on
Comment on lines +11 to +16

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: {}

Copilot Autofix

AI 2 days ago

To fix the problem, explicitly set permissions so the GITHUB_TOKEN has only the minimal required access. Since this job only runs prospero-ctrl power on and does not touch repo contents, we can safely set contents: read at the job (or workflow) level. This documents the intended permission level and prevents unintentional escalation if repository defaults change.

The best fix with no behavior change is to add a permissions block under the power-on job definition in .github/workflows/devkit-power-on.yml. Insert it alongside runs-on and timeout-minutes. For example, between runs-on (line 12) and timeout-minutes (line 13), add:

    permissions:
      contents: read

No additional imports, methods, or definitions are needed because this is a YAML configuration change only.

Suggested changeset 1
.github/workflows/devkit-power-on.yml

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/devkit-power-on.yml b/.github/workflows/devkit-power-on.yml
--- a/.github/workflows/devkit-power-on.yml
+++ b/.github/workflows/devkit-power-on.yml
@@ -10,6 +10,8 @@
   power-on:
     name: Power on devkit
     runs-on: [self-hosted, playstation, windows, x64]
+    permissions:
+      contents: read
     timeout-minutes: 10
 
     steps:
EOF
@@ -10,6 +10,8 @@
power-on:
name: Power on devkit
runs-on: [self-hosted, playstation, windows, x64]
permissions:
contents: read
timeout-minutes: 10

steps:
Copilot is powered by AI and may make mistakes. Always verify output.
Comment on lines +6 to +16
Copy link

Choose a reason for hiding this comment

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

Bug: The pull_request trigger on a self-hosted runner allows forks to execute arbitrary code on the physical devkit by modifying the workflow file in their pull request.
Severity: CRITICAL

Suggested Fix

Avoid running workflows from forks on self-hosted runners. Change the trigger to pull_request_target and ensure you explicitly check out code from a trusted source, not the PR head. Alternatively, restrict this workflow to run only on internal branches and not from public forks, or use ephemeral Just-In-Time (JIT) runners that are destroyed after each job.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: .github/workflows/devkit-power-on.yml#L3-L16

Potential issue: The new workflow `devkit-power-on.yml` is configured to run on a
`self-hosted` runner (`playstation` devkit) when a pull request is opened. Since the
repository is public, an attacker can fork it, add malicious commands to their version
of `devkit-power-on.yml`, and open a pull request. GitHub will execute the attacker's
modified workflow, granting them arbitrary code execution on the physical devkit. This
could be used to disrupt development, damage the hardware, or exfiltrate credentials.
The `paths` filter on the workflow file itself facilitates this attack vector.

Loading