3 ms·
There are valid reasons for requiring re-approval. A very good example is that a normal looking first commit gets approved. In the next commit the PR author ex
by hashhar 5y ago
There are valid reasons for requiring re-approval.
A very good example is that a normal looking first commit gets approved.
In the next commit the PR author exfiltrates GitHub secrets by base64ing them and logging in the workflow run (or any other way).
Boom - now your CI infra AWS S3 testing bucket, Google BigQuery keys etc. are leaked.
Runtime is also easy to work-around - repeatedly push commits with a execution time limit on the CI workflow to avoid triggering outlier detection.
A trusted PR author today doesn't guarantee trust tomorrow.
Also your trust on some other repo doesn't (and shouldn't) transfer across repos.
> It also would be fair to allow maintainers that do not
> want this load to mark their repos as open-source but
> closed to contributions.
This is already possible.
- mhils 5y ago> In the next commit the PR author exfiltrates GitHub secrets by base64ing them and logging in the workflow run (or any other way). Environment secrets are not exposed to PRs, so this does not work. This really only concerns DoS.
- hashhar 5y agoIIRC I can look at the secret names in the workflow definition then pipe them through `base64 | zip` and have fun. I did this quite some time ago but they may have added better limits in place.
- gray_-_wolf 5y ago> This is already possible. How? I did not find it possible to turn off pull requests when I last looked. Is that something they've added recently?
- __s 5y agoYou're right, likely the OP thought PRs were included in settings where you can disable issues or wikis Discussion: https://github.com/dear-github/dear-github/issues/84 https://github.com/dear-github/dear-github/issues/84
- hashhar 5y agoThanks for correcting me. Looks like I got confused. Though ironically people have used GitHub Actions to auto-close all incoming pull-requests. XD
- sramam 5y agoAny review should be part of the code review process - not the CI build process. If the build is broken, a review is likely to be less reliable.