We were storing the Slack secrets on a CircleCI context. Although we were also passing them to forks, it resulted on unauthorized builds for external contributions.
We could work around the issue in two ways:
Having the secrets outside of any context, but that would compromise the security of the associated Slack channel for:
Send messages as @<!---->CircleCI notifications
Send messages to channels @<!---->CircleCI notifications isn't a member of
Upload, edit, and delete files as CircleCI notifications
Using CircleCI logic statements to conditionally run jobs when CIRCLECI_USERNAME or CIRCLE_PR_USERNAMEenv vars are in a list of allowed users. However, that would be something difficult to maintain, and there's no other way to check the user's role.
Given that we don't find those trade-offs to be acceptable, we remove the integration for now.
waiting-for-dev
commented
1 year ago
Summary
We were storing the Slack secrets on a CircleCI context. Although we were also passing them to forks, it resulted on unauthorized builds for external contributions.
We could work around the issue in two ways:
CIRCLECI_USERNAMEorCIRCLE_PR_USERNAMEenv vars are in a list of allowed users. However, that would be something difficult to maintain, and there's no other way to check the user's role.Given that we don't find those trade-offs to be acceptable, we remove the integration for now.
Closes #4902
Checklist
Check out our PR guidelines for more details.
The following are mandatory for all PRs:
The following are not always needed: