RNMapboxMapsDownloadToken is exposed when using expo:prebuild under build.gradle and podfile

[FrederickEngelhardt]

Adding the download key RNMapboxMapsDownloadToken to expo's App.json / app.config.js cause it to publish to the podfile and gradle.properties file.

I had the key abstracted to a local config file. But expo prebuild does not know these items are secrets so it adds them to the Podfile and gradle file which normally need to be committed.

// eslint-disable-next-line @nx/enforce-module-boundaries
const localConfig = require('../../.local.config.js')
const expoConfig = {
    plugins: [
    ...
      [
        '@rnmapbox/maps',
        {
          RNMapboxMapsVersion: '11.4.0',
          RNMapboxMapsDownloadToken:
            localConfig.mapbox.RNMapboxMapsDownloadToken,
        },
      ]
    ]

Questions

1. Is this intended?
2. Should I be ignoring the gradle properties and podfile for xcode projects that are auto-generating some things?

Workaround / Security Doc update

If this is not intended...

• I think we should update the docs to protect these keys. The download key exposure seems to be low risk for now, but could get your banned if a bad actor took the key and spammed the api.
• We can add docs or point to docs about .netrc (ios) and local.properties for android.

Environment

Latest expo 51 (as a development build) with RN74.

Steps to reproduce

1. Add the config key. Run expo prebuild and see the key be added to the android/gradle.properties and ios/Podfile
2. Publish it to github public and get a warning about exposing download keys. 😢

You can try it on this repo. https://github.com/VirtualizeLLC/examples. Add the key to the apps/mapbox/app.config.js or make a .local.config and add the key there.

Afterwards run nx run mapbox:prebuild --clean it should add the download keys.

[mfazekas]

See also:

#3396

A PR with a warning in docs would be great. Also a PR addressing this correctly with Env vars would be also nice. You can also consider not checking in iOS and android to your ci, but even then the secrets will be in built product’s eas.json I think.

[FrederickEngelhardt]

I'll look at making a PR. May also want to add something to expo for this. Secret handling especially for open source needs to be prioritized.

[FrederickEngelhardt]

Done in #3609 🎉 . Let's follow up there. Let's close this issue once that PR is accepted.