Environment Variables are insecure and transferred to new repository owners

I used a github to transfer the repository to the new owner. We test a build and watched it deploy. The Travis CI console showed a successful deploy. The problem is, it deployed to my AWS account using my AWS credentials. The environment variables had been transferred to a third party and were no longer in my control, any fix?

The threat model/paradigm in this particular situation isn’t really an attacker (if an attacker gets into your GitHub account, it’s essentially all over anyway).

The main issue at hand is regarding the secrets. The trivial fix is to wipe secure env vars then change hands. Seems like the most logical and safe thing to do, and unfortunately in this case this didn’t happen.

I’d recommend setting the value from the Travis CLI just to rule everything out travis env set GH_TOKEN <your token>.

If you want to be secret about that token even in your terminal:

read -s NEW_TRAVIS_PASS <enter your password in the empty void> 
cd <directory containing the cloned repo> travis env set 

I’ve seen a similar case, where people don’t clear their env vars before transferring over repositories to new owners. This is the equivalent of wiping a phone before giving it to a new owner, etc. For good measure you can delete the logs with the --delete flag, which optionally takes a reason as an argument:

travis logs --delete DANGER ZONE: Do you really want to delete the build log for travis-
ci/travis.rb#559.1? |no| yes deleting log for travis-ci/travis.rb#559.1 $ travis logs 1.7 --delete "contained c
onfidential data" --force deleting log for travis-ci/travis.rb#1.7

Another way of doing this is using the Travis API via:

curl -X DELETE \
  -H "Travis-API-Version: 3" \
  -H "Authorization: token xxxxxxxxxxxx" \

In turn:


Make sure on their end it’s encrypted again, should look like this:

Travis CI uses a public-key/private-key security system, also known as asymmetric cryptography, to encode and decode sensitive data. When I encrypt env vars in Travis, under the covers, the Travis CLI tool used the public key to do the encryption.

However, decryption can only take place within the Travis CI runtime environment, because only Travis CI has access to the private key.

These are all things you must remember when dealing with env vars and are completely relevant to the Travis CI env vars. It’s no different than Docker. I hope this helps and hopefully this gets you out of hot water, and lesson learned.

Montana Mendy
Travis CI Staff

1 Like

If your AWS credentials got compromised (let’s be real),
you need to change them, or revoke them if it’s an access token.



To say the least. As I stated it’s unfortunate that the env vars were not wiped when the transfer occurred.

1 Like

yeah we sorted out problem this morning, thank you for all the help

I’m curious as how you got this sorted out? - Was it something technical, or a human variable?