Conversation
Match the wasm package by treating unreadable or malformed persisted Noise config as an empty config on read. This keeps missing, malformed, and inaccessible localStorage cases on the same compatibility path while preserving write failures as noise-config errors. Update tests for malformed JSON, invalid byte arrays, and getItem failures.
Keep the public EIP-712 signing API aligned with the wasm package intent: callers pass the raw typed-data object, not a pre-serialized JSON string. The wasm wrapper stringifies the provided value itself before Rust parses the JSON. Accepting string input in the TypeScript parser widened the public API and let call sites work that would fail against the wasm package. Remove the JSON.parse path and cover both the parser and signing method so string input is rejected before any device query.
Return plain Uint8Array fields for Ethereum signatures, matching the wasm package output more closely. The previous implementation attached custom toJSON methods to the signature object and its r, s, and v byte arrays. That made JSON.stringify produce array-shaped output, but it was a TypeScript-only convenience and changed observable runtime behavior. Simplify signature construction and keep tests focused on the normal Uint8Array API.
Publish the TypeScript package as @bitboxswiss/bitbox-api instead of the temporary unscoped bitbox-api-ts name. Update README examples, sandbox imports and aliases, and public stub error messages so consumers see and use the intended scoped npm package name.
Run simulator suites for each manifest entry and keep version-specific expectations in the tests.
So malformed handshake messages, AEAD failures, and other Noise primitive errors cross the public boundary as noise errors instead of unknown-js. Transport queries are intentionally left outside the wrapper so existing communication and bridge error mapping is preserved.
Match the old bridge transport timing by letting the WebSocket close event invoke the onClose callback. Calling close() now only asks the socket to close instead of firing the callback directly. Keep the existing close guard so repeated close events or repeated close() calls still notify callers at most once.
Match the old U2F-WS bridge framing limit by rejecting payloads that do not fit in the reference MAX_LEN buffer before writing the frame length. This avoids sending a malformed frame whose 16-bit length header no longer represents the actual payload size.
Wire deviceInfo and rootFingerprint through HWW protobuf requests. Add unit, simulator, and sandbox coverage matching bitbox-api-rs.
Old query_proto mapped empty or non-success encrypted reply status values to unexpected-response, not to a Noise channel failure. Keep authentication and decryption failures on the noise code, but classify the response-status framing case as an unexpected BitBox response.
The old wasm boundary treated a decoded top-level response without an active oneof arm as a protobuf decode failure. Classify that case before method-specific response checks so callers see protobuf-decode instead of unexpected-response.
The old package classified host nonce generation failures as antiklepto failures, not unknown JavaScript errors. Catch getRandomValues failures at nonce creation and preserve the stable antiklepto public error code.
Match the wasm TryFrom path for invalid address_case values. Add an explicit switch default so invalid runtime values fail instead of falling through to an undefined protobuf enum value.
|
|
||
| import { useState } from 'react'; | ||
| import * as bitbox from 'bitbox-api-ts'; | ||
| import * as bitbox from '@bitboxswiss/bitbox-api'; |
There was a problem hiding this comment.
is the idea to not bring the wasm api under the @BitBoxSwiss namespace and deprecate it eventually? So they're both 'bitbox-api', but only this one is under @BitBoxSwiss?
| return { | ||
| r: signature.slice(0, 32), | ||
| s: signature.slice(32, 64), | ||
| v, |
There was a problem hiding this comment.
this is unfortunately a regression of b4fb772
I agree that signature.slice() is a cleaner API shape, but at this point it's no longer a drop in replacement because it breaks Rabby. Chrome extension messaging strips Uint8Array identity, so BitBox signatures sent from Rabby’s offscreen context arrive as plain objects instead of byte arrays unless Rabby serializes them explicitly.
So right now Rabby bitbox integration is written to handle the wasm api shape which is in a way mocked in b4fb772 to make it a drop in replacement
Two solutions, keep the json array workaround, which I agree is not as clean, or when submitting a PR to Rabby to swap the library, also rework their bitbox plumbing to adapt it to the new library.
While cleaner, the second option might also break other integrations (like NuFi) that would have to be fixed.
b4fb772 made both the signature object and each byte field stringify to arrays, so after the offscreen message boundary Rabby received:
{ r: [..32 bytes..], s: [..32 bytes..], v: [..] }
That shape works with bytesToHex() and Buffer.from().
Compatible with old WASM package, which mistyped it as Uint8Array - the actual values produced were JS arrays, not UInt8Arrays.
Make typed API errors keep message enumerable while still throwing real Error instances, matching the old WASM error shape across Chrome extension messaging.
Explain why typed Error instances make message enumerable for JSON serialization and Chrome extension message boundaries.
No description provided.