fnox values don't understand 1Passwors sections

[hilja]

1Password can define a section inside an item, here called "local":

Accessing the secret in a section using a secret reference works op://env-vars/UPSTASH/local/QSTASH_CURRENT_SIGNING_KEY, but using a shorthand fails:

[providers]
op = { type = "1password", vault = "env-vars" }

[secrets]
QSTASH_CURRENT_SIGNING_KEY = { provider = "op", value = "UPSTASH/local/QSTASH_CURRENT_SIGNING_KEY" }

Error:

ERROR fnox_core::secret_resolver: Error resolving secret 'QSTASH_CURRENT_SIGNING_KEY': 1Password: invalid response: Invalid secret reference format: 'UPSTASH/local/QSTASH_CURRENT_SIGNING_KEY'
Error: [fnox::provider::invalid_response ](https://fnox.jdx.dev/providers/1password)[(link)](https://fnox.jdx.dev/providers/1password)

                                 × 1Password: invalid response: Invalid secret reference format: 'UPSTASH/
  │ local/QSTASH_CURRENT_SIGNING_KEY'
  help: Expected 'item', 'item/field', or 'op://vault/item/field'

[ChangkeunJ]

It's not really about sections, it's that the shorthand parser only knows one and two segment values. From crates/fnox-core/src/providers/onepassword.rs:

let parts: Vec<&str> = value.split('/').collect();
match parts.len() {
    1 => Ok(format!("op://{}/{}/password", ...)),
    2 => Ok(format!("op://{}/{}/{}", ...)),
    _ => Err(FnoxError::ProviderInvalidResponse { ... }),
}

UPSTASH/local/QSTASH_CURRENT_SIGNING_KEY splits into three, so it drops straight into the error arm. Any three segment value fails identically. And the full form works precisely because it short-circuits at the top of that function, before the split ever runs.

So the workaround for now is just to write it out:

QSTASH_CURRENT_SIGNING_KEY = { provider = "op", value = "op://env-vars/UPSTASH/local/QSTASH_CURRENT_SIGNING_KEY" }

which makes the vault on the provider redundant for that secret, a bit irritating if you have a pile of them.

For the actual fix the minimal version is one more arm:

3 => Ok(format!(
    "op://{}/{}/{}/{}",
    self.vault.as_ref().unwrap(),
    parts[0],
    parts[1],
    parts[2]
)),

but the whole match collapses, since everything other than the bare item case is just the vault glued onto the value unchanged:

match parts.len() {
    1 => Ok(format!("op://{}/{}/password", self.vault.as_ref().unwrap(), value)),
    _ => Ok(format!("op://{}/{}", self.vault.as_ref().unwrap(), value)),
}

That loses the error arm, which I'd argue is the right call regardless. op validates references itself and its message will always be more accurate than one guessed from a segment count. Worth a glance at vault.rs and proton_pass.rs while you're in there too, they carry the same error string so they may have the same shape of assumption baked in.