You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pekko.apache.org by Arnout Engelen <en...@apache.org> on 2026/01/20 13:05:04 UTC
Allowing PR validation without workflow approval for returning contributors
Hello Pekko community,
Currently, when an outside contributor provides a PR, a committer needs to
verify the PR and click "Approve workflow run" after each change and for
each new PR. I believe this makes the contributing experience worse, as it
leads to longer turn-around times. I would like to propose we configure
GitHub so "Approve workflow run" is only needed for a contributors' first
PR.
The reason "Approve workflow run" is required by default is to protect
against malicious PRs. There are two types of malicious PRs: ones that
merely steal processing power (by for example mining cryptocurrencies
during the build), and ones that steal sensitive resources the GitHub
Actions may have access to. I don't think we need to worry about the first
type: GitHub is pretty good at detecting those, as they typically would not
go through the trouble of first providing a legitimate PR. The second type
we should be more wary of: it is definitely plausible that such an attacker
would first provide a legitimate PR before launching their 'real' attack.
Securing GitHub Actions can be notoriously difficult, for example per
https://cwiki.apache.org/confluence/display/BUILDS/GitHub+Actions+Security.
In the case of Pekko, however, while we do have some secrets exposed to
GitHub Actions (for staging release candidates), we do not use the
dangerous triggers (pull_request_target, issue_comment), and have a mature
RC validation process in place.
In our case I believe it is a reasonable trade-off to allow PR validation
to run without manual approval to improve the contributing experience,
despite the risk of insecure GitHub Actions workflows, which we have
reasonably mitigated.
A special case is that this would also make sure we don't need to manually
confirm validations for PRs created by the public scala-steward instance,
removing the need for our own scala-steward-asf bot. This should make
things simpler and more secure, as the public scala-steward instance
clearly doesn't have access to any of our secrets, which is harder to
guarantee for the scala-steward-asf workflows (see also
https://lists.apache.org/thread/8v1cpvd8y3bo04hy0hn84j5gshcmrfcg).
If there is general (lazy) consensus on this proposal we can ask Infra to
make this change in https://issues.apache.org/jira/browse/INFRA-27565
Kind regards,
--
Arnout Engelen
ASF Security Response
Apache Pekko PMC member, ASF Member
NixOS Committer
Independent Open Source consultant
Re: Allowing PR validation without workflow approval for returning contributors
Posted by PJ Fanning <fa...@apache.org>.
Seems ok to me.
We might need to do regular checks of our CI workflows that have pull_request triggers because those are the most dangerous. We need to regularly review that we are not putting that trigger on anything that works with GitHub secrets.
On 2026/01/21 02:38:17 kerr wrote:
> Yeah, but it will be okay the next time they contribute.
>
> 何品
>
>
> Arnout Engelen <en...@apache.org> 于2026年1月20日周二 21:05写道：
>
> > Hello Pekko community,
> >
> > Currently, when an outside contributor provides a PR, a committer needs to
> > verify the PR and click "Approve workflow run" after each change and for
> > each new PR. I believe this makes the contributing experience worse, as it
> > leads to longer turn-around times. I would like to propose we configure
> > GitHub so "Approve workflow run" is only needed for a contributors' first
> > PR.
> >
> > The reason "Approve workflow run" is required by default is to protect
> > against malicious PRs. There are two types of malicious PRs: ones that
> > merely steal processing power (by for example mining cryptocurrencies
> > during the build), and ones that steal sensitive resources the GitHub
> > Actions may have access to. I don't think we need to worry about the first
> > type: GitHub is pretty good at detecting those, as they typically would not
> > go through the trouble of first providing a legitimate PR. The second type
> > we should be more wary of: it is definitely plausible that such an attacker
> > would first provide a legitimate PR before launching their 'real' attack.
> > Securing GitHub Actions can be notoriously difficult, for example per
> > https://cwiki.apache.org/confluence/display/BUILDS/GitHub+Actions+Security
> > .
> >
> > In the case of Pekko, however, while we do have some secrets exposed to
> > GitHub Actions (for staging release candidates), we do not use the
> > dangerous triggers (pull_request_target, issue_comment), and have a mature
> > RC validation process in place.
> >
> > In our case I believe it is a reasonable trade-off to allow PR validation
> > to run without manual approval to improve the contributing experience,
> > despite the risk of insecure GitHub Actions workflows, which we have
> > reasonably mitigated.
> >
> > A special case is that this would also make sure we don't need to manually
> > confirm validations for PRs created by the public scala-steward instance,
> > removing the need for our own scala-steward-asf bot. This should make
> > things simpler and more secure, as the public scala-steward instance
> > clearly doesn't have access to any of our secrets, which is harder to
> > guarantee for the scala-steward-asf workflows (see also
> > https://lists.apache.org/thread/8v1cpvd8y3bo04hy0hn84j5gshcmrfcg).
> >
> > If there is general (lazy) consensus on this proposal we can ask Infra to
> > make this change in https://issues.apache.org/jira/browse/INFRA-27565
> >
> >
> > Kind regards,
> >
> > --
> > Arnout Engelen
> > ASF Security Response
> > Apache Pekko PMC member, ASF Member
> > NixOS Committer
> > Independent Open Source consultant
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Allowing PR validation without workflow approval for returning contributors
Posted by kerr <he...@gmail.com>.
Yeah, but it will be okay the next time they contribute.
何品
Arnout Engelen <en...@apache.org> 于2026年1月20日周二 21:05写道：
> Hello Pekko community,
>
> Currently, when an outside contributor provides a PR, a committer needs to
> verify the PR and click "Approve workflow run" after each change and for
> each new PR. I believe this makes the contributing experience worse, as it
> leads to longer turn-around times. I would like to propose we configure
> GitHub so "Approve workflow run" is only needed for a contributors' first
> PR.
>
> The reason "Approve workflow run" is required by default is to protect
> against malicious PRs. There are two types of malicious PRs: ones that
> merely steal processing power (by for example mining cryptocurrencies
> during the build), and ones that steal sensitive resources the GitHub
> Actions may have access to. I don't think we need to worry about the first
> type: GitHub is pretty good at detecting those, as they typically would not
> go through the trouble of first providing a legitimate PR. The second type
> we should be more wary of: it is definitely plausible that such an attacker
> would first provide a legitimate PR before launching their 'real' attack.
> Securing GitHub Actions can be notoriously difficult, for example per
> https://cwiki.apache.org/confluence/display/BUILDS/GitHub+Actions+Security
> .
>
> In the case of Pekko, however, while we do have some secrets exposed to
> GitHub Actions (for staging release candidates), we do not use the
> dangerous triggers (pull_request_target, issue_comment), and have a mature
> RC validation process in place.
>
> In our case I believe it is a reasonable trade-off to allow PR validation
> to run without manual approval to improve the contributing experience,
> despite the risk of insecure GitHub Actions workflows, which we have
> reasonably mitigated.
>
> A special case is that this would also make sure we don't need to manually
> confirm validations for PRs created by the public scala-steward instance,
> removing the need for our own scala-steward-asf bot. This should make
> things simpler and more secure, as the public scala-steward instance
> clearly doesn't have access to any of our secrets, which is harder to
> guarantee for the scala-steward-asf workflows (see also
> https://lists.apache.org/thread/8v1cpvd8y3bo04hy0hn84j5gshcmrfcg).
>
> If there is general (lazy) consensus on this proposal we can ask Infra to
> make this change in https://issues.apache.org/jira/browse/INFRA-27565
>
>
> Kind regards,
>
> --
> Arnout Engelen
> ASF Security Response
> Apache Pekko PMC member, ASF Member
> NixOS Committer
> Independent Open Source consultant
>