Tools that integrate with Proton Pass, like the SecretSpec Proton Pass provider, have no public API, SDK or compatibility policy to build on. The only option is to run pass-cli as a subprocess and parse its text output. Proton support has confirmed that breaking changes can ship in patch releases without notice.
What this costs users today:
- Upgrades break things without warning. Three pass-cli releases have already broken integrations: 2.0.3 changed the item list JSON, 2.1.0 started requiring an agent reason, and 2.2.4 removed pass-cli test. That last one stopped every SecretSpec Proton Pass operation until a fix was released. Users now have to pin old CLI versions to stay safe.
- Secrets are exposed in the process list. pass-cli item update only accepts values as --field name=value on the command line, so any local user can read the secret with ps. Because of this, integrations have to make field writes read-only.
- New fields can't be hidden. item update stores any new field as plain text, with no way to make it a hidden field.
- Errors are just text. Missing items and missing fields only show up as English error messages, and an empty field gives the same error as a missing one. Integrations have to match strings that can change in any release.
- It's slow. There's no batch read, so loading N secrets means starting N pass-cli processes.
What would fix it (any one of these helps):
1. A versioned public API or SDK, for example Rust bindings to the existing pass crate, with a published compatibility policy.
2. A stable machine interface in pass-cli: versioned JSON output, documented error codes, and a promise of no breaking changes in patch releases.
3. At minimum: read values for item update from stdin or a template, support hidden custom fields, and add a batch read command.
Proton Pass is a great end-to-end encrypted place for developer secrets. Please make it safe to build on. 👍 Vote if you use Pass with CI, .env tooling, or secret managers like SecretSpec.