Heads up: github security scanning now detects mapbox api keys

[simonpoole]

I've just been working on the February maintenance release of Vespucci which includes, as every month, an updated version of ELI. Committing the update this month however fails/failed because of the exposed mapbox keys from ~half a dozen sources. It is currently possible to override the block but I wouldn't count on that continuing. With one exception most of the relevant sources would seem to be provided by OSM-US and in the end it would seem to be their call how to handle this.

@tyrasd @1ec5

[tyrasd]

Thanks for the heads-up. IMO it would be best to omit those tokens from the repository. As one has to organize¹ an API token to access the Mapbox Satellite layer anyway, it would be easy to reuse that one for other mapbox hosted tile sets. As far as I can see, at least at the moment, neither openstreetmapus' tiles for the TIGER overlays nor the USForestService roads overlay style are set to public, so using them is currently only possible with the provided "hardcoded" API keys. But that should be easy to fix that. 😊

//cc @planemad regarding the India-PMGSY layer which is also affected. But at a quick glance it looks like this layer/token does not even load anymore?

Footnotes

1. For OSM editors and related tools: contact me or EWG to get a key that was kindly provided for free by Mapbox for OSM through their community program. ↩

[1ec5]

It is currently possible to override the block but I wouldn't count on that continuing.

Are you running into the secret scanning feature or something else?

As far as I can see, at least at the moment, neither openstreetmapus' tiles for the TIGER overlays nor the USForestService roads overlay style are set to public, so using them is currently only possible with the provided "hardcoded" API keys.

The TIGER Roads layers are maintained by @iandees. They shouldn’t be locked to any domain or application ID. Setting the tilesets to public would address the issue from iD’s perspective, but I don’t know that the tileset is intended to be limited to just OSM/OHM.

[tyrasd]

Secret Protection is not enabled.

This is how it looks like when a commit contains a file with a mapbox access_token:

$ git push […]

[…]

remote: error: GH013: Repository rule violations found for refs/heads/gh-pages.
remote: 
remote: - GITHUB PUSH PROTECTION
remote:   —————————————————————————————————————————
remote:     Resolve the following violations before pushing again
remote: 
remote:     - Push cannot contain secrets
remote: 
remote:     
remote:      (?) Learn how to resolve a blocked push
remote:      https://docs.github.com/code-security/secret-scanning/working-with-secret-scanning-and-push-protection/working-with-push-protection-from-the-command-line#resolving-a-blocked-push
remote:     
remote:      (?) This repository does not have Secret Scanning enabled, but is eligible. Enable Secret Scanning to view and manage detected secrets.
remote:      Visit the repository settings page, https://github.com/osmlab/editor-layer-index/settings/security_analysis
remote:     
remote:     
remote:       —— Mapbox Secret Access Token ————————————————————————
remote:        locations:
remote:          - commit: 
remote:            path: :13
remote:          - commit: 503234dd271a36693bced651922c4c27d9699f87
remote:            path: sources/asia/in/India-PMGSY.geojson:13
remote:     
remote:        (?) To push, remove secret from commit(s) or follow this URL to allow the secret.
remote:        https://github.com/osmlab/editor-layer-index/security/secret-scanning/unblock-secret/[<<<snip temporary URL>>>]
remote:     
remote: 
remote: 
To github.com:osmlab/editor-layer-index.git
 ! [remote rejected]   gh-pages -> gh-pages (push declined due to repository rule violations)
error: failed to push some refs to 'github.com:osmlab/editor-layer-index.git'

[tyrasd]

Setting the tilesets to public would address the issue from iD’s perspective, but I don’t know that the tileset is intended to be limited to just OSM/OHM.

JOSM, Vespucci, as well as a few other OSM editors and tools already have access to a Mapbox token as mentioned above. And any other tool can easily get one. So really only the more niche use cases like using the layer in QGIS, etc. would really be affected. But if OSM-US can live with their credentials being accessible publicly (and thus being easy to scrape/misuse), that's also fine. The main downside would be that in case the key does get misused (which is even easier as such a public key cannot be limited to a specific referrer) and thus has to be rotated, all consumers of the editor layer index have to update in order to access to the layers again.

[simonpoole]

Are you running into the secret scanning feature or something else?

It is that feature, but it a) seems to be default on, and b) it is probably a good idea, just that simply failing a commit with no pre-warning is not good form.

[tyrasd]

Yeah, true. To be even more specific it's the secret scanning partner program that is kicking in here.

[simonpoole]

PS: just in case anybody is wondering why I'm so insane and am committing ELI (and a couple of other things) to the Vespucci repo: while you can update the ELI configuration on the fly in the app, we try to avoid, well actually have no mandatory phoning home in the app. Now we could simply include ELI at build time (which we for example do for nearly all keys) and have the same effect, but that would cause issues with third party builds, most notable F-Droid that requires code to be in the repo they are building from and any dependencies to be from a small number of "approved" binary repositories.

[iandees]

Mapbox is aware of the access token posted alongside the TIGER layers. They don't currently have a way to lock an access token to a specific layer or tileset, so they're ok with it sitting as-is.

Having said that, if we can move them to use the existing side channel token retrieval system that the Mapbox Satellite ELI layer uses, that'd likely be better.