mirror of
https://github.com/openharmony/third_party_rust_regex.git
synced 2026-06-30 21:37:57 -04:00
ci: harden configuration
This makes it so the permissions are locked down by default. The threat model here is something like, "what happens if an authorized party gains control of the non-PR CI configuration somehow." To be honest, I (BurntSushi) don't quite understand how that might happen without also the ability to set the permissions itself. But locking permissions down by default does seem like a good and sensible thing to do. Closes #932
This commit is contained in:
@@ -6,6 +6,27 @@ on:
|
||||
- master
|
||||
schedule:
|
||||
- cron: '00 01 * * *'
|
||||
|
||||
# The section is needed to drop write-all permissions that are granted on
|
||||
# `schedule` event. 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 or compromised third party tool or
|
||||
# action) is restricted. Currently the worklow doesn't need any additional
|
||||
# permission except for pulling the code. Adding labels to issues, commenting
|
||||
# on pull-requests, etc. may need additional permissions:
|
||||
#
|
||||
# Syntax for this section:
|
||||
# https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions
|
||||
#
|
||||
# Reference for how to assign permissions on a job-by-job basis:
|
||||
# https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
|
||||
#
|
||||
# Reference for available permissions that we can enable if needed:
|
||||
# https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
|
||||
permissions:
|
||||
# to fetch code (actions/checkout)
|
||||
contents: read
|
||||
|
||||
jobs:
|
||||
test:
|
||||
name: test
|
||||
|
||||
Reference in New Issue
Block a user