How to handle Google Play service JSON key in the latest Deploy to Google Play step?

[tallpants]

Hey guys,

In the latest version of the Google Play Deploy step, the service key JSON file URL changed from a regular field to a sensitive field – so we can’t use regular environment variables for it anymore – only secrets.

However all the documentation I can find says the way to handle it is to upload the service key JSON to generic file storage and use it from there (https://blog.bitrise.io/how-to-deploy-android-app-to-google-play-store?utm_source=medium&utm_medium=web&utm_campaign=deployandroidapp) – this won’t work anymore if the field is sensitive.

How do you propose we handle providing the service key JSON to Bitrise in the latest version?

[bitce]

Hi @tallpants!

You can still use the same process of uploading it to the Generic File Storage, and afterwards you can add it’s URL as a secret, the variable of which you can provide to the Google Play Deploy step, and you should be all set!

[tallpants]

Thanks for the quick reply @bitce!

The URL for the generic file upload will be an environment variable right? Will the input replacement still work if the secret text is just an environment variable?

Like [secret=$URL] and [service_key_json_url=$secret]

[bitce]

Of course!

Not exactly, I believe once you upload the service key, a “hidden secret” of sorts will be automatically generated for it and the step input will be filled accordingly without it appearing among your secrets - and you have to provide the var manually when dealing with multiple keys.

In case I am wrong here - you can do the method you described, just adding it as a secret variable instead of an environment one.

[bitce]

Like [secret=$URL] and [service_key_json_url=$secret]

Sorry, I missed this, you can, in fact, set an env var value to be a secret var, it just wouldn’t work in this specific case because of the step input requirement for it to be secret.

[tallpants]

So wait if I set the secret var to be an env var – and I set the step input to that secret var – will it be replaced with the env var’s content?

And if so it seems kind of pointless to enforce the secret requirement

[bitce]

To be honest I’m getting slightly confused here

@tallpants

So wait if I set the secret var to be an env var – and I set the step input to that secret var – will it be replaced with the env var’s content?

And if so it seems kind of pointless to enforce the secret requirement

I’m not entirely sure you could do this, because secrets are prioritised, but the machines handle both as variables, the only difference is that secrets mean to protect sensitive information, and hence the requirement meant to ensure that absolutely no one can access your service key.

So I wouldn’t agree that this is pointless at all, and the method you describe seems like overkill to me, really this process should require one secret and that’s all.

I hope it’s clear now, sorry if that got confusing!

[tallpants]

Yea I’m confused too

I’ll try my best to describe it clearly:

If I upload my service key JSON file to Generic File Storage – I get an env var (let’s say $BITRISEIO_SERVICE_KEY_URL.

In the previous version of the Deploy to Google Play step, the service key input URL was a regular input field – so I could set it to $BITRISEIO_SERVICE_KEY_URL and that was all that’s needed.

In the latest version of the step, the input is now a secret – but the Generic File Storage only gives you a regular environment variable – not a secret, so I can’t set it to $BITRISEIO_SERVICE_KEY_URL anymore.

So my question is:

• Can we create a secret variable (say $BITRISEIO_SECRET) and set it to the environment variable given by the Generic File Storage ($BITRISEIO_SERVICE_KEY_URL), and then set the Play Store Deploy input to the secret ($BITRISEIO_SECRET) – will that work?

Essentially:

[Generic File Storage] -returns-> $BITRISEIO_SERVICE_KEY_URL

BITRISEIO_SECRET = $BITRISEIO_SERVICE_KEY_URL

PLAY_STORE_DEPLOY_STEP_INPUT = $BITRISEIO_SECRET

• And if not, how do you propose we get the service key JSON file to the Play Store Deploy step input.

[bitce]

Hey again!

Yes, that will absolutely work. I think it’s best to illustrate this for the sake of clarity for anyone who might read this

The method to do this should be the following:

The env var I named my service key here is $BITRISEIO_125_URL. Now, in the step input I can create a secret like this one:

Referencing the env var itself. (Make sure to tick in ‘Replace variable in input’)

Now, after all this I do get your point - while this is still a secure method - the URL could be available as secret as well after the upload. Would you consider creating a #feature-request about it?

[koral]

Simpler workaround is just to set input to $BITRISEIO_SERVICE_KEY_URL in bitrise.yml.

bitrise.yml editor does not verify if value is a secret.

[bitce]

@koral is very right here currently this should work as well.

[tallpants]

Sure, but I feel like something working with YAML but not with the GUI just because Bitrise doesn’t verify secrets in YAML isn’t a good precedent to set

[koral]

I agree, so I explicitly said that it is a workaround, not a real solution.

BTW @bitce it seems that the first workaround:

@tallpants

[Generic File Storage] -returns-> $BITRISEIO_SERVICE_KEY_URL

BITRISEIO_SECRET = $BITRISEIO_SERVICE_KEY_URL

PLAY_STORE_DEPLOY_STEP_INPUT = $BITRISEIO_SECRET

reveals another kind of issue.
There is an environment variable processing order documentation: Bitrise CLI - Bitrise Docs on devcenter.

URL from generic storage is an environment variable according to description (Download URL will be available as the Environment Variable). We see that it is processed before secrets but it does not seem to match p 1. Bitrise CLI exposed environment variables. This link on devcenter is invalid but on the target page: Available Environment Variables - Bitrise Docs there is nothing about env vars from generic file storage.

WDYT? IMHO it should be listed explicitly before secrets somewhere.

[bitce]

Thanks once again @koral!

We’ll update the wrong link shortly, here is the correct one in the while.

But the problem you brought up remains - none of these articles explain how are these file storage vars handled. Currently, these URLs are in fact passed as Secrets to the build, the issue is that they are not available as Secrets, and they are specifically referred to as env vars on the site indeed.

So my interpretation is that they currently hold a middle ground of sorts, but considering the recent security updates, my two-cents is that they should be available as secrets.

[koral]

OK, so if that URL is already a secret then it seem that we have only UI issue that it cannot be selected and feature request: Solution for convoluted Service Key JSON issue in Deploy to Google Play step is not needed.

BTW @bitce what about other variables defined in signing tab? Files (p12, provisioning and keystore) and keystore credentials are they also secrets but not available in UI?

[koral]

@bitce

Currently, these URLs are in fact passed as Secrets to the build

@bitce what about PRs in public projects? Secrets are not available there so generic file storage is not available. Is it intended limitation or a bug?

[bitce]

Hey @koral, sorry for the late replies here!

hat about other variables defined in signing tab? Files (p12, provisioning and keystore) and keystore credentials are they also secrets but not available in UI?

That is correct.

As for the public project issue, the Generic File Storage is a wildcard in this extent, since that allows these URL to be exposed for PRs even as opposed to regular secrets.