Skip to content

edit: encrypt with item key when entry has one - #368

Open
Mic92 wants to merge 1 commit into
doy:mainfrom
Mic92:item-key-edit
Open

Mic92 wants to merge 1 commit into
doy:mainfrom
Mic92:item-key-edit

Conversation

@Mic92

@Mic92 Mic92 commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

Fixes #364.

rbw edit encrypted fields with the user/org key and dropped the key field from the cipher PUT, corrupting entries that have an individual item key (vault becomes undecryptable with invalid mac).

Now the agent encrypts with the item key when present and the PUT preserves key. Tested against vaultwarden.

rbw edit re-encrypted password/notes with the user/org key while the
server kept the entry's individual item key, corrupting the entry for
all clients (doy#364).
m11y added a commit to m11y/rbw that referenced this pull request Sep 2, 2026
Encrypt custom-field (and password/notes) values with the entry's
individual item key when present, and send that key on the cipher PUT.
Without this, keyed items become mixed-key and fail with invalid mac
(doy#364; same plumbing as doy#368).

Refuse SSH key entries (Client::edit is unreachable for them) and linked
fields. Require boolean fields to be true/false. Interactive edits strip
only the appended help suffix so user lines starting with # are kept.
@m11y

m11y commented Sep 3, 2026

Copy link
Copy Markdown

Heads up: I opened #371, which overlaps this PR.

It fixes the same item-key corruption (#364) with the same approach, but bundles four more cipher-write fixes on top: preserving reprompt / favorite / archivedDate on the PUT (they are reset on every edit today), sending lastKnownRevisionDate so a stale full PUT cannot clobber a concurrent edit, correcting the ordering between the agent's master-password-reprompt set and the on-disk vault, and exit-code semantics for a write that landed but whose local cache refresh failed.

Because those additions replace actions::edit with edit_with_meta rather than adding a key parameter, the two branches conflict textually.

I did not want to duplicate your work silently, so either order works for me: if this PR merges first I will rebase #371 onto it and drop the duplicated part; if @doy prefers the combined one, this can be closed.

@Mic92

Mic92 commented Sep 3, 2026 •

Copy link
Copy Markdown
Contributor Author

I have no preference. I am happy if i can settle my patches.

@m11y m11y mentioned this pull request Sep 6, 2026
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.

rbw edit corrupts entries that have an individual encryption key

2 participants