security

Maintainers now have additional control over when they must approve Actions runs for new contributors.

In April, we shipped an update for GitHub Actions that required maintainers to approve Actions runs for first-time contributors in their repositories. Based on your feedback we have added additional settings to give you more control over this behavior.

Learn more about approving first time contributor pull requests

GitHub actions will now require a collaborator with write access to take action to run workflows from first time users in pull requests.

Learn more about why we are making this change

Learn more about approving first time contributor pull requests

GitHub Actions now lets you control the permissions granted to the GITHUB_TOKEN secret.

The GITHUB_TOKEN is an automatically generated secret that lets you make authenticated calls to the GitHub API in your workflow runs. Actions generates a new token for each job and expires the token when a job completes. The token has write permissions to a number of API endpoints except in the case of pull requests from forks which are always read. These new settings allow you to follow a principle of least privilege in your workflows.

Setting permissions in the workflow

A new permissions key supported at the workflow and job level enables you to specify which permissions you want for the token. Any permission that is absent from the list will be set to none.

permissions:
  actions: read|write|none
  checks: read|write|none
  contents: read|write|none
  deployments: read|write|none
  issues: read|write|none
  packages: read|write|none
  pull-requests: read|write|none
  repository-projects: read|write|none
  security-events: read|write|none
  statuses: read|write|none

Pull requests from public forks are still considered a special case and will receive a read token regardless of these settings.

Setting the default permissions for the organization or repository

A new admin setting lets you set the default permissions for the token in your organization or repository.

You can choose between two options:

• Read/write for all scopes (current default)
• Read repo contents

Setting the default to contents:read is sufficient for any workflows that simply need to clone and build. If you need additional permissions you will need to specify those in your workflow yaml.

Learn more about setting the token permissions

For questions, visit the GitHub Actions community

To see what’s next for Actions, visit our public roadmap

Starting March 1st, 2021 workflow runs that are triggered by Dependabot from push, pull_request, pull_request_review, or pull_request_review_comment events will be treated as if they were opened from a repository fork. This means they will receive a read-only GITHUB_TOKEN and will not have access to any secrets available in the repository. This will cause any workflows that attempt to write to the repository to fail.

This change will affect all repositories, both public and private, regardless of how they are configured, and is being made to prevent potentially compromised dependencies from capturing secrets referenced in your workflows.

If your workflow needs to have a write token or access to secrets, you can use the pull_request_target event; however, please read
Keeping your GitHub Actions and workflows secure: Preventing pwn requests to better understand the risks.

For questions, visit the GitHub Actions community

To see what’s next for Actions, visit our public roadmap

On October 1, 2020, we published a CVE outlining a vulnerability in the set-env and add-path workflow commands feature of GitHub Actions, and announced that we would be deprecating those features. In addition, we began flagging to customers in their Actions logs about the coming deprecation and provided guidance on how to migrate to the replacement functionality.

Specific vulnerabilities introduced by these commands have been patched, but in order to completely close the attack vector we need to disable the set-env and add-path workflow commands.

Security and transparency are essential to maintaining your trust. Therefore, while our investigations show no evidence at this time of this vulnerability being exploited, out of an abundance of caution, we will disable those commands and start failing workflow runs that use them on November 16, 2020.

For details on how to use the new functionality and prevent your workflows from breaking please see https://blog-github-com-develop.go-vip.co/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/.

Update 11/19/2020: Version [v2.274.2](https://github.com/actions/runner/releases/tag/v2.274.2) of the GitHub Actions runner removes support for these commands and has been rolled out across GitHub.

A moderate security vulnerability has been identified in the GitHub Actions runner that can allow environment variable and path injection in workflows that log untrusted data to STDOUT. This can result in environment variables being introduced or modified without the intention of the workflow author.

To allow us to address this issue and maintain the ability for you to dynamically set environment variables we have introduced a new set of files to manage environment and path updates in workflows.

Patching your actions and workflows

If you are using self-hosted runners make sure they are updated to version 2.273.1 or greater.

Action authors who are using the toolkit should update the @actions/core package to v1.2.6 or greater to get the updated addPath and exportVariable functions.

Action and workflow authors who are setting environment variables via STDOUT should update any usage of the set-env and add-path workflow commands to use the new environment files.

If you need to log untrusted information such as issue titles, bodies, or commit messages to STDOUT we recommend that you disable command processing prior to doing that.

As an example in bash you could do the following:

jobs:
  example-job:
    name: example
    runs-on: ubuntu-latest
    steps:
    - name: log untrusted output
      run: |

        # disable command workflow processing
        echo "::stop-commands::`echo -n ${{ github.token }} | sha256sum | head -c 64`"

        # log untrusted output
        echo "untrusted output"

        # enable workflow command processing
        echo "::`echo -n ${{ github.token }} | sha256sum | head -c 64`::"

In a JavaScript Action:

import {v4 as uuidv4} from 'uuid'

// disable workflow commands
const token = uuidv4()
console.log(`::stop-commands::${token}`)

// log untrusted output
console.log("untrusted output")

// enable workflow commands
console.log(`::${token}::`)

For other languages you need to generate a suitably random token that changes with each run.

See Stopping and starting workflow commands to learn more.

Starting today runner version 2.273.5 will begin to warn you if you use the add-path or set-env commands. We are monitoring telemetry for the usage of these commands and plan to fully disable them in the future.

Learn more about CVE-2020-15228

@actions/core npm package

Learn more about the new environment files

For questions please visit the GitHub Actions community forum