CI services take care of this, as long as you configure permissions correctly.

Travis has secret variables you store in travis.yml. You send the cleartext to Travis, which encrypts it with a private key known only to Travis and sends back to you. You store the ciphertext in the travis.yml, optionally scoped by stage. When travis CI scripts expand the variable, it censors it.

You are correct that a PR could implement something like `send-to-pastebin.sh`. The way to mitigate that risk is to configure travis CI to only run CI against protected branches, and to not provide any secrets to test stages.

It is really only a problem if your test stage requires and includes secret environment variables. I have only seen this in private organizations where the test stage does things like spin up a test S3 bucket. For open source, you would want to use mock S3. The only stage that would need secrets would be release/deploy, for which you can make sure only you can run the command.

Basically: If your open source repository has a test stage that requires secrets, and your CI server injects secrets as environment variables into that test stage, then you need to be extremely careful who can create code that runs in that stage. The best solution is to not have secrets in the test stage at all.

That was a nice complete answer. Thank you. :)

Yes. It's that easy. Sometimes it's already done by a dev. Say in GitLab the CI is pretty good about never revealing env. variables to you once you set them, however devs for debugging purposes will do something like echo $SECRET_PASSWORD and the output will be in the job.

That's why you have code reviews and don't let anyone merge their own code or at least not deploy it themselves.

But that's why I said the test stage. Supposedly there is a step that runs for every single PR.

A lot of open source project have something like that too, where it's a lint checker or unit test runner or whatever.

You shouldn't be able to compromise `prod` from the `test` stage.

Tell that to the CIs with no env var scoping.

But yes, I get what you mean. It seems so weird to me that this scenario can be done.

There's usually some configuration option in your CI for this kind of thing.

With Jenkins+GitHub, for example, I have it configured so PRs from anybody but myself do not automatically run, and I can comment to trigger the build.

Ah that's a nice way to do it!