Keeping BrowserStack's username/access key encrypted in travis.yml

[akshay-bhardwaj]

Hi,

Can you please update travis.yml to keep BROWSER_STACK_USERNAME & BROWSER_STATCK_ACCESS_KEY encrypted. In order to encrypt them you need to install travis gem and then from angular.js root folder run following commands:

travis encrypt BROWSER_STACK_USERNAME=VojtaJin --add env.global
travis encrypt BROWSER_STACK_ACCESS_KEY= --add env.global
(For reference, please refer: http://about.travis-ci.org/docs/user/build-configuration/)

Finally just remove BROWSER_STACK_USERNAME AND BROWSER_STACK_ACCESS_KEY from travis.yml

I can't submit a pull request for this change, since public key of my fork will differ from yours. So please kindly consider this issue and encrypt the sensitive information in travis configuration file.

Regards,
Akshay Bhardwaj
BrowserStack

[timelf123]

👍

[mgol]

A mere change to existing data won't be enough since the secret key has already been exposed and will live forever in repository history. The only thing that can be done to solve the issue is to generate a completely new key and then put in encrypted here.

[IgorMinar]

@montu We can't encrypt the key because that would not allow us to use the key to test PRs which is the main goal here.

I understand that the current situation is not ideal and we are going to reset the key and remove it from the repo until a solution is found.

Sauce Labs allowed us to use the key in this way since there isn't another good solution out there right now.

We are in discussion with Travis to solve this problem.

@vojtajina can you please reset the browser stack key and remove the old key from our repo. As far as I can tell, we are not using BrowserStack right now.

We still have plans to alternate between BrowserStack and Sauce in our travis builds, but if BrowserStack is not comfortable with the exposure of the key then we'll just stick to Sauce until we can secure the key.

PS: sorry about the response delay!

[dhimil]

@IgorMinar : I agree that you will need un-secure keys for pull requests. Our concern was just that someone could misuse the keys and occupy your parallel limits with BrowserStack causing your genuine tests to starve or even timeout.
Apart from that we don't have any issues.

[vojtajina]

We can't encrypt the keys because encrypted vars don't work with pull requests (it only work when the PR is coming from the same repo which is basically useless for us - I would have to resend every pull request).

I think this is hard problem to solve. There are many issues about it (for instance travis-ci/travis-ci#1459).

I can't think of any other solution than "trust" - Travis could have additional metadata (either outside of the repo or in .travis.yml and locking it - only owner fork can change it). But these people can still do echo $SECRET_VAR.

We should probably just authenticate them with their own credentials so that we have better transparency. BS would allow anybody (with their credentials) and "charge" Angular as long as they are using some Angular id token. We can see who is using it and black list people if they are not nice ;-)

Another solution might be separating the build code. Forks could only change Angular source code but not the build scripts. That would however solve the problem for Angular, but not for projects like Karma or Protractor.

[IgorMinar]

for the benefit of others: we are working with travis/saucelabs/browser stack to solve this problem once and for all... fingers crossed.