python-stdnum
python-stdnum copied to clipboard
Automatically update GitHub Actions in the future
If I understand correctly this updates the actions file within Github. The problem is that the Github Git repository is a mirror of the upstream one at https://arthurdejong.org/git/python-stdnum which means that any changes directly on Github will automatically get overwritten whenever a new commit is pushed.
I'm also not very happy with the security model where a Github action have write access to the repository. Github actions are used to run builds for e.g. pull requests and other code that is not (yet) part of the repository. Giving the action write access seems like the security is the wrong way around.
If there was some way to have Github automatically create a pull request (like sometimes seems to happen for security issues) that would be fine.
Dependabot creates merge requests, whether to update GitHub Actions or to update other dependencies. These are not fully automatic updates.
Dependabot is not a GitHub Action as far as I can tell. Strictly speaking, you wouldn't be giving write access to a GitHub Action. But I get the idea. Fortunately, Dependabot creates pull requests, it does not write into the repository. Furthermore, Dependabot is a GitHub product. If Dependabot was malicious, the whole GitHub workflow could be malicious. At some point, you need to trust a few providers, to a certain degree: the provider of the CPU, motherboard or whole computer, the provider of the operating system, the provider of the compiler or the interpreter. I agree the list should be kept limited. However, I suppose we already trust GitHub, to some extent.
By the way, you are absolutely right, GitHub Actions can be as dangerous as any random application in any “store” – the Apple Store, the Microsoft Store, PyPI, CRAN, etc. Fortunately, you can limit the permissions of workflows or jobs with permissions
, providing for example only read access to GitHub Actions you do not fully trust. I could add permissions
to all CI jobs in file .github/workflows/test.yml
in a separate merge request.
It seems that Dependabot makes the PRs by creating a branch in the repository (instead of normally via a fork). This means that when the branches are synchronised they automatically get removed (e.g. see https://github.com/arthurdejong/webchat/pull/7 that got automatically closed because the corresponding branch got removed).
It also seems that Dependabot has write access to the repository regardless of what permissions you assign to Github Actions (in the example above Github Actions only should have read-only access to the repository).
Do you have any idea how to resolve this? I'd be happy to exclude refs/heads/dependabot
from the git push
but I can't find a way to configure this exception.
I was merely referring to permissions as a way to mitigate the risk of running 3rd party GitHub Actions. However, Dependanbot is not a GitHub Action, so GitHub Actions permissions have no influence on Dependabot itself.
Dependabot being a GitHub product, I wouldn't worry too much about giving Dependabot itself write access to the repository, because you implicitly trust GitHub by using their Git servers. I may be mistaken, but it seems to me that if GitHub were compromised or malicious, the attackers or GitHub would be able to write to this repository in a much more straightforward way. They don't need Dependabot for that.
The only issue that I can see here is that:
- a 3rd party GitHub Action maintainer could be compromised or malicious,
- the attacker could update the 3rd party GitHub Action, adding malicious code,
- the update would trigger a PR in this repository, not in a fork,
- this PR could trigger CI jobs, before you have a chance to review the updated GitHub Action,
- CI jobs running the updated and hostile GitHub Action could write to the repository.
I'm not sure yet to what extent a hostile GitHub Action run from a CI job associated to a specific branch could damage the whole repository. Is that what you want to avoid? In any case, giving the 3rd party GitHub Action read-only permissions mitigates the risk.
Also, I don't know whether CI jobs are automatically run for Dependabot PRs, or if you have to trigger them yourself.
Have I correctly understood your security concerns?
Thanks for the details. I think most security concerns are mostly addressed. It is still a bit weird what Github and Dependabot do and don't do with your repositories and projects.
A practical problem I have now with Depenadabot creating branches in my repository for pull requests is that these will be automatically removed when Git branches and commits are synced from the main Git repository (there are a number of Git repositories that are automatically kept in sync). If the branch is removed the PR is automatically closed.
Some Dependabot updates are available in the security section on Github as Dependabot alerts. Do you know if the updates that would be noted by this would also show up somewhere (other than in PRs which could end up getting closed)?
I agree, it would be nice if GitHub had a document with details of how GitHub modify (or even simply read) hosted repositories, using their admin status. I haven't found such a document yet.
Indeed, if the sync process erases branches created by Dependabot, this merge request won't help. I now understand what you meant by “exclude refs/heads/dependabot
from the git push
”. I don't have enough experience to help achieve that, especially without seeing the actual details of your sync process. Perhaps the following can help:
- About protected branches
- Managing a branch protection rule
- Git: how can I exclude just one branch from push?
I haven't played enough with Dependabot to help, but Configuration of Dependabot alerts might give some clues. As far as I can see, alerts can only be associated to vulnerable dependencies.