IMHO, It is not wise to drop leading white spaces or any white spaces for that matter. There may be a real need to have those white spaces in the value. Only the second proposed solution makes sense.

export quoted=' this is a test '
export escaped=\ this\ is\ a\ test\ 
echo "*$quoted*"
echo "*$escaped*"

Both approaches get the correct output. The '*' guards are added just for display purposes.

* this is a test *
* this is a test *

Could you point to a legitimate use case of environment variables where the leading white space is required? I am of the opinion that it is more likely to be a user error than not.

This is just a hypothetical situation. Let's say, I want to specify a SUPER_SECRET environment variable to have this value my secret. Note the string literal has a space in between. Without proper escaping or quoting when exporting it, the end result will be wrong anyway.

export SUPER_SECRET=my secret
echo "*$SUPER_SECRET*"

Output:

*my*

If the risk of exposing the value is what you concern here then you can safe-guard that using stderr redirection, like so.

export SUPER_SECRET= 12345 2>/dev/null

The not a valid identifier error message is still being sent out but it now redirected to a null device instead of terminal output, in this case your log file.

EDIT: Thus, you may probably want to employ both quoting/escaping + stderr redirection.

Hmm. I am still not convinced. If a user needs spaces in their environment variables, secure or otherwise, it is easy to inject them by putting the value in quotes; e.g., https://travis-ci.org/BanzaiMan/travis_production_test/builds/68571201#L97 (Here, I put ' SPACE THE FINAL FRONTIER' as the value of the secret environment variable.)

Redirect to /dev/null might be a good idea, though.

Fair enough. Having said that, normally I would not trust my user input. So, properly quoting or escaping the user input before injecting it into my script is a proper thing to do. In the context of Travis worker VM, if a malicious user could find a way to inject other code to be executed in the escalated privilege, I suppose the user is just hurting him/herself as the VM image is only used by that one user before the VM image is reverted back to the original snapshot. Hopefully the exploit stops there and not breach further into the container. Too far fetch may be 😄.

EDIT: have anybody tried to put this in the value dummy; sudo rm -rf /

If the user wants to run sudo rm -rf on the VM, there is nothing that stops them. And there are more direct ways to do it.

Yes, I know that. That is just one of the stupid example payload for user to shoot himself in his foot, but only when you are sure he cannot breach further in. Anyway, this is just hypothetical. I am a very happy Travis CI user so I cannot think of any reason to do anything nasty.

I agree we should just trim leading/tailing whitespace when we store the variable.

@drogus any chance you could have a look? I've tried making sense out of the Virtus stuff, and couldn't quite figure it out quickly.

I think we have two different problems here: an UI issue and a security issue.

The UI is not very friendly, it don't warn you about a no scaped string and neighter show you some tips about how it works.
The security issue is a rebealed secure variable.

$ export SONATYPE_NEXUS_PASSWORD=[secure]
/home/travis/build.sh: eval: line 41: syntax error near unexpected token `)'
/home/travis/build.sh: eval: line 41: `export SONATYPE_NEXUS_PASSWORD=>~1I)"K&F'gb'&D'

I saw this issue with my old password: >~1I)"K&F'gb'&D. (Notice that it's old because Travis reveal it). So it's not only a problem with white spaces.

@BraisGabin That sounds like a separate issue entirely, though. Yours is a case where the use of special characters resulted in revelation of the value. It is true, however, that we should do a better job of explaining how the values are processed.

I was thinking about open a new one. I didn't because the main problem is the same: scape special characters like white space or ". Anyway, I can open a new issue if it's better for you guys.

Any updates on this issue?

I am having this problem as my password is something like 1&k and I am getting the following error:

$ export MY_PASSWORD=[secure]
/home/travis/build.sh: line 45: k: command not found

I'd guess it is caused by the & char.

My build system is the following

Using worker: worker-linux-ab06560a-2.bb.travis-ci.com:travis-linux-18
system_info
Build system information
Build language: android
Build group: stable
Build dist: precise
Build image provisioning date and time
Wed Apr 22 12:23:44 UTC 2015
Operating System Details
Distributor ID: Ubuntu
Description:    Ubuntu 12.04 LTS
Release:    12.04
Codename:   precise
Linux Version
2.6.32-042stab090.5

@felipesabino In your case, quoting is best. '1&k…'

This is actually not just a theoretical problem.
I accidentally exposed my github api key in the travis logs because the representation github includes a leading space when copying it.

The same problem occurs when a variable name contains a dot .
Pls, fix this, it's more like a security issue - https://www.google.pl/#q=site:travis-ci.org+%22not+a+valid+identifier%22

OMG, serious security issue when builds are indexed by Google! I can see all my passwords in the logs.

+1 for bumping the severity of this issue. I just inadvertently exposed my AWS secret key by copying and pasting it with extra spaces.

Specifically, I was following the instructions for uploading build artifacts:

https://docs.travis-ci.com/user/uploading-artifacts/

I set an ARTIFACTS_SECRET environment variable with value G4/OCR5M0NNeclOn6x0BrMz65UpCdJgndrjYrX97, copied and pasted from the AWS console. Note inadvertently copied space at the front. I got this in the build:

$ export ARTIFACTS_SECRET=[secure]
/home/travis/build.sh: line 45: export: `G4/OCR5M0NNeclOn6x0BrMz65UpCdJgndrjYrX97': not a valid identifier

(Note I've of course generated a new secret key value.)

+1 for bumping the severity of this issue.

+1

Just had the exact same issue, although just a token was exposed that can be regenerated. I was not aware of unwanted whitespaces that inadvertently got added in front of the real secret key.

As a security issue, this should definitely be addressed, hard to believe this has been pending for over one year already.

+1

I had a related issue with a setting that was URL-like with < and # in it.

The generated script should properly escape any embedded double-quotes in the setting string, and then double-quote that value. That way it will correctly handle leading/trailing whitespace, special characters and variable substitution.

I'm closing this in favor of #1775.