Continuous integration may reveal your environment variables

Earlier this week Bitbucket announced new features, including Bitbucket Pipelines. Pipelines is a continuous integration service similar to AppVeyor, Travis CI, CircleCI, and others.

If your code depends on environment variables, for example to store database connection strings or API keys, these could be exposed during the build process.

Interestingly Bitbucket Pipelines doesn’t show the value of a environment variable, ever. Instead any instance of value belonging to $AUTH_USER is replaced. This protects against export $AUTH_USER but also does funny things.

Consider this example of building and checking a R package:

* using log directory ‘/opt/atlassian/pipelines/agent/build/..Rcheck’
* using R version 3.3.1 (2016-06-21)
* using platform: x86_64-pc-linux-gnu (64-bit)
* using session charset: UTF-8
* using options ‘--no-manual --as-cran’
* checking for file ‘./DESCRIPTION’ ... OK
* checking extension type ... Package
* this is package ‘examplepkg’ version ‘0.1.2’
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Ellis Valentiner <$AUTH_USER@gmail.com>'

Pipelines noticed AUTH_USER=evalentiner and replaced part of my e-mail with the environment variable key name. Depending on the context, it may not be difficult to decipher the value of $AUTH_USER. Further the log may have contained no other indication that $AUTH_USER even existed!

Don’t print environment variables or sensitive information. That’s pretty obvious but worth saying anyway. Bitbucket decided to try to protect you if you do (or even if you didn’t) but other services, such as Travis, will gladly let you export $AUTH_USER. Even if the values of environment variables are obfuscated, they can reveal themselves through context. Protect your logs as you would your secure keys or code.