Harden Proton validation and report candidate details #1

Open
opened 2026-05-31 18:05:02 +01:00 by hegdeatri · 0 comments
Owner

Objective

Harden the Rust passkey migration tool before it is used on real exports by tightening input validation and improving audit report detail.

Background

Duplicate Bitwarden item creation is now the default migration behavior, with --no-create-duplicates as the opt-out. During the follow-up review, two correctness/usability gaps stood out that are not part of that default-policy change.

Findings

  1. Proton export shape is under-validated. proton::extract_passkeys currently returns an empty list when the top-level vaults object is missing or when vault/item shapes are wrong. That can make a malformed or wrong file look like a successful zero-passkey migration instead of a bad input.
  2. Candidate details in ambiguous/conflict reports are lossy. ActionRecord carries only candidate ids, and report_entry_from_action maps those to TargetItem { id, name: None }. The text renderer only prints candidate names, so ambiguous reports can show an empty candidate list even when candidates existed.

Proposed approach

  • Add explicit Proton export validation before extraction: require a top-level object with a vaults object, require vault items arrays when vaults are present, and return clear non-zero CLI errors for invalid structure.
  • Keep per-item/passkey malformed content as reportable per-passkey failures, but treat invalid export structure as invalid input.
  • Preserve candidate ids and names in ActionRecord or use TargetItem directly so text and JSON reports identify the exact ambiguous/conflicting Bitwarden items.
  • Add regression tests for malformed Proton structure and ambiguous report candidate rendering.

Acceptance criteria

  • Running the CLI with a valid JSON file that is not a Proton export fails with a clear error and non-zero exit.
  • Ambiguous matching reports include candidate item ids and names in JSON output.
  • Text reports display useful candidate identifiers when names are absent.
  • Existing cargo test coverage passes, with new tests for the validation and report cases.

Risks

  • Be careful not to reject real Proton exports that omit optional fields or contain vaults without login passkeys.
  • Keep malformed individual passkeys reportable so one bad passkey does not abort the whole migration.
## Objective Harden the Rust passkey migration tool before it is used on real exports by tightening input validation and improving audit report detail. ## Background Duplicate Bitwarden item creation is now the default migration behavior, with `--no-create-duplicates` as the opt-out. During the follow-up review, two correctness/usability gaps stood out that are not part of that default-policy change. ## Findings 1. Proton export shape is under-validated. `proton::extract_passkeys` currently returns an empty list when the top-level `vaults` object is missing or when vault/item shapes are wrong. That can make a malformed or wrong file look like a successful zero-passkey migration instead of a bad input. 2. Candidate details in ambiguous/conflict reports are lossy. `ActionRecord` carries only candidate ids, and `report_entry_from_action` maps those to `TargetItem { id, name: None }`. The text renderer only prints candidate names, so ambiguous reports can show an empty candidate list even when candidates existed. ## Proposed approach - Add explicit Proton export validation before extraction: require a top-level object with a `vaults` object, require vault `items` arrays when vaults are present, and return clear non-zero CLI errors for invalid structure. - Keep per-item/passkey malformed content as reportable per-passkey failures, but treat invalid export structure as invalid input. - Preserve candidate ids and names in `ActionRecord` or use `TargetItem` directly so text and JSON reports identify the exact ambiguous/conflicting Bitwarden items. - Add regression tests for malformed Proton structure and ambiguous report candidate rendering. ## Acceptance criteria - Running the CLI with a valid JSON file that is not a Proton export fails with a clear error and non-zero exit. - Ambiguous matching reports include candidate item ids and names in JSON output. - Text reports display useful candidate identifiers when names are absent. - Existing `cargo test` coverage passes, with new tests for the validation and report cases. ## Risks - Be careful not to reject real Proton exports that omit optional fields or contain vaults without login passkeys. - Keep malformed individual passkeys reportable so one bad passkey does not abort the whole migration.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
hegdeatri/bitwarden_import_proton_pass#1
No description provided.