Gopass

2026.08.26.3

Fixed: Restored inline npm:zod@4.4.3 import specifiers so the registry quality scorer can resolve dependencies and score the extension. An earlier release used a bare "zod" import-map specifier, which published but scored as unscored.

Changed: Retained explicit compilerOptions.strict in deno.json. No behavioral or schema changes.

2026.08.26.1

Changed: Normalized deno.json configuration for repo-wide consistency: added explicit compilerOptions.strict and migrated zod dependency to the import map (bare "zod" specifier instead of inline npm:zod@4.4.3). No behavioral changes — runtime resolution is identical.

2026.08.25.1

Changed: Updated labels for improved extension discoverability. Added cross-cutting category labels (security, observability, finops, infrastructure, networking, compliance, devops, ai, incident-response) where applicable.

2026.08.23.1

Fixed: README's Usage section documented invented CLI flags/subcommands (--vault, --key, --value) that don't exist. Corrected to the real swamp vault put/read-secret/list-keys command forms.

Changed: Documentation only — no code changes otherwise. Added a ## Troubleshooting section covering missing-binary errors when gopass isn't on PATH, the deliberately terse exit-code error message (namespace is kept out of it on purpose), assertSafeKey's rejections, passwordOnly defaulting to true and truncating multi-line entries, and store-prefix stripping in list.

2026.08.21.1

Changed: When the gopass CLI exits non-zero, the thrown error now names the subcommand that failed (e.g. gopass show -o -n <path> exited with code 1: entry not found) instead of just the exit code and bare stderr. Previously a failure surfaced only gopass's own message with no indication of which operation — show, insert, or list — was in progress; that's important context to have when multiple vault calls happen back to back. Secret values passed on stdin are still redacted before the error is constructed, as before.

2026.08.20.1

Upgrade note: Bumped zod from 4.3.6 to 4.4.3. No behavioral changes — dependency version alignment only.

2026.07.27.1

Changed: Bump @opentelemetry/api 1.9.0 → 1.9.1

2026.07.26.2

Added: OpenTelemetry spans on get, put, and list, named gopass get, gopass put, and gopass list. Attributes: vault.name, vault.secret_key, vault.store when a store is configured, rpc.system, rpc.service, rpc.method, and vault.keys_returned on list.

This closes a real observability gap rather than duplicating the host. swamp emits swamp.vault.* spans when a human runs a swamp vault subcommand, with no attributes at all — and emits nothing when a model or workflow resolves a vault expression. A secret read during a run was invisible in traces. These spans appear on both paths.

The extension uses @opentelemetry/api only and never constructs a TracerProvider. With no provider configured the tracer is a no-op and the cost is a few property lookups.

There are deliberately no spans around the gopass invocation itself. Each public method is exactly one CLI call, so a child span would be a renamed duplicate of its parent, and keeping span code out of the exec helper means no edit can attach argv or stdin — which hold the plaintext — to a span.

Changed: Error messages no longer echo a submitted secret value. If gopass fails an insert and quotes the value back on stderr, that value is replaced with [redacted] before the message is thrown. The swamp host publishes thrown error messages into its own span as a status description, an exception.message, and a stack trace, so an echoed value reached the trace backend regardless of what this extension recorded.

Note on what spans deliberately omit: spans record error.type and an ERROR status on failure, and never recordException and never a status description. A gopass error message is the CLI's stderr, which this extension does not control, and the host already publishes it once. Recording key names is intentional — a vault span without the key is close to useless for debugging — so treat key names as visible to anyone with access to your trace backend. gopass's own documentation advises against putting sensitive data in secret names; that advice now has a second reason behind it.

2026.07.26.2

Added: OpenTelemetry spans on get, put, and list, named gopass get, gopass put, and gopass list. Attributes: vault.name, vault.secret_key, vault.store when a store is configured, rpc.system, rpc.service, rpc.method, and vault.keys_returned on list.

This closes a real observability gap rather than duplicating the host. swamp emits swamp.vault.* spans when a human runs a swamp vault subcommand, with no attributes at all — and emits nothing when a model or workflow resolves a vault expression. A secret read during a run was invisible in traces. These spans appear on both paths.

The extension uses @opentelemetry/api only and never constructs a TracerProvider. With no provider configured the tracer is a no-op and the cost is a few property lookups.

There are deliberately no spans around the gopass invocation itself. Each public method is exactly one CLI call, so a child span would be a renamed duplicate of its parent, and keeping span code out of the exec helper means no edit can attach argv or stdin — which hold the plaintext — to a span.

Changed: Error messages no longer echo a submitted secret value. If gopass fails an insert and quotes the value back on stderr, that value is replaced with [redacted] before the message is thrown. The swamp host publishes thrown error messages into its own span as a status description, an exception.message, and a stack trace, so an echoed value reached the trace backend regardless of what this extension recorded.

Note on what spans deliberately omit: spans record error.type and an ERROR status on failure, and never recordException and never a status description. A gopass error message is the CLI's stderr, which this extension does not control, and the host already publishes it once. Recording key names is intentional — a vault span without the key is close to useless for debugging — so treat key names as visible to anyone with access to your trace backend. gopass's own documentation advises against putting sensitive data in secret names; that advice now has a second reason behind it.

2026.07.26.1

Fixed: Secrets with leading or trailing whitespace came back altered. The CLI output was passed through trim(), which strips spaces and tabs at both ends, not just the line terminator the CLI adds. Only a single trailing newline is removed now, so " padded " round-trips intact.

Fixed: Keys were not validated, so get("../../other/secret") escaped the configured store and read — or with put, overwrote — a secret outside the namespace the config pinned the caller to. Keys containing . or .. path segments, empty path segments (a//b, trailing/), absolute keys, empty keys, and keys starting with - (which gopass would parse as a flag) are now rejected before the CLI runs.

Note: Unlike @webframp/pass at this version, the gopass subprocess still inherits the full parent environment. gopass has a much larger set of its own GOPASS_* and backend variables, and narrowing it needs to be validated against a live gopass store before it ships.

Known limitation: A secret whose own final character is a newline cannot be distinguished from the terminator the CLI appends, so that byte is still lost. This is inherent to reading secrets from a line-oriented CLI.

2026.07.18.2

Changed: Version bump only, no code changes.

2026.07.18.1

Changed: Renamed the manifest tags: field to labels: — the schema's actual field name. No runtime or install behavior change.

2026.07.18.1

Changed: Renamed the manifest tags: field to labels: — the schema's actual field name. No runtime or install behavior change.