We want to hear from you - vote for the features and improvements you'd most like to see, or submit your own ideas if you don't find them already listed.
Secrets may be accidentally printed in the build logs. Travis hide them in the logs masking them as [secret] every time that it finds a match with the provided secrets. See https://discuss.circleci.com/t/masking-secrets-in-output-logs/22231
ran into this today and exposed an aws secret key, expecting behavior of other ci systems. bitbucket pipelines for example protects against this.
I do think the develop team at Circle CI should promote this feature as highest priority for enterprise (pay) users.
I tested with other pipelines, such as bamboo, travis ci, bitbucket pipeline, no secrets can be echo in build logs.
This feature becomes a block when we plan to move our application to production environment, because the developers can easily get the api keys (such as aws, database, apigee, etc) after change the pipeline from the feature branches.
I've voted for this, but just to add more colour to my vote. Because the reason for this proposal is more than just "write sensible scripts", because it's entirely possible code you are testing also accidentally leaks secrets through its test output. And you could keep going enumerating the different paths through which your secret environment variables get accidentally exposed.
Having the CI system as a backstop, replacing secret values in _all_ output, just seems like the right thing to do therefore.
This would absolutely be essential for us.
Really hoping to try out Circle as a Travis replacement however I'm contemplating all the extra adjustments I'll need to make. Currently lean pretty heavily on their secret scrubbing, and I like a good set -x in my builds..
After the adjustments there would be the extra safe guard considerations as an accidental leak would probably go unnoticed and be very bad.
Bitbucket mask the "secret" variables with the variable name. This was actually confusing at first, until I realised what was occurring. I like a combination of both travis and bitbucket. So, after defining an AWS_SECRET_KEY in the environment variables and checking a box that it's a secret, it would be good to mask with something like [PROJECT-SECRET:::AWS_SECRET_KEY]. If I had several secrets and something was going wrong, I'd want to know which secret was which if I was debugging. Also know where the secret came from would be good, project or org/context etc.
You won't be notified about changes to this idea.