MSQ Snap

Description

User consent may not consistently be enforced. Identities are bound to their origin (URL). Third-party origins are outside the scope of this Snap and are therefore in a lower trust zone where it is uncertain what security measures are in place to protect the dApp from impersonating the user’s wallet identity. dApps may be hosted on integrity-protecting endpoints (ipfs/IC), however, this is not enforced. Additionally, even when hosted on integrity-protecting endpoints there are still risks of insider and external attacks on the deployed dApp (Insider changing code, External attacker gaining access to code, Injection, Web Attacks), BGP routing related attacks (typically expensive), and DNS related attacks.

Allowing linked identities to sign with a main origin’s identity extends the risk from one public origin to another.

It should be noted that identities on public RPC methods are origin bound. There is no direct way for one public origin to sign with another origin’s identity unless it is linked.

Examples

• critical functionality: acting on behalf of user
  • SNAP_METHODS.public.identity.sign - sign with origin bound identity
• potential identity leak
  • SNAP_METHODS.public.identity.getPublicKey - origin bound identity
  • SNAP_METHODS.public.identity.getPseudonym - origin bound pseudonym
• no concerns
  • SNAP_METHODS.public.identity.getLinks - origin links
  • SNAP_METHODS.public.identity.sessionExists - check if session for origin exists

Example: signing

The function handleIdentitySign is responsible for signing a payload with an identity. However, it has been observed that the function proceeds to sign the payload without seeking explicit user confirmation or displaying the payload in a human-readable format. This approach can significantly undermine the security and trust model of MetaMask Snaps by allowing potentially malicious operations to be executed without the user’s informed consent.

packages/snap/src/protocols/identity.ts:L268-L280

export async function handleIdentitySign(bodyCBOR: string, origin: TOrigin): Promise<ArrayBuffer> {
  const body: IIdentitySignRequest = zodParse(ZIdentitySignRequest, fromCBOR(bodyCBOR));
  const manager = await StateManager.make();
  let session = (await manager.getOriginData(origin)).currentSession;

  if (session === undefined) {
    err(ErrorCode.UNAUTHORIZED, "Log in first");
  }

  const identity = await getSignIdentity(session.deriviationOrigin, session.identityId, body.salt);

  return await identity.sign(body.challenge);
}

Recommendation

When performing critical actions on behalf of the user, always ask for consent. The user must always be notified when a dApp acts on their behalf (especially signing). For API that provides less critical information it should be considered to implement a session based consent mechanism that trades security for convenience where, e.g., linked identities or the public key can only be extracted if the user at least once confirmed this for the current origin (caching the decision).

Description

The current Snap implementation allows untrusted dapps to supply their own nonces for the generation of unique private keys tied to their identities. These nonces, which can be arbitrary and are not managed or stored by the Snap, introduce a risk. Specifically, if a dapp fails to securely store these nonces or ceases operation, users may irretrievably lose access to their accounts, potentially resulting in the loss of funds. This issue underscores a vulnerability in the system’s design, where the reliance on external parties for the management of crucial security parameters compromises the safety and recoverability of user assets.

Examples

From the documentation:

MSQ is a Snap, it has no cloud storage, so all the data is self-managed by the user. It is safe for users to lose their data (by re-installing the snap, for example) - because they can recover it from their seed phrase later. To achieve that we use deterministic algorithms for entropy derivation.

packages/snap/src/protocols/identity.ts:L298-L309

  const body = zodParse(ZIdentityGetPublicKeyRequest, fromCBOR(bodyCBOR));
  const manager = await StateManager.make();
  let session = (await manager.getOriginData(origin)).currentSession;

  if (session === undefined) {
    err(ErrorCode.UNAUTHORIZED, "Log in first");
  }

  const identity = await getSignIdentity(session.deriviationOrigin, session.identityId, body.salt);

  return identity.getPublicKey().toRaw();
}

Recommendation

