rear
Are all our GitHub Actions safe?
By chance I noticed
https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/
I know basically nothing about GitHub Actions so I can neither check nor verify whether or not all those GitHub Actions that are run for ReaR are safe.
In particular I worry about those GitHub Actions that produce so called "binaries" from our ReaR sources like RPM packages which could be installed by users. Is it safe for our users to install those "binaries" on their systems? Will those "binaries" always contain only our unmodified ReaR sources (i.e. same as "git clone") or might those "binaries" contain modified ReaR sources?
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I don't see any self-hosted runners here: https://github.com/rear/rear/actions/runners?tab=self-hosted . We could also restrict workflow runs for contributors, https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks#about-workflow-runs-from-public-forks , but I can't do that myself (I don't see the Settings tab for the repository).
@pcahyna I will have a look regarding "restrict workflow runs for contributors". I think in case of doubt I prefer to be better too restrictive than too permissive.
At https://github.com/rear/rear/settings/actions under
Fork pull request workflows from outside collaborators
I changed now the current setting
Require approval for first-time contributors
Only first-time contributors will require approval to run workflows.
to the new setting
Require approval for all outside collaborators
Let's wait and see how things behave with that new setting.
How to approve workflow runs is described in https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks#approving-workflow-runs-on-a-pull-request-from-a-public-fork
A different topic regarding GitHub Actions:
At https://github.com/rear/rear/settings/actions in the section
Workflow permissions
in the sub-section
Choose whether GitHub Actions can create pull requests
or submit approving pull request reviews.
the following is currently allowed
Allow GitHub Actions to create and approve pull requests
I wonder why we need that? I don't like it when "bots" (i.e. GitHub Actions) can create and approve pull requests. In particular I dislike the "approve pull requests" part because that means "bots" can change our code on their own by creating a pull request and approve it without any deliberate human decision so it may too easily happen that such a bot request gets "just merged" because the approval looks valid.
So a crucial part would be whether or not it is obvious when a GitHub action bot approved a pull request versus when a human approved a pull request.
he following is currently allowed
Allow GitHub Actions to create and approve pull requestsI wonder why we need that? I don't like it when "bots" (i.e. GitHub Actions) can create and approve pull requests. In particular I dislike the "approve pull requests" part because that means "bots" can change our code on their own by creating a pull request and approve it without any human decision.
Automated creation of PRs looks useful for dependency updates: e.g. #3172 , although that was not submitted by a GitHub Action, it was an external bot .
I don't think we need the "approve pull requests" part, I suppose it is for CI systems like Zuul. I don't think that approving a PR leads to change of the code though, as we don't have any automation to merge approved PRs automatically.
Unfortunately at https://github.com/rear/rear/settings/actions there is only the one choice
Allow GitHub Actions to create and approve pull requests
that can be enabled or disabled as a whole. The wording of the description on that GitHub page
Choose whether GitHub Actions can create pull requests
or submit approving pull request reviews.
is misleading because the 'or' looks as if one could choose for 'create' and 'approve' separately.
If we (at lest currently) do not use any GitHub Actions that create pull requests I could disable
Allow GitHub Actions to create and approve pull requests
as a whole.
@jsmeix sorry, I have not understood that there is a single setting for it, anyway since the dependabot PRs are not created by a GitHub Action and we don't use any other automated PRs, I believe you should disable the setting.
Because in case of doubt I prefer to be better too restrictive than too permissive I disabled now
Allow GitHub Actions to create and approve pull requests
on https://github.com/rear/rear/settings/actions
@pcahyna thank you for your helpful information with this things where I am inexperienced and feel rather uncertain.
Regarding GitHub Actions that produce so called "binaries" from our ReaR sources like RPM packages which could be installed by users, see my initial description here https://github.com/rear/rear/issues/3130#issue-2083394287
Righ now I noticed https://github.com/rear/rear/pull/3278#issuecomment-2238911590 that reads (excerpts):
... Pacman packages ...
How far can we trust third party build environments?
For example I trust the openSUSE Build Service because I know that my employer SUSE pays a lot of attention to keep the openSUSE Build Service build environment sufficiently safe and of course also SUSE's internal build environment where the SLES software is built.
Very likely same for Red Hat's own build environment.
But I know basically nothing about other build environments. This does not mean other build environments are carelessly maintained. It only means that I personally know basically nothing about them.
By chance I noticed CVE-2025-30066 e.g. see https://github.com/advisories/GHSA-mrrh-fwg8-r2c3 which proves that using GitHub Actions is a generic security risk for GitHub projects.
I have no idea if ReaR might be somehow directly or indirectly affected by this particular CVE.
I am in particular interested how far each of the Docker images is trustworthy which are referenced in tools/run-in-docker as
# Define the list of supported images
declare -r IMAGES=(
ubuntu:{20.04,22.04,24.04}
debian:{10,11,12,unstable}
opensuse/leap:15
registry.suse.com/suse/sle15
centos:8 # discontinued
quay.io/centos/centos:stream{9,10}
# registry.access.redhat.com/ubi{7,8,9} basic packages like parted are missing
fedora:{41,42} # rawhide Docker image is broken, see https://github.com/fedora-cloud/docker-brew-fedora/issues/109
archlinux
manjarolinux/base
)
currently online at https://github.com/rear/rear/blob/master/tools/run-in-docker#L12C1-L24C2