git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH] ci: restrict workflow's github token permissions

From
AGAlex via GitGitGadget <gitgitgadget@gmail.com>
Date
Sep 22, 2022, 07:27 UTC
Message-ID
<pull.1337.git.git.1663831649705.gitgitgadget@gmail.com>
From: sashashura <aleksandrosansan@gmail.com>
Currently the workflow runs with the following permissions:
GITHUB_TOKEN Permissions
  Actions: write
  Checks: write
  Contents: write
  Deployments: write
  Discussions: write
  Issues: write
  Metadata: read
  Packages: write
  Pages: write
  PullRequests: write
  RepositoryProjects: write
  SecurityEvents: write
  Statuses: write
Signed-off-by: sashashura <aleksandrosansan@gmail.com>
---
    ci: restrict workflow's github token permissions
    
    This PR adds explicit permissions section
    [https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions]
    to workflows. This is a security best practice because by default
    workflows run with extended set of permissions
    [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token]
    (except from on: pull_request from external forks
    [https://securitylab.github.com/research/github-actions-preventing-pwn-requests/]).
    By specifying any permission explicitly all others are set to none. By
    using the principle of least privilege the damage a compromised workflow
    can do (because of an injection
    [https://securitylab.github.com/research/github-actions-untrusted-input/]
    or compromised third party tool or action) is restricted. It is
    recommended to have most strict permissions on the top level
    [https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions]
    and grant write permissions on job level
    [https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs]
    case by case.
    
    check-whitespace.yml is triggered by pull_request only and receives
    restricted token already. l10n.yml has permissions on job level already.
    So I didn't make any changes to them. In both cases it is possible to
    add explicit global lever permissions just for consistency if you
    prefer. Let me know.
    
    Currently
    [https://github.com/git/git/actions/runs/3100948073/jobs/5021781329] the
    workflow runs with the following permissions: GITHUB_TOKEN Permissions
    Actions: write Checks: write Contents: write Deployments: write
    Discussions: write Issues: write Metadata: read Packages: write Pages:
    write PullRequests: write RepositoryProjects: write SecurityEvents:
    write Statuses: write
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1337%2Fsashashura%2Fpatch-2-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1337/sashashura/patch-2-v1
Pull-Request: https://github.com/git/git/pull/1337
 .github/workflows/main.yml | 6 ++++++
 1 file changed, 6 insertions(+)
diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 831f4df56c5..3ce9302c589 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -5,8 +5,14 @@ on: [push, pull_request]
 env:
   DEVELOPER: 1
 
+permissions:
+  contents: read
+
 jobs:
   ci-config:
+    permissions:
+      contents: read
+      actions: read # for github.actions.getWorkflowRun
     name: config
     runs-on: ubuntu-latest
     outputs:

base-commit: dda7228a83e2e9ff584bf6adbf55910565b41e14
-- 
gitgitgadget
Next: Phillip Wood
Message 1 of 2 in “ci: restrict workflow's github token permissions”
  1. ci: restrict workflow's github token permissionsAlex via GitGitGadget, Sep 22, 2022
  2. Phillip WoodSep 22, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.