Follow-up from the BYO-IAM adversarial review (branch feat/external-s3-iceberg, finding S1).
redact_graph_source_config (fluree-db-api/src/ledger_info.rs) redacts scalar values whose key exact-matches SECRET_CONFIG_KEYS (client_secret, token, secret, password, passwd, access_key_id, secret_access_key, session_token, default_val). Every current secret leaf in the graph-source config schema is covered — there is no live leak — and the exhaustive per-auth-variant canary test forces a decision when AuthConfig gains a variant.
But the mechanism fails open for a future secret-bearing field whose name isn't on the list (e.g. refresh_token, api_key) if it arrives outside a new AuthConfig variant (where the canary wouldn't force the decision). Options, roughly in preference order:
- Schema-driven redaction: serialize through a DTO that enumerates the non-secret fields explicitly (true allowlist — unknown fields redact by default).
- Keep the denylist but add a structural canary: walk
IcebergGsConfig's serde schema in a test and assert every leaf is either on a known-NON-secret allowlist or on SECRET_CONFIG_KEYS — new fields fail the test until classified.
- Heuristic hardening (substring match on secret/token/key/password) — weakest, false-positive prone.
Option 2 is cheap and forces the classification decision at compile/test time for any new field, not just auth variants.
The doc comments were corrected to describe the denylist semantics accurately in the BYO-IAM branch; this issue tracks making the mechanism itself fail closed.
Follow-up from the BYO-IAM adversarial review (branch
feat/external-s3-iceberg, finding S1).redact_graph_source_config(fluree-db-api/src/ledger_info.rs) redacts scalar values whose key exact-matchesSECRET_CONFIG_KEYS(client_secret, token, secret, password, passwd, access_key_id, secret_access_key, session_token, default_val). Every current secret leaf in the graph-source config schema is covered — there is no live leak — and the exhaustive per-auth-variant canary test forces a decision whenAuthConfiggains a variant.But the mechanism fails open for a future secret-bearing field whose name isn't on the list (e.g.
refresh_token,api_key) if it arrives outside a newAuthConfigvariant (where the canary wouldn't force the decision). Options, roughly in preference order:IcebergGsConfig's serde schema in a test and assert every leaf is either on a known-NON-secret allowlist or onSECRET_CONFIG_KEYS— new fields fail the test until classified.Option 2 is cheap and forces the classification decision at compile/test time for any new field, not just auth variants.
The doc comments were corrected to describe the denylist semantics accurately in the BYO-IAM branch; this issue tracks making the mechanism itself fail closed.