Secure "env" configuration - continuation #76
Conversation
|
@joshk I've updated this PR with fix to allow handling arrays for env vars, like: I'm pretty sure that this should be already handled in worker, according to |
|
Also, implementation of decrypting and building matrix is getting kind of messy, so I will look into refactoring it, but I just wanted to send this quick spike, to show the fix and get feedback. |
|
This looks good to me, although i think we need to merge in the changes to travis build first, including the TRAVIS_ stuff, wdyt? |
|
@joshk sure! I didn't have time to finish it and push, I will do that soon. For now, I refactored |
|
@joshk I pushed changes in travis-ci/travis-build#22, travis-ci/travis-worker#31 also will need to be merged (this one is from @laserlemon) |
…nv" configuration
… from travis-build
If you want to encrypt some of the ENV variables, but leave the others
untouched, you need to pass array in config, like:
- env:
- ["FOO=bar", {secure: "encrypted..."}]
Worker can handle such payload, but decrypting and sending such payload was
broken. This commit fixed this situation to allow defining arrays like the one
above.
This is just a start of refactoring matrix related methods. I moved all of those methods to separate class (Matrix::Config) to clean Matrix module.
It can be used instead of config when we want to display config with encrypted
ENV variables in human readable way. For example instead of displaying:
{ :env => [{:secure => "abf8a7bd8e0......."}] }
you may display:
{ :env => ["FOO=[secure] BAR=[secure]"] }
|
@svenfuchs could you take a look on 7b3fe68 and 6cf1e27? @joshk noticed that it will probably look bad to display encrypted vars in the matrix on site, so I added obfuscation to config in the API |
|
@drogus that makes sense to me |
Secure "env" configuration - continuation
|
Is this already usable or is this not yet available on travis-ci.org? |
|
Not yet available, there will be a blog post when it is. On 17/07/2012, at 3:27 PM, Clemens Müller wrote:
|
|
Great! Thanks for the immediate feedback! |
|
I have made a 'node figaro' module (https://github.com/cmanzana/node-figaro) to take this feature into use in node.js applications |
|
@cmanzana Nice!! Looks great! |
|
@svenfuchs @joshk @drogus If not live yet, is there anything I can do to help out? Thanks guys! This looks great. 👏 |
|
This is all deployed and we should have docs on it too :) Thank you sooooo much for helping get this live! Do try it out and let us know how it gets on for you! On 2/10/2012, at 1:36 PM, Steve Richert wrote:
|
|
Fantastic. Will do. 🤘 |
|
@joshk I can confirm it's working, but I had to figure that out myself. I haven't seen any docs for it on the Travis site... |
|
Near the bottom: http://about.travis-ci.org/docs/user/build-configuration/ |
|
I also submitted a pull request to fix Travis encryption through the CLI gem: https://github.com/travis-ci/travis-cli/pull/4 |
I rebased the work that @laserlemon pushed in his pull request (#45) and ensured that
ENVvariables are not decrypted for pull requests.I haven't added
TRAVIS_SECURE_ENV_VARSandTRAVIS_PULL_REQUESTenv vars yet, as I'm not sure what is the best place to do it. For now I addedpull_requestkey to the API and I planned to export those variables in the worker, but I'm not familiar with travis' architecure yet, so I would like to get some feedback for this.The other thing is that I don't like the fact that we need all or nothing approach. If you want to have secure(disregard this paragraph, travis is right, I'm wrong)ENVvars, you need to encrypt all of them and because of that there is no way to set both types of vars. Can I also address it in this pull request? And if yes, have you guys thought about approach to this problem or is this something that hasn't been discussed before?