Approval of Forked PRs to access restricted contexts.
E
Eddie
This would allow OSS projects, or even non-OSS projects using forked PRs to run sensitive jobs upon the approval of an organizational member.This would allow a team member to review the PR for any potentially malicious changes to config or code that would leak secrets.Currently contexts are excluded from forked PRs just like project level secrets. I feel that restricted contexts that consider the actor would address security concerns of roque PRs, while allowing important testing jobs that require tokens to be successfully validated prior to merge.The work-arounds today are overly complex that involve staging to intermediate branches and multiple PRs (one forked, one internal) that move changes from forked PR->Internal branch -> master branch.https://twitter.com/Zephraph/status/1184834013577523201
CCI-I-1202
Justin Bennett
One thought: If maintainers prefer a forked workflow they should just get automatic access to credentials. So if a team member of artsy forks artsy/force, we'd want things that have credential requirements to still work.
i.e. if the user triggering the build has write access to the repo, allow credentials to be passed.