Skip to content

Fail closed on glued Bitwarden refs from bash 0.3.0 refresh - #99

Merged
JacobStephens2 merged 1 commit into
mainfrom
fix/glued-bws-refresh-lines
Sep 7, 2026
Merged

JacobStephens2 merged 1 commit into
mainfrom
fix/glued-bws-refresh-lines

Conversation

@JacobStephens2

Copy link
Copy Markdown
Owner

va grok on a host that had run bash 0.3.0 va refresh --all failed with:

no secret matched 'name:META_AI_API_KEYFIREWORKS_API_KEY=name:FIREWORKS_API_KEY…'

The rust writer already emits one mapping per line. The reader still treated the glued blob as a legal name: ref and asked the vault for a secret that does not exist. refresh then treated every name:KEY as already mapped because each is a substring of the blob, so a second merge was a no-op.

What changed

  • validate (launch, doctor, secrets validate --offline) fails closed on a glued VAR=name:VAR line and prints the recovered mappings.
  • va refresh splits those lines even when added == 0.
  • Merge tests now assert one mapping per line, not contains.

A host still running the 0.3.0 bash binary will re-glue on the next merge refresh. va update is the way off that writer.

va refresh on the bash launcher captured each VAR=name:KEY line with
$(...), which strips the trailing newline, then concatenated. Launch
sent the blob to the vault and reported no secret matched the glued name.

validate now rejects that shape and prints the recovered
one-mapping-per-line form. refresh splits those lines even when every
secret already appears as a substring, so a second merge is not a no-op.
@JacobStephens2
JacobStephens2 merged commit 1344069 into main Sep 7, 2026
2 checks passed
@JacobStephens2
JacobStephens2 deleted the fix/glued-bws-refresh-lines branch September 7, 2026 13:33
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