Skip to content

FXCM-2280: Implement Migration for Encrypted Autofill Storage - #7576

Draft
theidkamp wants to merge 3 commits into
mozilla:mainfrom
theidkamp:fxcm-2280-migration
Draft

FXCM-2280: Implement Migration for Encrypted Autofill Storage#7576
theidkamp wants to merge 3 commits into
mozilla:mainfrom
theidkamp:fxcm-2280-migration

Conversation

@theidkamp

Copy link
Copy Markdown

Blocked on #7542 — does not build until the shared db-crypto crate lands,
so CI here is expected to be red. Verified locally against #7542's head
(cc7212f7d): fmt clean, clippy clean, 109 tests passing.

Stacked on #<2281> and #<2279>. Do not merge before both* — this branch
contains their commits, so merging here would land all three. Please review
only the last commit, eb4fa2f3b.

Description

Stores the encrypted card number as {"v":1,"n":"<number>"} instead of the bare
number, so a CVV can be added as a second encrypted field later without
rewriting every row a second time. db::migrate_cc_secure_fields rewrites
existing rows in place.

Pull Request checklist

  • Breaking changes: This PR follows our breaking change policy
    • This PR follows the breaking change policy:
      • This PR has no breaking API changes, or
      • There are corresponding PRs for our consumer applications that resolve the breaking changes and have been approved
  • Quality: This PR builds and tests run cleanly
    • Note:
      • For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
      • If this pull request includes a breaking change, consider cutting a new release after merging.
  • Tests: This PR includes thorough tests or an explanation of why it does not
  • Changelog: This PR includes a changelog entry in CHANGELOG.md or an explanation of why it does not need one
    • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
  • Dependencies: This PR follows our dependency management guidelines
    • Any new dependencies are accompanied by a summary of the due diligence applied in selecting them.

Move autofill's credit-card encryption onto the shared db-crypto crate and let
AutofillDb own the encryptor, as logins' LoginDb does. The consumer supplies it
when building the store, so no key is passed into individual calls or down
through the sync layers.
Move encrypting and decrypting a card number behind one type, so the knowledge
of what the stored value looks like lives in a single place instead of being
spread across the db and sync code. A struct rather than a bare string is
deliberate: a CVV is expected as a second encrypted field, which needs a
structured encoding and a rewrite of existing rows (FXCM-2280). No stored data
changes here.
Store the encrypted number as {"v":1,"n":"<number>"} rather than the bare
number, so a CVV can be added as a second encrypted field later without
rewriting every row again. db::migrate_cc_secure_fields rewrites existing rows
in place, on the raw table so sync_change_counter and time_last_modified do not
move, and matching on the old ciphertext so a concurrent write is not clobbered.
It runs from run_maintenance before the vacuum there, guarded by a moz_meta flag
that is only set when no row was skipped.

Bump the schema to 6. No tables change; the bump makes a downgrade fail in
open_database rather than read a blob as a card number and upload it.
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