+
Skip to content

[BUG]: pull_request_target without code check-out is false positive #1163

@jrfnl

Description

@jrfnl

Pre-submission checks

  • I am not filing a feature request. These should be filed via the feature request form instead.
  • I have looked through both the open and closed issues for a duplicate report.

zizmor version

1.13.0

Expected behavior

That the pull_request_target workflow trigger is not flagged when the jobs in the workflow do not check out any code.

Yes, I very much realize the danger of pull_request_target, but for some things, it's the only trigger which works and it can be used securely.
Typical example: adding labels to issues/PRs.

Actual behavior

Any workflow using pull_request_target appears to be blindly flagged.

Reproduction steps

Example workflow which - in my opinion - should not be flagged for the use of pull_request_target:

name: Check PRs for merge conflicts

on:
  # Check for new conflicts due to merges.
  push:
    branches:
      - main
  # Check conflicts in new PRs and for resolved conflicts due to an open PR being updated.
  pull_request_target:
    types:
      - opened
      - synchronize
      - reopened
  # Allow manually triggering the workflow.
  workflow_dispatch:

permissions: {}

jobs:
  check-prs:
    runs-on: ubuntu-latest
    if: github.repository_owner == 'MyOrg'

    name: Check PRs for merge conflicts

    permissions:
      pull-requests: write # to label PRs

    steps:
      - name: Check PRs for merge conflicts
        uses: eps1lon/actions-label-merge-conflict@1df065ebe6e3310545d4f4c4e862e43bdca146f0 # v3.0.3
        with:
          dirtyLabel: "Status: has merge conflict"
          repoToken: ${{ secrets.GITHUB_TOKEN }}

Here's another example:

name: Label new PRs

on:
  # https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target
  # The `pull_request_target` event is used for "normal" PRs to label them when they are opened.
  # This will use the `labeler.yml` file in the default branch of the repo.
  pull_request_target:
    types:
      - opened
      - ready_for_review

  # The `pull_request` event is used for PRs which change the files which handle the labelling to prevent a silently failing action.
  # This will use the `labeler.yml` file in the PR branch.
  pull_request:
    paths:
      - '.github/workflows/label-new-prs.yml'
      - '.github/labeler.yml'

jobs:
  label-new-prs:
    runs-on: ubuntu-latest
    if: github.repository_owner == 'MyOrg' && github.event_name == 'pull_request_target'

    name: Add labels to new PRs

    steps:
      - name: Label new PRs
        uses: srvaroa/labeler@v1
        env:
          GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"

  validate-labeler-worflow:
    runs-on: ubuntu-latest
    if: github.repository_owner == 'MyOrg' && github.event_name == 'pull_request' && github.event.pull_request.merged == false

    name: Validate changes to Labeler logic

    steps:
      # Checkout is needed to use the `use_local_config` option.
      - name: Checkout code
        uses: actions/checkout@v5

      - name: Verify changes to the labeling logic
        uses: srvaroa/labeler@v1
        with:
          use_local_config: true
          fail_on_error: true
        env:
          GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"

Logs


Additional context

I did find some loosely related issues, but those are all closed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载