Skip to content

Release v0.4.22: pin installer after Bitwarden launch lookup reuse - #102

Merged
JacobStephens2 merged 1 commit into
mainfrom
release/v0.4.22
Sep 7, 2026
Merged

JacobStephens2 merged 1 commit into
mainfrom
release/v0.4.22

Conversation

@JacobStephens2

Copy link
Copy Markdown
Owner

Version bump only - no behaviour change beyond what #101 already merged. Same pin-file shape as v0.4.21: Cargo.toml, Cargo.lock, install-remote.sh, AGENTS.md, README.md (and the va update vX.Y.Z examples so they name this pin).

Why cut a release

#101 shipped after v0.4.21 was tagged. An unpinned curl … | bash still installs a binary without the single-listing lookup optimization. Moving the pin is what makes the optimized Bitwarden harness launch available from a product install.

Also includes #99 (fail closed on glued Bitwarden refs from bash 0.3.0 refresh).

Checks

Pin-only. CI on this PR is the gate. Tagging follows merge: .github/workflows/release.yml fires on v*.

#101: Bitwarden harness launches were listing the full vault separately
for every named or project-qualified reference. Reuse parsed lookup
metadata within one manifest resolution. UUID-only and empty manifests
skip listing, and every launch still fetches current secret values.

Also includes #99: fail closed on glued Bitwarden refs from bash 0.3.0
refresh.
@JacobStephens2
JacobStephens2 merged commit 049fff2 into main Sep 7, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant