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

Author: sashashura

Diff for: .github/workflows/ci.yml

@@ -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