As it’s open-source, I’m inviting public contributors to it quite often. This results in the fact that most of the incoming PRs are from forks.
PRs are not allowed to be merged before the Bitrise build succeeds. This means that I have to approve all their builds manually, every single time. You can imagine that this is both frustrating for them and for me.
Especially because I’m simply approving each build and I never see the need to not approve them.
Also, why isn’t it just possible for the Bitrise user to decide whether approval is needed or not? I can see the option but I’m not able to turn it off.
Use case / for what or how I would use it
I think it’s already quite clear why I need this feature
This is due to security reasons. Approval is always needed for public Bitrise apps and cannot be turned off Bitrise Blog
For example one can have Github API token used by Danger step in PR workflow exposed as an environment variable (it needs to have a permission in order to post comments: Getting Set Up).
Malicious user may create a PR with change in build.gradle which dumps all the environment and sends it somewhere.
If you have any Secret exposed to the PR from the fork we need an approval so that you first ensure that the PR does not try to steal those secrets in any way.
My question is: do you have a secret which is exposed for PRs? If you don’t that might need some inspection from our side, but if you do then it’s working as intended (protecting you).
Yes, I do. We’re using Danger. However, I’m surprised this is a security issue as other CI tools are allowing this. Is this just a lack of security from other CI tools?
Either way, I now understand a bit better why this is but I would still love to get rid of having to accept each build manually
If you use Danger and you set a GitHub Access Token as the secret, if Bitrise would automatically run the build (for my theoretical fork PR) without an approval from you first, then I could send you a PR that simply gets this secret and sends it to myself e.g. via email or such.
Danger recommends the public_repo GitHub Access Token scope ( Getting Set Up ), which means:
Limits access to public repositories. That includes read/write access to code, commit statuses, repository projects, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories.
If a CI allows this (exposing secrets in fork PRs without a manual approval first), that’s a serious security issue in case of open source repos where anyone can send PRs from forks.
Most CIs don’t even allow you to expose secrets for fork PRs (like @koral linked at Disable manual approval for public repositories - #6 by koral ); with Bitrise we wanted to give you the option but only in a secure way which requires an approval before running the build, which is unfortunately the only secure way of doing this.
I’d love to have a better option, but AFAIK there’s no better one that’s still technically 100% secure
Thanks a lot for your detailed explanation, it makes so much more sense to me now!
We’ve been using Travis CI before and we never had to manually approve incoming builds.
Whenever I’m in the occasion of finding a solution to this, I’ll revisit this topic!
