🚨 suggestion (security): Persisting the private key in plain text config may be a security concern

Persisting the private key in the general config store means any user/process with access to that file can read it. Depending on your threat model, consider a more secure storage mechanism (OS keyring/keystore, separate restricted file, or encrypting the key with a passphrase) rather than plain text in the config. At minimum, ensure the config file location is tightly permissioned if you keep this approach.

Suggested implementation:

  // Persist shared file list and public key in the general config store.
  config->SetStringList(CONFIG_SHARED_FILE_LIST, sharedFileList);
  config->SetString("public_key", public_key);

  // NOTE: We intentionally do NOT persist the private key in the general
  // config store to avoid storing it in plaintext in a world-readable file.
  // The private key should be loaded from a more secure storage mechanism
  // (OS keyring/keystore, separate file with restrictive permissions, or
  // encrypted on disk) instead of being written here.
  config->Save();
}

To fully address the concern, you should:

1. Introduce a secure storage mechanism for private_key (e.g. OS keyring/keystore integration, or a separate file created with restrictive permissions such as 0600).
2. Update ProgramData::initPrivateKey() to load the private key from that secure storage, and ensure it never falls back to reading it from the general config.
3. Audit any other call sites that might read/write private_key via config and migrate them to the secure storage path instead.
4. Ensure that any new secure-storage file is documented and added to ignore lists/backups as appropriate so it is not accidentally exposed.