Open AraHaan opened 3 years ago
I believe a great amount of work has gone into not allowing bots to have harmful abilities, this would certainly qualifiy. If someone were to change a workflow to use malicious code (say, by switching a uses
to his own repository), their bot could hijack all the other bots and can completely destroy the repo. I haven't really gone into the full depth of GH actions security, but I've seen a lot of places where they play it safe and I would assume this is one of them.
It also depends on the bot as well. Usually companies that own the bot keeps the bot secured and usually you would think they would not have that issue. I agree some open source bots could possibly get hijacked and somehow secretly add malicious code without the maintainer knowing it. But then again that is why they should review every line of code added and scrutinize it as if it was problematic. However for cases of bots I set up mergify to only look to merge from the bot that is built into github itself (in this case it's dependabot) so I would think it should be save to allow mergify to be able to merge pr's made by dependabot that only updates actions in the workflows.
A common use case is when the github native dependabot is set up to update github actions workflows, that then also gets automated by a github bot (the Merfiy bot).
That bot then contains a specific set of rules:
check-pending
) add theenhancement
label (and optionally some labels specifying the area the changes are to for maintainers of those areas can review by using the label)automerge
(Theautomerge
label could also be added by an maintainer on a repository made from a fork).automerge
label is picked up and then the bot sends a message saying it is about to be merged, approves the changes, then "tries" to actually merge then fail.automerge
label removed upon closure or successful manual merge.Because of this it becomes painful as then the other way to merge (using github actions) becomes needed for automerging dependabot prs) but cannot be used to merge pr's from forks which is what I also want to do out of box only when an maintainer just adds the label in a fast way to try to
batch
PR's together for merge trains (to try to speed up the merging of a ton of prs).