Skip to content

Separate sensitive credentials into credentials.cfg#18770

Open
RJNY wants to merge 1 commit intolibretro:masterfrom
RJNY:rjny/credentials-cfg
Open

Separate sensitive credentials into credentials.cfg#18770
RJNY wants to merge 1 commit intolibretro:masterfrom
RJNY:rjny/credentials-cfg

Conversation

@RJNY
Copy link
Contributor

@RJNY RJNY commented Feb 25, 2026

Description

Separates sensitive settings (passwords, tokens, stream keys) into a dedicated credentials.cfg file so they are not exposed when sharing or backing up retroarch.cfg.

  • Adds CFG_BOOL_FLG_SENSITIVE flag with SETTING_ARRAY_SENSITIVE and SETTING_PATH_SENSITIVE wrapper macros to tag 13 sensitive settings (cheevos, webdav, smb, netplay, streaming)
  • On save, sensitive fields are written to credentials.cfg and stripped from the main config via config_unset
  • On load, credentials.cfg is merged back via config_append_file
  • If credentials.cfg write fails, sensitive fields stay in retroarch.cfg as a safety net
  • Migration is JIT: first config save after updating creates credentials.cfg and cleans the main config
  • Generalizes the cheevos-specific override exclusion (#ifdef HAVE_CHEEVOS + 3x string_is_equal) into a single flag check covering all sensitive settings

Testing:

  • macOS (M4 Pro)
  • Verified credentials.cfg created on quit, retroarch.cfg clean
  • Verified "Save New Configuration" produces no sensitive fields
  • Verified deletion of credentials.cfg + relaunch recreates it

@RJNY RJNY closed this Feb 25, 2026
@RJNY RJNY reopened this Feb 25, 2026
@RJNY RJNY marked this pull request as ready for review February 25, 2026 00:41
@i30817
Copy link
Contributor

i30817 commented Feb 25, 2026

I think the pr #18376 will probably conflict and one of the prs will have to be rebased but both features are important.

At first I thought this could be done with only the linked pr by making those properties only save into the base config, but I like a separate file better, since its explicit and since the base file might end up unreadable (and unreachable in the app sandbox in android at least by common users) by design in Linux and android.

I would kind of prefer a OS keyring solution because for example google and Firefox keyrings are automatically backed up into the cloud (dangerous but very convenient indeed) and/or its easier to remember what you have to backup or how to look into it if its only one thing, but that is fiddly platform specific technology and and the perfect mustn't be the enemy of the good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants