AdminModule: don't return the device private key to remote config reads#11030
Conversation
A SECURITY_CONFIG get_config response copied config.security verbatim, so a remote request was answered with the device identity private_key and sent over the air. Only the local owner needs it, for backup. Zero private_key in the SECURITY_CONFIG response when the request is remote (from != 0); the local BLE/USB/TCP path (from == 0) still receives it. public_key and admin_key are public and stay as they were.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthrough
ChangesSecurity Config Redaction
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
⚡ Try this PR in the Web FlasherNote Building this pull request… the flash button, badges and supported-board |
A
get_configforSECURITY_CONFIGcopiesconfig.securitystraight into the response:config.securityincludesprivate_key, the device identity key used to derive PKC sharedsecrets. For a request that arrived over the mesh (
from != 0), that response is sent backover the air, so the private key leaves the device. Only the local owner needs it, and only
for backup.
Zero
private_keyin the SECURITY_CONFIG response when the request is remote. Local adminclients (BLE/USB/TCP) set
from == 0and still receive the full config, so the backup/restorepath is unchanged. This mirrors the existing
writeSecret()redaction used fornetwork.wifi_pska few cases up.On
admin_key: I evaluated redacting it too and left it. Those entries are public keys ("thepublic key authorized to send admin messages"), not secret material, and a legitimate remote
admin may want to read the configured admin set.
private_keyis the only field whose exposureescalates to identity compromise. Zeroing
admin_keyfor remote would be a one-line addition inthe same block if that trust-set disclosure is judged worth closing.
Tests (test_admin_session_repro): a remote SECURITY_CONFIG response decodes to an empty
private_key; a local (from == 0) response still carries the 32-byte key, so the redaction is
remote-specific rather than a blanket wipe.
Summary by CodeRabbit