The router migrated from generate_device_keypair → register_device
(returns signing_public_key + deploy_public_key with private keys
staying internal to WASM). Test still mocked the old function under
the old return shape (public_key_hex / private_key_base64), so the
router's state.wasm.register_device() call failed with
"is not a function".
Updates the mock function name, response shape, and assertion to the
current contract. Test intent (treat the WASM return as a JS object,
not a JSON string) is preserved.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Expand get_active_tab_url protocol filter regex to include view-source:,
data:, devtools:, and other browser-internal/extension contexts that would
misbehave if autofilled. Add third regression test for view-source: URLs.
Wrap get_active_tab_url tests in dedicated describe block with beforeEach/
afterEach to snapshot/restore globalThis.chrome, preventing stub leakage
between tests.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The wasm-bindgen binding for generate_device_keypair uses
serde-wasm-bindgen and returns a plain JsValue (object), not a JSON
string. Two consumers were calling JSON.parse on it, causing the
runtime error 'SyntaxError: "[object Object]" is not valid JSON' which
broke device registration end-to-end.
Fixes:
- wasm.d.ts: return type now { public_key_hex; private_key_base64 }
matching the rate_passphrase pattern (also a JsValue-returning
binding).
- popup-only.ts (register_this_device handler) and setup.ts (initial
device wire-up): drop JSON.parse, use the object directly.
- router.test.ts: pin the contract — mock generate_device_keypair as a
function returning an object (matching real binding behavior) and
assert register_this_device returns ok and forwards the public key.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Closes three audit gaps in one pass:
1. Sync now button in the popup settings view (📤). Triggers the existing
{ type: 'sync' } SW message and surfaces success / failure inline. The
SW message was already wired but had no UI entry point.
2. Device registration from the popup. The "Register this device" button
on the devices view used to error out with a "not yet implemented"
message; it now opens an inline name input (default = browser+OS), and
on confirm sends a new register_this_device SW message that generates
an ed25519 keypair via WASM, persists private_key + name to
chrome.storage.local, and writes the public key to the remote
devices.json. No setup-wizard detour.
3. Vault tab is now an authorized sender for popup-only SW messages. The
router accepts vault.html alongside popup.html, so the fullscreen tab
can drive the same flows. Test covers acceptance from the vault tab.
New SW message: register_this_device { name }. Added to PopupMessage and
POPUP_ONLY_TYPES, handled in router/popup-only.ts.
Tests: 5 new vitest cases (3 in settings.test.ts, 2 in devices.test.ts)
+ 1 router test for vault-tab acceptance. All 194 extension tests pass.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Both popup-only. upload_attachment encrypts via WASM, putBlobs via
GitHost (Git Data API fallback for >900 KB), persists the AttachmentRef
on the item + manifest summaries. Duplicate uploads (same content =
same id from sha256) return the existing ref without a re-upload.
download_attachment reads + decrypts and returns plaintext bytes for
the popup to wrap in a Blob. 4 new router tests (accept × 2, reject × 2).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Critical bug caught in T8 code review: the SW's get_totp handler
gated on core.type === 'login' and referenced core.totp, so the
standalone Totp item type (which lands in T8 with core.type === 'totp'
and core.config) had its detail-view ticker silently rejected with
'no_totp' every second. Ticker swallowed the error; rotating code
display stayed at placeholder forever.
Fix: extend the handler to resolve TotpConfig from either carrier:
- Login items: item.core.totp (optional subfield)
- Totp items: item.core.config (required)
Also:
- Add 3 router tests covering both paths + the empty case
- Remove stale '……' placeholder check in types/totp.ts's \`t\`
keyboard shortcut (dead code — the placeholder is '·····' or
'······', never horizontal ellipses)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bug: setup tab's zxcvbn meter silently stayed at score=-1 because the
router's isSetup exception only allowed save_setup, so rate_passphrase
got unauthorized_sender. Result: the "create vault" button stayed
disabled forever even with a strong passphrase.
Fix: add a narrow SETUP_ALLOWED set containing save_setup,
rate_passphrase, and is_unlocked (step-4 extension detection). Reject
everything else from the setup tab. Also clean up setup.ts's unlock
call — it was passing the raw 32-byte imageSecret where JPEG bytes with
embedded secret are required; the Rust-side unlock calls imgsecret::
extract internally.
Diagnostic logging across the message path so the next silent failure
speaks up:
- [relicario setup] staged logs through vault-init; console.error
with the failure stage name in the UI banner.
- [relicario setup] rate_passphrase lastError / rejected / threw
branches each log their own warning.
- [relicario router] console.warn on unauthorized_sender (with sender
classification) and unknown_message_type.
- [relicario sw] first-message wasm init announced; per-message
non-ok result logged; thrown errors console.error'd.
Tests: +3 setup-allowlist tests (rate_passphrase accepted, is_unlocked
accepted, fill_credentials + unlock rejected). 55/55 green.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After Slice 4's router split, the capture prompt's Save button was
silently failing on every site: content/capture.ts called four handlers
(get_settings, get_item, update_item, add_item) that are all in
POPUP_ONLY_TYPES, so the router rejected each with unauthorized_sender.
Fix in two parts:
Part A — get_settings: content scripts already have storage permission
via the manifest, so read relicarioSettings directly from
chrome.storage.local instead of round-tripping through the SW.
Part B — new content-callable 'capture_save_login' message that
consolidates what was previously three separate popup-only calls
(get_item + update_item or add_item) into one SW-side operation.
Content scripts no longer need to distinguish add vs update — the SW
does that itself from the manifest.
Security model (all enforced SW-side, never trusting content):
- Origin is derived from sender.tab.url by the router. The payload
contains only username + password; there is no way for content to
influence which host the new/updated item binds to.
- Update path re-verifies the existing item's core.url hostname
matches senderHost before mutating. If the manifest icon_hint ever
drifts from core.url, we return origin_mismatch rather than
silently binding a password to the wrong origin.
- Update mutates ONLY the password field + modified timestamp —
never title, url, or any other core field.
- Add path creates a new Login item whose title is senderHost and
whose url is the sender's origin.
Five new router tests cover: content-accept, popup-reject, update
path rotates only the password, add path creates bound item, and
origin_mismatch when the stored item's host disagrees with senderHost.
Tests: 47 -> 52.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three new describe blocks cover the gaps flagged during Slice 4 review:
1. fill_credentials captured-tab verification — three cases:
- tab_navigated: chrome.tabs.get returns a tab whose hostname differs
from capturedUrl → handler must return { ok: false, tab_navigated }
and not call chrome.tabs.sendMessage.
- origin_mismatch: tab matches capturedUrl but the item's
LoginCore.url hostname differs → same refusal, no delivery.
- happy path: verify the forwarded message is exactly
{ type: 'fill_credentials', username, password, expectedHost }.
2. save_setup exception scope: the setup tab gets a narrow exception
to POST save_setup, but nothing else. Prove fill_credentials from
the setup tab is rejected with unauthorized_sender.
3. isContent sender.id guard: a content-shaped sender with a bogus
sender.id (≠ chrome.runtime.id) must be rejected.
Vault/session modules are partial-mocked via vi.mock + importOriginal so
the existing tests continue to exercise real listItems/findByHostname.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
