feat: use build env

[tuna1207]

Jira Link

Description

Upgrade deps and use build env

How has this been tested?

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• My code follows the code style of this project. (run lint)
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

---

Note

Medium Risk
Moderate risk because it changes how the SDK selects signer/metadata endpoints (new buildEnv param and Citadel allow URL), which could affect key retrieval/import flows if the environment mapping is wrong; the rest is dependency/version updates.

Overview
Bumps @toruslabs/torus.js to 17.2.0 and updates runtime/dev dependencies (notably @toruslabs/constants/fetch-node-details, plus vite/vitest and related lockfile changes).

Introduces an optional buildEnv constructor option and threads it through share retrieval/import so legacy metadata host selection is based on LEGACY_METADATA_MAP[buildEnv] and the “allow” gating call is routed via CITADEL_SERVER_MAP[buildEnv]/v1/signer/allow (removing the previous authorizationServerUrl/SIGNER_MAP path).

^{Written by Cursor Bugbot for commit c5bf756. This will update automatically on new commits. Configure here.}

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​toruslabs/​constants@​16.0.0 ⏵ 16.1.0				+1
	vitest@​4.0.18 ⏵ 4.1.0			+1	+2
	@​vitest/​coverage-istanbul@​4.0.18 ⏵ 4.1.0	+1		+11	+2
	@​toruslabs/​fetch-node-details@​16.0.0 ⏵ 16.1.0				+1
	lint-staged@​16.3.2 ⏵ 16.4.0				+1

View full report

[socket-security]

Warning

MetaMask internal reviewing guidelines:

• Do not ignore-all
• Each alert has instructions on how to review if you don't know what it means. If lost, ask your Security Liaison or the supply-chain group
• Copy-paste ignore lines for specific packages or a group of one kind with a note on what research you did to deem it safe.
  @SocketSecurity ignore npm/PACKAGE@VERSION

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		Potential code anomaly (AI signal): npm @rolldown/binding-wasm32-wasi is 90.0% likely to have a medium risk anomaly Notes: The JS loader is not itself executing obvious malicious JavaScript (no eval, no external network calls, no hard-coded credentials). However it intentionally grants a WebAssembly module broad privileges: it passes the full process.env into WASI and the worker, and preopens the host filesystem root so the wasm can access the filesystem. It also forwards worker messages into a filesystem proxy function. These design choices make running an untrusted or tampered-with wasm binary dangerous: a malicious wasm could read environment variables, enumerate and modify host files, and exfiltrate data via any network capability inside the wasm or worker. Therefore the module should be treated as high-risk if the wasm artifact (local file or npm package) is not from a trusted source. Recommended mitigations: avoid preopening the root (limit to specific directories), avoid passing full process.env, validate integrity of the wasm binary (signing/checksums), and avoid installing untrusted package replacements. Confidence: 0.90 Severity: 0.60 From: package-lock.json → npm/vitest@4.1.0 → npm/@rolldown/binding-wasm32-wasi@1.0.0-rc.10 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@rolldown/binding-wasm32-wasi@1.0.0-rc.10. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Potential code anomaly (AI signal): npm @rolldown/binding-wasm32-wasi is 90.0% likely to have a medium risk anomaly Notes: The file itself does not contain overt malicious code (no network calls, no obfuscated payloads, no hardcoded credentials). However, it deliberately exposes powerful capabilities to loaded WASM modules and local scripts: it passes all environment variables into WASI and preopens the filesystem root, and it implements importScripts by reading and eval-ing local files. These choices make the environment capable of data theft or system access if untrusted wasm or scripts are executed. Treat wasm modules and files loaded via importScripts as fully trusted/native — do not run untrusted modules with this loader. Recommend restricting WASI preopens to a minimal directory and avoid passing full process.env, and avoid eval-based importScripts when possible. Confidence: 0.90 Severity: 0.60 From: package-lock.json → npm/vitest@4.1.0 → npm/@rolldown/binding-wasm32-wasi@1.0.0-rc.10 ℹ Read more on: This package | This alert | What is an AI-detected potential code anomaly? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@rolldown/binding-wasm32-wasi@1.0.0-rc.10. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

Ignoring alerts on:

• detect-libc@2.1.2
• vite@8.0.1

View full report

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[cursor]

Authorization request drops useAPIKey option

High Severity

The old authorization code passed { useAPIKey: true } as the options argument to both the post and get calls, ensuring the configured API key was included in the request. The new get call at line 398 omits this option entirely. Every other similar HTTP call in the codebase (e.g., in metadataUtils.ts) still passes { useAPIKey: true }. If the citadel server requires the API key for authorization, all retrieveOrImportShare calls will fail.

 

[chaitanyapotti]

@SocketSecurity ignore npm/vite@8.0.1
@SocketSecurity ignore npm/detect-libc@2.1.2

Both the deps are only used for dev deps

[chaitanyapotti]

Tested against local server for now.
Tests are failing since prod server isn't live yet.
This is fine for now since this sdk isn't being used yet