Protected secrets are printed in logs when used as arguments to xcodebuild

Secrets are assigned as environment variables in the arguments for xcodebuild, in order for xcode to recognise them. However, they are printed plaintext in the logs when xcodebuild’s arguments are printed. This exposes them to other members of the team, who may have access to those logs.

The secrets are protected. The setting for the individual secret of “Replace variable in input”, if initially set to off, will set itself to on again at the next build.

A solution may be to mimic travis, which redacts any secure variables it finds in the logs

1 Like

Perfect timing with the question @BlueDrink9! :smiley:

The latest CLI, which was just released, includes this feature: Monthly release of Bitrise CLI tools and summary of updates (April, 2018) - CLI v1.15.0

This CLI version will be available on this weekend as usual (following weekend after the CLI release). Feel free to set the related secret as described in the announcement and it’ll enable filtering right away once v1.15.0 is deployed on

Keep in mind this is an experimental feature which will not be enabled this month, at least not right away after the deploy (disabled by default in the CLI). We plan to enable it before the next CLI release for everyone by default, but if there’s any issue we might only enable it at the next CLI release for everyone. You can of course enable it for yourself, the way mentioned in the announcement, and this feature is expected to be enabled by default in the next CLI release :slight_smile:

If you’d have any questions just let us know! :wink:

Brilliant! How good. A few questions/clarifications:

  • The docs say to add BITRISE_SECRET_FILTERING to secrets but it just needs to be an env variable, right?
  • Does this apply retroactively?
  • Does this prevent a collaborator removing the env variable then re-running/scheduling a new build with the secrets?

Thanks for the rapid response.

1 Like

No, right now it has to be in the Secrets. In the next release it will be enabled by default and turning it off will be possible via env var (which is set before the bitrise cli process, so it can’t be an env var specified in the config), Secrets (just like now) and bitrise CLI flag as well. But for now it can only be enabled via Secrets.

No, the filtering is done by the CLI itself, real time. The advantage is that this way the non filtered logs are not stored and not available for any tool, not for the website and not even in the build. The CLI (the open source “runner” which performs the builds / executes the build config inside a VM : ) runs the commands in a way that all command outputs on StdOut & StdErr are go through the CLI’s filtering algorithm and only after that are printed / made available on any output.

No, it does not. If this secret is set when the build starts then the filtering mode will be enabled in that build. If you then remove it, the next build will run without filtering. Can be enabled/disabled any time.

Any time, we’re always happy to answer any questions you have :wink: