Are EAS Secrets available to EAS Updates

Expo Application Services (EAS)
1

hi again :slight_smile:

I’m still a bit confused about ENV variables and EAS Update. At least with the (possibly legacy) way I am doing things, I noticed that secret values passed via eas secret seem to be available with code generated by eas build but go missing after running eas update without the ENV variables explicitly passed in. To make this more specific:

My app.config.js has

{
  sentryDsn: process.env.SENTRY_DSN,
}

And my eas secrets has a valid entry for SENTRY_DSN.

Now if I run vanilla eas update ..., then sentryDsn becomes undefined. But if I run SENTRY_DSN=x expo update, (i.e. with the ENV variables passed it) it becomes populated again.

I don’t know if this is expected behavior or just a teething problem with these bleeding-edge features, but at least from my POV as an end-user (and a long-time user of the legacy OTA system), this is surprising behavior.

So two questions:

  1. Is this the expected behavior or just a temporary blip?
  2. What would you advise end users to do here in order to make these secrets available to the app in some way that a) removes duplication and b) restricts unnecessary access? For context, we have some high-profile clients who are under public scrutiny and we need to make access to certain credentials restricted to people with security clearance (I know there are no perfect secrets with apps but we want to increase the barrier to entry for hacking our app credentials. Most predicted attacks are by extreme amateurs in our space wishing to gain political points)

PS Sorry for posting lots of questions – we are pretty heavily invested in the Expo ecosystem so this is high-stakes stuff for us. If any of your team are curious about how my agency uses/plans to use Expo, I’m happy to arrange a call and could offer some insights. We also have a YouTube channel for programmers (3k subs) and are considering doing a video on EAS.

2

Welcome back!

As you suspect, this particular issue is a teething issue and one that we have not intentionally designed yet. I wrote a doc on how env vars can be used at the moment here, but those approaches are not smooth and likely do not meet what you need.

Right now, we don’t have a good solution for the two things you need: removing duplication and restricting access. --Perhaps there is some workaround with git-crypt or direnv, that could allow only some developers access to env vars.

We are going to work on this soon, and will certainly be in a better state before a general release later this year. Hearing your use case and needs will help us build a better flow/process. It sounds like you need the ability to have an update use the same env vars as a build, and also to have access to EAS secrets. Let me know if you have other needs!

3

Thanks.

The interim solution we ended up using is this

  • we created a .env file with all the secrets
  • we used these secrets in app.config.ts 
const processEnv: ProcessEnv = process.env
const extra = {
  apiUrl: processEnv.API_URL,
  ...
}
  • we created a script that added these secrets to eas secret 
# This is an approximation -- it may not work without tweaking for your shell
for pair in $(cat .env | grep "=."); do; eas secret:create --name $(echo $pair | cut -d = -f 1) --value $(echo $pair | cut -d = -f 2); done
  • we wrapped our own interfaces to all the eas commands with something that made all the variables in the .env file available as true ENV variables

For us, this was a Makefile

-include .env

URL_FOR_DEV_CLIENT="exp+$(EXPO_PROJECT_NAME)://expo-development-client/?url=$(EAS_UPDATES_URL)"


update_staging_ota: ## Update the staging branch over the air
	ENV=staging eas update --branch staging --message "Update"
	@echo "Open up the following link in the dev-client:"
	@echo $(URL_FOR_DEV_CLIENT)?channel-name=staging

We also ensured these secrets were available on Github Actions (using convenience helpers from the gh CLI.