Dollar sign in environment variables

I have a setup where I try to sign an Android application with a key password which contains a dollar sign ($).
I set up the secret environment variable for the project:


I’m using the sign-apk Android step.
I verified locally that all passwords are correct.

However I get a build error on my builds in the signing process.

Sign APK
=> /usr/bin/jarsigner “-sigfile” “CERT” “-sigalg” “SHA1withRSA” “-digestalg” “SHA1” “-keystore” “/bitrise/src/projectname.jks” “-storepass” “***” “-keypass” “***” “-signedjar” “/tmp/bitrise-sign-apk438099450/unaligned.apk” “/tmp/bitrise-sign-apk438099450/unsigned.apk” "projectname"
Failed to sign APK, error: jarsigner: key associated with projectname not a private key

The error is misleading as I verified that the keystore file has the required private key and that both the storage and key passwords are correct.

The only reason for failure I can think about now is the dollar sign in the password.
Does it interfere with the enviroment variable replacement functionality on Bitrise, if so how to escape?




Thanks for asking this question here! :slight_smile:

In general, you can disable the $ expansion for an env var by setting is_expand: false for the env var, where you define it (e.g. in App Env Vars). Related docs:

Now, in case of BITRISEIO_ANDROID_KEYSTORE_PASSWORD, you don’t have this flag exposed for you, so you might have to define the password separately if you need to set is_expand: false for the env var.

I’ll double check if is_expand is enabled for the env if you specify the password in the Code Signing & Files section, and we’ll fix this if it would not be set to false, but as a workaround you can specify it as an App Env Var, where you can set the is_expand flag.

I did two things:

  • I uploaded the keystore to Bitrise instead of loading it from our repository
  • I changed the private key password to one without a dollar sign

Now my builds are successful. I’m pretty sure the second one solved the issue.

1 Like

Thanks for the info, and I’m glad to hear that you could solve this!

Indeed, the solution was most likely to not to include $ in the password. That said, $ in the password should still work.

In the meantime I checked the related code in the website, and the BITRISEIO_ANDROID_KEYSTORE_PASSWORD env var should be exposed with is_expand: false (correctly), so the issue is most likely in the apk-signer step.

We’ll check this, and fix it ASAP, in the meantime the solution is to don’t use $ in the password if you use the apk-signer step.

1 Like

Just ran into this issue myself. I have a large number of variables stored in a single bitrise env variable (creating a yml file on the fly), including a password that had a $ in it:

itc_password: password_with_$
itc_team_id: teamid

I use that to sign into iTunesConnect and kept getting invalid credential issues (I also tried putting the password in quotes). The fix was to remove the $ from the password, but the assumption prior was that the bitrise wouldn’t care about $ inside of an environment variable. This leads me to believe you can embed environment variables within eachother, which could potentially lead to some recursive issues. Removing the $ from the password was a sufficient solution for me, but I figured I should at least point this out!

1 Like

Sure, we value every feedback! :wink:

This is true, if you disable environment variable expansion for that env var / input. Related docs:

Correct, you can :slight_smile:

No, that’s not possible. Environment Variables are processed in the order of definition, in a non recursive way. If you specify ENV_A: value A and then specify ENV_B: $ENV_A, then ENV_B's value will be value A (if environment variable expansion is enabled for ENV_B). If you’d change the value of ENV_A and specify it as ENV_A: $ENV_B, then that would be an empty value, because at that point ENV_B is not defined. You can find more information about this at:

Ahh I see. Thanks for the explanation and glad to see you are WAY ahead of me haha :slight_smile:

1 Like

The core system is quite battle tested by now, but that doesn’t mean that there’s nothing we forgot about or missed, so keep the feedback/questions coming! :wink:

Just ran into this error but had the password stored in a “Secrets” var. Changed the password to remove the $ before realizing I could have toggled the “Replace variables in inputs” there. Seems like having it on by default is risky since you might not even know that feature exists (as in my case).

Exactly what we thought as well @garret! This was planned for a while now, and was finally shipped in the latest Workflow Editor version 2 days ago:

When creating secrets & env vars, set “is expand” option to false initially

Happy Building! :wink:

1 Like