Separate credentials/PII from retroarch.cfg to make configs safely shareable
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 14.1k
- Forks
- 2.2k
- Avg merge
- 7h 35m
- Merged PRs (30d)
- 51
Description
Description
retroarch.cfg stores credentials and sensitive data inline alongside all other settings. This makes it unsafe to share configs without manual editing, and causes credential leakage into override files (see #12953).
Sensitive fields currently stored in retroarch.cfg
| Field | Risk |
|---|---|
cheevos_password |
RetroAchievements password in plaintext |
cheevos_token |
RetroAchievements auth token |
cheevos_username |
RetroAchievements username |
twitch_stream_key |
Would let someone stream to your Twitch channel |
youtube_stream_key |
Would let someone stream to your YouTube channel |
netplay_password |
Netplay session password |
netplay_spectate_password |
Netplay spectate password |
webdav_username |
Cloud sync username |
webdav_password |
Cloud sync password |
Why this matters
Config sharing is common in the RetroArch community. Influencers share optimized configs for specific cores/devices, users migrate between devices, and third-party tools help manage backups. All of these workflows involve moving retroarch.cfg around, and all of them risk leaking credentials.
This was partially reported in #12953 (credentials leaking into override files via "Save Overrides"), but the root cause is that credentials live in the same config format as everything else.
Proposed solution
Store credentials in a separate file (e.g. retroarch-secrets.cfg or retroarch-credentials.cfg) that RetroArch reads at startup but is never included in:
- "Save New Configuration" exports
- "Save Overrides" (per-core/per-game)
- Any config dump to
config/
This would make the main retroarch.cfg and all override files safe to share by default, without requiring users or third-party tools to scrub sensitive fields.
Current workarounds
Third-party tools (and careful users) must manually strip these fields before sharing. This is fragile because:
- The list of sensitive fields can change across RetroArch versions
- New credential fields (e.g. for future integrations) won't be caught
- Users who don't know about this risk will share credentials unknowingly
Environment
Applies to all platforms, but especially impactful on Android where scoped storage restrictions make config management harder.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing RetroArch's startup configuration loading and the paths for Save New Configuration, Save Overrides, and config dumps. Identify where the listed credential fields are read and written, then define the separate secrets-file behavior and verify that shared configs and overrides exclude those fields.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100