To mitigate the risk of users losing access to their accounts and funds due to mismanaged or lost nonces by dapps, it is recommended to either:

• Enforce Deterministic Nonces: Shift to a system where the Snap generates unique identities using deterministic nonces, ensuring all accounts are recoverable, independent of dapps actions or continuity. This is already implemented to generate “root” dapps identities.
• Introduce Disclaimers: Clearly inform users and developers of the risks through disclaimers in the user interface and documentation.

Description

The Snap employs a custom wrapper around its storage, incorporating a caching mechanism to optimize performance by updating the Snap’s storage only when necessary. This caching strategy uses a timestamp-based method, maintaining records of the last storage (LAST_STATE_PERSIST_TIMESTAMP) and state (STATE_UPDATE_TIMESTAMP) updates to decide on the need for persisting the updated state. However, two logical flaws were identified in this approach:

• First, in the retrieveStateWrapped() function, where the state is fetched from the Snap’s storage, the state update timestamp is only refreshed if the retrieved state is null. Consequently, if an existing state is successfully retrieved, the state update timestamp remains unchanged, which is incoherent.

packages/snap/src/state.ts:L464-L472

  if (state == null) {
    const s = makeDefaultState();
    STATE = s;

    STATE_UPDATE_TIMESTAMP = Date.now();
  } else {
    STATE = zodParse(ZState, fromCBOR(state.data as string));
  }
}

• Second, the persistStateLocal() function, responsible for persisting the state, updates the LAST_STATE_PERSIST_TIMESTAMP before the actual state update is executed. This can lead to an invalid timestamp if the subsequent state update operation (e.g., due to CBOR encoding errors or failures in the internal Snap’s storage mechanism) fails, risking state and storage inconsistencies.

packages/snap/src/state.ts:L527-L538

