Bug: fnox sync breaks secrets that use json_path

[rpendleton]

Problem

When using fnox sync to cache a secret that uses json_path to extract a key from a JSON value, the cached secret fails on subsequent reads. I ran into this with an AWS Secrets Manager secret whose value is a JSON object, but it's easy to reproduce locally with the plain provider.

For example, given the following plain-provider config:

root = true

[providers.plain]
type = "plain"

[secrets]
USER = { provider = "plain", value = '{"username":"admin","password":"secret123"}', json_path = "username" }
PASS = { provider = "plain", value = '{"username":"admin","password":"secret123"}', json_path = "password" }

The behavior looks like this:

1. fnox get USER works — fetches the JSON, extracts "admin" via json_path

2. fnox sync -p age --force — resolves the secret (applying json_path), then encrypts the result

3. fnox get USER — decrypts the cached value ("admin"), then tries to apply json_path again, failing with:

   Configuration error: Failed to parse JSON secret: expected value at line 1 column 1
   

Root cause

src/commands/sync.rs calls resolve_secrets_batch without stripping json_path from the secret configs first. As a result, apply_post_processing runs during sync resolution, and the synced value becomes the extracted field ("admin") instead of the full JSON blob. On read-back, json_path is applied again to that already-extracted string, which is not valid JSON.

Compare with src/commands/reencrypt.rs, which already correctly strips json_path (and sync and default) before resolving.

Fix options

I've implemented three approaches on separate branches so you can review the trade-offs. I'm happy to open a PR for whichever direction you prefer, but I wanted to align on the shape of the fix before I spent more time writing tests for all three.

Let me know which option you'd prefer (or if you have a different idea) and I'll put up a PR with tests.

Option A: Strip json_path inline in sync.rs (diff)

The minimal fix. It adds secret_config.json_path = None next to the existing secret_config.sync = None in the resolve loop, matching the pattern already used by reencrypt.rs.

• Smallest change; only touches sync.rs
• Downside: if new post-processing steps are added later, sync and reencrypt still need to be kept in sync manually, which is the kind of drift that caused this bug

Option B: Add resolve_secrets_batch_raw wrapper (diff)

Adds a resolve_secrets_batch_raw function that wraps the existing resolver but skips all post-processing internally. Threads a skip_post_processing flag through the internal functions (resolve_level, resolve_provider_batch, process_batch_results, etc.).

• Future-proof: new post-processing steps are automatically skipped
• Downside: adds a fair amount of internal plumbing for a fairly targeted fix

Option C: Add SecretConfig::for_raw_resolve() (diff)

Adds a method on SecretConfig that returns a copy with all post-processing fields stripped (json_path, sync, default). Both sync.rs and reencrypt.rs use it, replacing the manual field-by-field stripping in reencrypt.rs.

• Single source of truth for "what is post-processing" without touching the resolver
• Cleans up the existing manual stripping in reencrypt.rs
• New post-processing fields only need to be added to one method

[jdx]

C seems like the best to me

[rpendleton]

Thanks! PR opened: #371.