async function persistStateLocal(): Promise<void> {
  if (LAST_STATE_PERSIST_TIMESTAMP >= STATE_UPDATE_TIMESTAMP) return;

  zodParse(ZState, STATE);

  LAST_STATE_PERSIST_TIMESTAMP = Date.now();

  await snap.request({
    method: "snap_manageState",
    params: {
      operation: "update",
      newState: { data: toCBOR(STATE) },

Recommendation

Adjust the timestamp update logic as follows:

• In retrieveStateWrapped(), ensure the STATE_UPDATE_TIMESTAMP is refreshed whenever a state (not null or empty) is retrieved, not just when the state is null.

• In persistStateLocal(), update the LAST_STATE_PERSIST_TIMESTAMP only after the state has been successfully persisted, preventing inaccuracies in the event of a failed state update.

Description

Identities are bound to their origin (URL). Third-party origins are outside the scope of this Snap and are therefore in a lower trust zone where it is unsure what security measures are in place to protect the dApp from impersonating the users’ wallet identity. dApps may be hosted on integrity protecting endpoints (ipfs/IC), however, this is not enforced.

Protected RPC functions can only be invoked by the MSQ administrative origin. User consent may not consistently be enforced on the administrative origin.

The administrative origin is identified by the origin URL. According to the client the dApp is hosted on an integrity protecting endpoint (IC). This already protects from direct manipulation of the deployed code, however, it may still be problematic as the Snap and Management dApp are in different trust zones with the dApp being exposed to many external factors that make it more prone to web related attacks. That said, even when hosted on integrity protecting endpoins there are still risks of insider and external attacks on the deployed dApp (Insider changing code, External attacker gaining access to code, Injection, Web Attacks), BGP routing related attacks (typically expensive), and DNS related attacks. In the worst case, an insider/external attacker gaining control of the trusted origin may be able to perform actions on many users behalf’s without them knowing (given that the user accesses the management origin).

Examples

• critical
  • SNAP_METHODS.protected.identity.login - log into any origin
  • SNAP_METHODS.protected.identity.editPseudonym
  • SNAP_METHODS.protected.icrc1.editAssetAccount
• unclear
  • SNAP_METHODS.protected.statistics.get
  • SNAP_METHODS.protected.statistics.increment
  • SNAP_METHODS.protected.statistics.reset
• potential privacy leak
  • SNAP_METHODS.protected.state.getAllOriginData - subset of origin data (no keys)
  • SNAP_METHODS.protected.state.getAllAssetData - subset of asset data
  • SNAP_METHODS.protected.identity.getLoginOptions

Recommendation

When performing critical actions on behalf of the user, always ask for consent. The user must always be notified when a dApp acts on their behalf (especially signing). For API that provides less critical information it should be considered to implement a lazy session based consent mechanism that trades security for convenience where, i.e., data can only be extracted from the snap if the user at least once confirmed this for the current session.

Description

protected_handleIdentityLogin is used to create a new session and logs in to a particular origin (e.g., a website). At a certain point, a new session object is created, where identityId: body.withIdentityId is set. The withIdentityId is an unchecked request parameter, which could potentially lead to an inconsistency where the origin set’s an invalid ID.

Examples

packages/snap/src/protocols/identity.ts:L76-L101

export async function protected_handleIdentityLogin(bodyCBOR: string): Promise<true> {
  const body: IIdentityLoginRequest = zodParse(ZIdentityLoginRequest, fromCBOR(bodyCBOR));
  const manager = await StateManager.make();

  if (body.withLinkedOrigin !== undefined && body.withLinkedOrigin !== body.toOrigin) {
    if (!manager.linkExists(body.withLinkedOrigin, body.toOrigin))
      err(ErrorCode.UNAUTHORIZED, "Unable to login without a link");
  }

  const originData = await manager.getOriginData(body.toOrigin);
  if (Object.keys(originData.masks).length === 0) {
    unreacheable("login - no origin data found");
  }

  const timestamp = new Date().getTime();
  originData.currentSession = {
    deriviationOrigin: body.withLinkedOrigin ?? body.toOrigin,
    identityId: body.withIdentityId,
    timestampMs: timestamp,
  };

  manager.setOriginData(body.toOrigin, originData);
  manager.incrementStats({ login: 1 });

  return true;
}

Recommendation

withIdentityId is an id relative to the origins masks, hence, it should be validated against the number of existing masks.

The client validated the issue providing more context:

Moreover, when withLinkedOrigin is provided, it should validate against masks of linked origin data. And if not, then it should validate with the originData.masks.

Description

The function protected_handleAddAssetAccount adds an account to an existing asset. It takes the asset name/symbol and assetId as inputs and then adds an account to the assetId if the user approves.

The dialog shown to the user displays the target assets symbol and name. However, this information comes from the dApp and it only used within the dialog. There is no check if the assetId matches the name and symbol which might allow the dApp to mislead the user into accepting the addition of an account for an asset that does not match the displayed name and symbol.

Examples

packages/snap/src/protocols/icrc1.ts:L90-L113

export async function protected_handleAddAssetAccount(bodyCBOR: string): Promise<string | null> {
  const body = zodParse(ZICRC1AddAssetAccountRequest, fromCBOR(bodyCBOR));
  const manager = await StateManager.make();

  const agreed = await snap.request({
    method: "snap_dialog",
    params: {
      type: "confirmation",
      content: panel([
        heading(`🔒 Confirm New ${body.symbol} Account 🔒`),
        text(`Are you sure you want to create a new **${body.name}** (**${body.symbol}**) token account?`),
        text(`This will allow you to send and receive **${body.symbol}** tokens.`),
        divider(),
        text("**Confirm?** 🚀"),
      ]),
    },
  });

  if (!agreed) return null;

  const accountName = manager.addAssetAccount(body.assetId);

  return accountName;
}

Recommendation

The function should take an assetId as input parameter only. Then check if the assetId has accounts registered. If that’s the case, display the name, symbol that corresponds to the assetId and add an account upon user confirmation.

Description

The functions getBaseEntropy and getSignIdentity lack validation for the correct type of arguments or the presence of control characters that may allow context breaks (newline).

For example, in the SNAP_METHODS.public.identity.requestLink method handler, the body.withOrigin is unsanitized and concatenated directly for the resulting salt. withOrigin is a user provided value and may include \n which breaks the context of the salt structure.

Examples

packages/snap/src/utils.ts:L75-L89

export async function getSignIdentity(
  origin: TOrigin,
  identityId: TIdentityId,
  salt: Uint8Array,
): Promise<Secp256k1KeyIdentity> {
  // the MSQ site has constant origin
  // this will allow us to change the domain name without users losing their funds and accounts
  const orig = isMsq(origin) ? "https://msq.tech" : origin;

  // shared prefix may be used in following updates
  const entropy = await getEntropy(orig, identityId, "identity-sign\nshared", salt);

  return Secp256k1KeyIdentity.fromSecretKey(entropy);
}

packages/snap/src/utils.ts:L105-L115

async function getBaseEntropy(origin: TOrigin, identityId: TIdentityId, internalSalt: string): Promise<Uint8Array> {
  const generated: string = await snap.request({
    method: "snap_getEntropy",
    params: {
      version: 1,
      salt: `\x0amsq-snap\n${origin}\n${identityId}\n${internalSalt}`,
    },
  });

  return hexToBytes(generated.slice(2));
}

Recommendation

To address this, enforcing that identityId is a positive number, valid id and origin is a valid URL (free from control characters) would mitigate misuse of this functionality.

Description

The function makeAvatarSvgCustom inserts the given arguments directly into a string that represents an XML SVG image. Since the arguments are not sanitized, there is a potential risk for XML-SVG injection, which could include malicious scripts.

Please note that this affects all arguments provided to the function, especially bgColor, but also the ones that are calculating cx,cy because the addition turns into a string concatenation if face[xy] is a string.

The severity rating is based on the current exploitability which is comparable low with the demo implementations of the front-end.

Examples

packages/shared/src/avatar.ts:L23-L89

/**
 * Generates a custom avatar SVG string based on provided parameters including body color, body angle,
 * face expression, and optional background and eye colors. This function allows for the creation of a
 * personalized avatar with specific characteristics defined by the input parameters. The SVG is constructed
 * with various elements such as circles for the body and eyes, and a custom path for the face expression.
 * Additional details like eye pupils and mouth are also included, with positions adjusted based on the body angle.
 *
 * @param {string} id - A unique identifier used to generate clip paths for the eyes, ensuring they are unique within the SVG.
 * @param {string} bodyColor - The fill color for the avatar's body.
 * @param {IAngle} bodyAngle - An object containing the center coordinates for the body and face, used to position elements.
 * @param {string} faceExpression - A string representing the SVG path for the face expression.
 * @param {string} [bgColor="#1E1F28"] - Optional background color of the SVG. Defaults to a dark gray if not specified.
 * @param {string} [eyeWhiteColor="white"] - Optional color for the whites of the eyes. Defaults to white if not specified.
 * @returns {string} A string representation of the SVG for the custom avatar.
 */
export function makeAvatarSvgCustom(
  id: string,
  bodyColor: string,
  bodyAngle: IAngle,
  faceExpression: string,
  bgColor: string = "#1E1F28",
  eyeWhiteColor: string = "white",
): string {
  const { bodyCx, bodyCy, faceX, faceY } = bodyAngle;

  const eyeWhite1Cx = faceX + EYE_WHITE_1_CX;
  const eyeWhite1Cy = faceY + EYE_WHITE_1_CY;
  const eyePupil1Cx = faceX + EYE_PUPIL_1_CX;
  const eyePupil1Cy = faceY + EYE_PUPIL_1_CY;

  const eyeWhite2Cx = faceX + EYE_WHITE_2_CX;
  const eyeWhite2Cy = faceY + EYE_WHITE_2_CY;
  const eyePupil2Cx = faceX + EYE_PUPIL_2_CX;
  const eyePupil2Cy = faceY + EYE_PUPIL_2_CY;

  const mouthX = faceX + MOUTH_X;
  const mouthY = faceY + MOUTH_Y;

  return `
    <svg xmlns="http://www.w3.org/2000/svg" width="100" height="100" style="position:relative;width:100%;height:100%;" viewBox="0 0 100 100" fill="none">
      <defs>
        <clipPath id="clip-eye-1-${id}">
          <circle cx="${eyeWhite1Cx}" cy="${eyeWhite1Cy}" r="6" />
        </clipPath>
        <clipPath id="clip-eye-2-${id}">
          <circle cx="${eyeWhite2Cx}" cy="${eyeWhite2Cy}" r="6" />
        </clipPath>
      </defs>

      <rect id="bg" x="0" y="0" width="100" height="100" fill="${bgColor}"/>

      <g id="body-group">
        <circle id="body" cx="${bodyCx}" cy="${bodyCy}" r="50" fill="${bodyColor}" />

        <circle id="eye-white-1" cx="${eyeWhite1Cx}" cy="${eyeWhite1Cy}" r="6" fill="${eyeWhiteColor}" />
        <circle id="eye-pupil-1" cx="${eyePupil1Cx}" cy="${eyePupil1Cy}" r="5" fill="#0A0B15" clip-path="url(#clip-eye-1-${id})" />

        <circle id="eye-white-2" cx="${eyeWhite2Cx}" cy="${eyeWhite2Cy}" r="6" fill="${eyeWhiteColor}" />
        <circle id="eye-pupil-1" cx="${eyePupil2Cx}" cy="${eyePupil2Cy}" r="5" fill="#0A0B15" clip-path="url(#clip-eye-2-${id})" />

        <g transform="translate(${mouthX}, ${mouthY})" id="mouth">
          ${faceExpression}
        </g>
      </g>
    </svg>
  `;
}

used in:

apps/site/src/frontend/components/boop-avatar/index.tsx:L37-L54

export function CustomBoopAvatar(props: ICustomBoopAvatarProps) {
  return (
    <BoopAvatarWrapper
      classList={props.classList}
      size={props.size}
      ref={(r) => {
        r.innerHTML = makeAvatarSvgCustom(
          props.id,
          props.bodyColor,
          props.angle,
          FACE_EXPRESSIONS[props.faceExpression - 1],
          props.bgColor,
          props.eyeWhiteColor,
        );
      }}
    />
  );
}

packages/client/src/identity.ts:L69-L83

/**
 * ## Returns user's avatar for current MSQ identity
 *
 * This avatar is an auto-generated SVG image
 * and should be treated as an easy way to render avatars for users without profiles.
 *
 * @param {string | undefined} bgColor
 * @returns {Promise<string>} avatar SVG src string as "data:image/svg+xml..."
 */
getAvatarSrc(bgColor?: string): Promise<string> {
  const principal = this.getPrincipal();
  const svg = btoa(makeAvatarSvg(principal, bgColor));

  return Promise.resolve(`data:image/svg+xml;base64,${svg}`);
}

apps/demo/src/frontend/pages/index/index.tsx:L73-L76

const profile: IProfile = {
  pseudonym: await identity.getPseudonym(),
  avatarSrc: await identity.getAvatarSrc(),
};

used with innerHTML

apps/site/src/frontend/components/boop-avatar/index.tsx:L15-L24

export function BoopAvatar(props: IBoopAvatarProps) {
  return (
    <BoopAvatarWrapper
      size={props.size}
      ref={(r) => {
        r.innerHTML = makeAvatarSvg(props.principal);
      }}
    />
  );
}

Recommendation

Runtime typecheck provided values (numbers vs. strings). Sanitize and validate arguments before embedding then with HTML or use a templating language to build the SVG (recommended)

Description

On certain occasions, the snap may need to present a dialog to the user to request confirmation for an action or data verification. This step is crucial as dapps are not always trusted, and it’s essential to prevent scenarios where they can silently sign data or perform critical operations using the user’s keys without explicit permission. To create custom user-facing dialogs, MetaMask provides the Snaps UI package, equipped with style-specific components. However, some of these components have been found to have potentially unintended side-effects.

For instance, the text() component can render Markdown or allow for control character injections. Specifically this poses a concern because users trust information displayed by the Snap.

In the code snippet provided below, please note that the variable body is provided by the dApp. It may contain Markdown renderable strings or Control Characters that can disrupt the context of the user-displayed message. It appears that only protected methods (admin origin) are affected by this, which is reflected in the severity rating of this finding.

Examples

• protected_handleAddAssetAccount - decodes ZICRC1AddAssetAccountRequest from CBOR with body potentially containing markdown or control chars.

packages/snap/src/protocols/icrc1.ts:L90-L107

export async function protected_handleAddAssetAccount(bodyCBOR: string): Promise<string | null> {
  const body = zodParse(ZICRC1AddAssetAccountRequest, fromCBOR(bodyCBOR));
  const manager = await StateManager.make();

  const agreed = await snap.request({
    method: "snap_dialog",
    params: {
      type: "confirmation",
      content: panel([
        heading(`🔒 Confirm New ${body.symbol} Account 🔒`),
        text(`Are you sure you want to create a new **${body.name}** (**${body.symbol}**) token account?`),
        text(`This will allow you to send and receive **${body.symbol}** tokens.`),
        divider(),
        text("**Confirm?** 🚀"),
      ]),
    },
  });

• protected_handleAddAsset - body

packages/snap/src/protocols/icrc1.ts:L59-L78

export async function protected_handleAddAsset(bodyCBOR: string): Promise<IAssetDataExternal[] | null> {
  const body = zodParse(ZICRC1AddAssetRequest, fromCBOR(bodyCBOR));
  const manager = await StateManager.make();

  const assetNames = body.assets.filter((it) => it.name && it.symbol).map((it) => `${it.name} (${it.symbol})`);

  if (assetNames.length > 0) {
    const agreed = await snap.request({
      method: "snap_dialog",
      params: {
        type: "confirmation",
        content: panel([
          heading(`🔒 Confirm New Assets 🔒`),
          text(`Are you sure you want to add the following tokens to your managed assets list?`),
          ...assetNames.map((it) => text(` - **${it}**`)),
          divider(),
          text("**Confirm?** 🚀"),
        ]),
      },
    });

• protected_handleShowICRC1TransferConfirm - body

packages/snap/src/protocols/icrc1.ts:L26-L57

export async function protected_handleShowICRC1TransferConfirm(bodyCBOR: string): Promise<boolean> {
  const body = zodParse(ZShowICRC1TransferConfirmRequest, fromCBOR(bodyCBOR));

  const agreed = await snap.request({
    method: "snap_dialog",
    params: {
      type: "confirmation",
      content: panel([
        heading(`💳 Confirm ${body.ticker} Transfer 💳`),
        text("**Protocol:**"),
        text("ICRC-1"),
        text("**Initiator:**"),
        text(`🌐 ${originToHostname(body.requestOrigin)}`),
        text("**From:**"),
        text(body.from),
        text("**To principal ID:**"),
        text(body.to.owner),
        text("**To subaccount ID:**"),
        text(body.to.subaccount !== undefined ? bytesToHex(body.to.subaccount) : "Default subaccount ID"),
        text("**Total amount:**"),
        heading(`${body.totalAmountStr} ${body.ticker}`),
        divider(),
        heading("🚨 BE CAREFUL! 🚨"),
        text("This action is irreversible. You won't be able to recover your funds!"),
        divider(),
        text("**Confirm?** 🚀"),
      ]),
    },
  });

  return Boolean(agreed);
}

Recommendation

Validate inputs. Encode data in a safe way to be displayed to the user (markdown, control chars). Show the original data provided within a pre-text or code block (copyable). Consider setting markdown: false for text ui components that do not render text.

../packages/snaps-sdk/src/ui/components/text.ts:L34-L53

/**
 * Create a {@link Text} node.
 *
 * @param args - The node arguments. This can be either a string
 * and a boolean, or an object with a `value` property
 * and an optional `markdown` property.
 * @param args.value - The text content of the node.
 * @param args.markdown - An optional flag to enable or disable markdown. This
 * is enabled by default.
 * @returns The text node as object.
 * @example
 * const node = text({ value: 'Hello, world!' });
 * const node = text('Hello, world!');
 * const node = text({ value: 'Hello, world!', markdown: false });
 * const node = text('Hello, world!', false);
 */
export const text = createBuilder(NodeType.Text, TextStruct, [
  'value',
  'markdown',
]);

const node = text({ value: 'Hello, world!', markdown: false });

Description

The function hexToBytes aims to convert a hex string into a Uint8Array. It splits the string into parts of two characters each and then tries to parse each part into an integer.

However, the function fails to validate that the provided hexString is of valid hex characters only. This may lead to the function interpreting non-hex characters incorrectly as zero bytes while it should throw an exception/report an error condition instead.

In the case where hexString contains non-hex characters, the parseInt will return NaN which in turn gets mapped to [00, ..] elements in the resulting Uint8Array.

Examples

packages/shared/src/encoding.ts:L42-L58

/**
 * ## Decodes {@link Uint8Array} from hex-string
 *
 * @see {@link bytesToHex}
 *
 * @param hexString
 * @returns
 */
export const hexToBytes = (hexString: string): Uint8Array => {
  const matches = hexString.match(/.{1,2}/g);

  if (matches == null) {
    throw new Error("Invalid hexstring");
  }

  return Uint8Array.from(matches.map((byte) => parseInt(byte, 16)));
};

Recommendation

Before passing the hex string into parseInt function, add validation checks to verify if the given string is a valid hex string of correct length.

export const hexToBytes = (hexString: string): Uint8Array => {
    if (!/^([0-9A-Fa-f]{2})+$/.test(hexString)) {
        throw new Error("Invalid hexstring");
    }
   
    const matches = hexString.match(/.{1,2}/g); 
    return Uint8Array.from(matches.map((byte) => {
        const parsed = parseInt(byte, 16);
        if (isNaN(parsed)) {
            throw new Error('Invalid byte found')
        }
        return parsed;
    }));
}; 

Description

While reviewing the codebase, we identified multiple instances of unused imports across the project’s files. The presence of these unused imports may affect its maintainability and readability.

Examples

(This list is not exhaustive)

• IStatisticsData, ZStatisticsData

packages/snap/src/protocols/statistics.ts:L1-L8

import {
  IStatisticsData,
  type IStatistics,
  ZStatisticsData,
  zodParse,
  fromCBOR,
  ZStatisticsIncrementRequest,
} from "@fort-major/msq-shared";

• jsSHA, Crc32, duplicate import Principal

packages/shared/src/encoding.ts:L1-L5

import { Principal } from "@dfinity/principal";
import { Encoder } from "cbor-x";
import { Crc32 } from "@aws-crypto/crc32";
import jsSHA from "jssha";

• IMetaMaskEthereumProvider

packages/client/src/client.ts:L1

import { IGetSnapsResponse, IMetaMaskEthereumProvider, ISnapRequest } from "./types";

Recommendation

Remove unused imports. Implementing a linter in the development workflow can help automate the detection and removal of such imports, ensuring a cleaner codebase and promoting best coding practices.