Skip to content

add deprecated comment to DOMAIN_SEPARATOR function#6366

Open
nugi32 wants to merge 3 commits intoOpenZeppelin:masterfrom
nugi32:add-deprecated-to-DOMAIN_SEPARATOR
Open

add deprecated comment to DOMAIN_SEPARATOR function#6366
nugi32 wants to merge 3 commits intoOpenZeppelin:masterfrom
nugi32:add-deprecated-to-DOMAIN_SEPARATOR

Conversation

@nugi32
Copy link
Copy Markdown

@nugi32 nugi32 commented Feb 23, 2026

Title:

docs: deprecate DOMAIN_SEPARATOR in ERC20Permit

Description:

This PR addresses issue #6363.

The DOMAIN_SEPARATOR() function in ERC20Permit is marked as deprecated in preparation for its removal in the next major release (v6.0). The deprecation aligns with the transition toward ERC-5267 domain introspection (eip712Domain) and avoids maintaining redundant interfaces going forward.

Changes:

Added a @deprecated NatSpec annotation to DOMAIN_SEPARATOR().

The deprecation notice explicitly recommends using ERC-5267 (eip712Domain) instead.

No behavioral changes were introduced.

No function removal was performed to avoid breaking changes in the current release line.

Rationale:

The DOMAIN_SEPARATOR() getter exposes the EIP-712 domain separator directly, but with ERC-5267 support available, domain information can be accessed through standardized mechanisms. Marking this function as deprecated signals its planned removal while maintaining backward compatibility until the next major version.

Implementation
/// @inheritdoc IERC20Permit
// solhint-disable-next-line func-name-mixedcase
/// @deprecated Use ERC-5267 (via {eip712Domain}) instead. This function will be removed in v6.0.
function DOMAIN_SEPARATOR() external view returns (bytes32) {
return _domainSeparatorV4();
}

Notes:

If additional steps are required (e.g., changelog entry or documentation updates), I am happy to include them.

@nugi32 nugi32 requested a review from a team as a code owner February 23, 2026 09:48
@changeset-bot
Copy link
Copy Markdown

changeset-bot bot commented Feb 23, 2026

🦋 Changeset detected

Latest commit: 1a52df2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
openzeppelin-solidity Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Feb 23, 2026

Walkthrough

Documentation was added to the public DOMAIN_SEPARATOR() function in both ERC20Permit.sol and IERC20Permit.sol to mark the function as deprecated. The deprecation notice indicates that ERC-5267's eip712Domain should be used instead and that the function will be removed in v6.0. No changes were made to function signatures or behavior.

Possibly related issues

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the primary change: adding a deprecation comment to the DOMAIN_SEPARATOR function in ERC20Permit.sol.
Description check ✅ Passed The description is directly related to the changeset, explaining the deprecation of DOMAIN_SEPARATOR(), the rationale, and the implementation details.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@contracts/token/ERC20/extensions/ERC20Permit.sol`:
- Around line 72-74: The NatSpec for DOMAIN_SEPARATOR() in ERC20Permit.sol is
broken by an inline solhint comment and uses an invalid `@deprecated` tag; update
the contiguous triple-slash docblock so it includes both the inheritdoc and
deprecation tag (replace `@deprecated` with `@custom`:deprecated) and then place the
// solhint-disable-next-line func-name-mixedcase comment after the closing
docblock so it does not split the NatSpec; apply the same tag fix in
IERC20Permit.sol (replace `@deprecated` with `@custom`:deprecated) or move the
deprecation text into an `@dev` description.

In `@contracts/token/ERC20/extensions/IERC20Permit.sol`:
- Around line 87-88: In the IERC20Permit.sol doc comment that mentions ERC-5267
(via {eip712Domain}), replace the invalid NatSpec tag "@deprecated" with the
supported custom tag "@custom:deprecated" and remove the trailing whitespace on
the blank documentation line so Prettier and the formal verification pipeline
accept the file; update the comment text near the ERC-5267 reference accordingly
(look for the comment block in IERC20Permit.sol that contains "This function
will be removed in v6.0." and edit the tag and whitespace there).

ℹ️ Review info

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6b55a93 and f9b07be.

📒 Files selected for processing (2)
  • contracts/token/ERC20/extensions/ERC20Permit.sol
  • contracts/token/ERC20/extensions/IERC20Permit.sol

Comment on lines +72 to +74
/// @inheritdoc IERC20Permit
// solhint-disable-next-line func-name-mixedcase
/// @deprecated Use ERC-5267 (via {eip712Domain}) instead. This function will be removed in v6.0.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

# First, locate and read the ERC20Permit.sol file around lines 72-74
find . -name "ERC20Permit.sol" -type f | head -5

Repository: OpenZeppelin/openzeppelin-contracts

Length of output: 129


🏁 Script executed:

# Once we have the file, read lines 70-80 to see the full context
sed -n '70,80p' contracts/token/ERC20/extensions/ERC20Permit.sol

Repository: OpenZeppelin/openzeppelin-contracts

Length of output: 384


🏁 Script executed:

# Also check the interface IERC20Permit.sol to see if deprecation is defined there
find . -name "IERC20Permit.sol" -type f

Repository: OpenZeppelin/openzeppelin-contracts

Length of output: 130


🏁 Script executed:

# Search for `@deprecated` usage in the codebase to understand conventions
rg "@deprecated" --type sol -B 2 -A 2 | head -50

Repository: OpenZeppelin/openzeppelin-contracts

Length of output: 106


🌐 Web query:

Solidity NatSpec @deprecated tag valid documentation

💡 Result:

@deprecated is not a Solidity NatSpec tag that the Solidity compiler recognizes. Solidity only supports the tags listed in the NatSpec docs (@title, @author, @notice, @dev, @param, @return, @inheritdoc, and @custom:...)—anything else (including @deprecated) is not part of the compiler-interpreted NatSpec set. [1]

What to use instead (valid NatSpec):

  • Put the deprecation note in @dev (and/or @notice for end users). [1]
  • Or use a custom tag such as @custom:deprecated (this is explicitly supported; semantics are tool-defined). [1]

Example:

/// `@notice` Deprecated: use fooV2() instead.
/// `@dev` Deprecated since v1.3.0; will be removed after 2026-06-01.
/// `@custom`:deprecated use fooV2()
function foo() external { }

Sources:
[1] Solidity docs: NatSpec format and supported tags list. (docs.soliditylang.org)

Citations:


🏁 Script executed:

# Check the IERC20Permit.sol file for DOMAIN_SEPARATOR definition and deprecation note
sed -n '1,100p' contracts/token/ERC20/extensions/IERC20Permit.sol | cat -n

Repository: OpenZeppelin/openzeppelin-contracts

Length of output: 4641


🏁 Script executed:

# Search for DOMAIN_SEPARATOR in IERC20Permit to see its NatSpec
rg "DOMAIN_SEPARATOR" contracts/token/ERC20/extensions/IERC20Permit.sol -B 5 -A 2

Repository: OpenZeppelin/openzeppelin-contracts

Length of output: 432


Two issues: @deprecated is an invalid NatSpec tag (pipeline blocker), and the solhint comment breaks the NatSpec block structure in the implementation.

Issue 1 — Invalid tag: @deprecated is not a recognized Solidity NatSpec tag. Valid tags are @title, @author, @notice, @dev, @param, @return, @inheritdoc, and @custom:*. This will cause documentation parsing errors. The same invalid tag also appears in IERC20Permit.sol (line 88), so both files must be corrected.

Issue 2 — Broken NatSpec block in implementation: The plain // solhint-disable-next-line comment at line 73 terminates the contiguous /// NatSpec block that started with /// @inheritdoc at line 72. The parser associates only the immediately preceding contiguous `///` block with a function, so the `/// `@deprecated at line 74 becomes the sole docstring for DOMAIN_SEPARATOR(), orphaning @inheritdoc. (This issue does not affect the interface, which uses block comment format.)

Fix: Use @custom:deprecated and keep the NatSpec block contiguous. The solhint directive must come after the NatSpec block ends:

Recommended fix
  /// `@inheritdoc` IERC20Permit
+ /// `@custom`:deprecated Use ERC-5267 (via {eip712Domain}) instead. This function will be removed in v6.0.
  // solhint-disable-next-line func-name-mixedcase
- /// `@deprecated` Use ERC-5267 (via {eip712Domain}) instead. This function will be removed in v6.0.
  function DOMAIN_SEPARATOR() external view returns (bytes32) {

Also correct the identical invalid tag in IERC20Permit.sol line 88 from @deprecated to @custom:deprecated or move it into the @dev description.

🧰 Tools
🪛 GitHub Actions: checks

[error] 74-74: DocstringParsingError: Documentation tag @deprecated not valid for functions.

🪛 GitHub Actions: formal verification

[error] 74-74: Documentation tag @deprecated not valid for functions.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@contracts/token/ERC20/extensions/ERC20Permit.sol` around lines 72 - 74, The
NatSpec for DOMAIN_SEPARATOR() in ERC20Permit.sol is broken by an inline solhint
comment and uses an invalid `@deprecated` tag; update the contiguous triple-slash
docblock so it includes both the inheritdoc and deprecation tag (replace
`@deprecated` with `@custom`:deprecated) and then place the //
solhint-disable-next-line func-name-mixedcase comment after the closing docblock
so it does not split the NatSpec; apply the same tag fix in IERC20Permit.sol
(replace `@deprecated` with `@custom`:deprecated) or move the deprecation text into
an `@dev` description.

Comment on lines +87 to +88
*
* @deprecated Use ERC-5267 (via {eip712Domain}) instead. This function will be removed in v6.0.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

cat -n contracts/token/ERC20/extensions/IERC20Permit.sol | sed -n '80,95p'

Repository: OpenZeppelin/openzeppelin-contracts

Length of output: 750


🌐 Web query:

Solidity NatSpec documentation valid tags @deprecated custom tags specification

💡 Result:

Solidity NatSpec: valid tags (compiler-supported)

Solidity’s official NatSpec parser recognizes these tags: @title, @author, @notice, @dev, @param, @return, @inheritdoc, and @custom:... (application-defined). [1]

Is @deprecated a valid NatSpec tag?

No—@deprecated is not one of Solidity’s supported NatSpec tags (so Solidity won’t treat it specially when producing userdoc / devdoc). [1]

Custom tags (@custom:...) specification

  • Must start with @custom:
  • The name after : must be one or more lowercase letters or hyphens
  • It cannot start with a hyphen
  • Can be used everywhere
  • Included in the developer documentation output (devdoc) [1]

Practical pattern for deprecation: use something like @custom:deprecated (and/or note deprecation in @notice / @dev). [1]

Source
[1] Solidity docs — “NatSpec Format” (supported tags + @custom: rules): https://docs.soliditylang.org/en/latest/natspec-format.html


@deprecated is not a valid NatSpec tag — use @custom:deprecated instead and fix trailing whitespace.

Solidity's NatSpec specification only supports: @title, @author, @notice, @dev, @param, @return, @inheritdoc, and custom tags via @custom: prefix (followed by one or more lowercase letters or hyphens, not starting with a hyphen). The bare @deprecated tag is not recognized and will cause the formal verification pipeline to fail.

Additionally, line 87 has trailing whitespace on the blank documentation line, which Prettier will flag.

Replace @deprecated with @custom:deprecated and remove the trailing space:

📝 Proposed fix
  /**
   * `@dev` Returns the domain separator used in the encoding of the signature for {permit}, as defined by {EIP712}.
-  * 
-  * `@deprecated` Use ERC-5267 (via {eip712Domain}) instead. This function will be removed in v6.0.
+  *
+  * `@custom`:deprecated Use ERC-5267 (via {eip712Domain}) instead. This function will be removed in v6.0.
   */
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@contracts/token/ERC20/extensions/IERC20Permit.sol` around lines 87 - 88, In
the IERC20Permit.sol doc comment that mentions ERC-5267 (via {eip712Domain}),
replace the invalid NatSpec tag "@deprecated" with the supported custom tag
"@custom:deprecated" and remove the trailing whitespace on the blank
documentation line so Prettier and the formal verification pipeline accept the
file; update the comment text near the ERC-5267 reference accordingly (look for
the comment block in IERC20Permit.sol that contains "This function will be
removed in v6.0." and edit the tag and whitespace there).

@socket-security
Copy link
Copy Markdown

socket-security bot commented Feb 23, 2026

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

Diff Package Supply Chain
Security
Vulnerability Quality Maintenance License
Updatednpm/​rimraf@​6.1.2 ⏵ 6.1.399 +1100100 +187 +5100
Updatednpm/​p-limit@​7.2.0 ⏵ 7.3.0100100100 +187100
Updatednpm/​hardhat@​2.28.5 ⏵ 2.28.692 +110092 +19680
Updatednpm/​eslint@​9.39.2 ⏵ 9.39.389 +110010097100
Updatednpm/​semver@​7.7.3 ⏵ 7.7.410010010090100
Updatednpm/​glob@​13.0.0 ⏵ 13.0.6991009994100
Updatednpm/​undici@​7.19.2 ⏵ 7.22.096100100 +197100

View full report

@socket-security
Copy link
Copy Markdown

socket-security bot commented Feb 23, 2026

Caution

Review the following alerts detected in dependencies.

According to your organization's Security Policy, you must resolve all "Block" alerts before proceeding. Learn more about Socket for GitHub.

Action Severity Alert  (click "▶" to expand/collapse)
Block Low
Potential code anomaly (AI signal): npm ajv is 100.0% likely to have a medium risk anomaly

Notes: The code augments a meta-schema to permit remote dereferencing of keyword schemas via a hardcoded data.json resource. This introduces network dependency and potential changes to validation semantics at runtime. While not inherently malicious, the remote reference constitutes a notable security and reliability risk that should be mitigated with local fallbacks, input validation, and explicit remote-resource governance.

Confidence: 1.00

Severity: 0.60

From: pnpm-lock.yamlnpm/solhint@6.0.3npm/eslint@9.39.3npm/ajv@6.14.0

ℹ 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/ajv@6.14.0. 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.

Block Low
Potential code anomaly (AI signal): npm ajv is 100.0% likely to have a medium risk anomaly

Notes: The code is a straightforward build script to bundle and minify a specified package using Browserify and UglifyJS. The primary security concern is potential path manipulation: json.main is used to form a require path without validating that it stays within the target package directory. If a malicious or misconfigured package.json includes an absolute path or traversal outside the package, the script could bundle unintended files. Otherwise, the script does not perform network access, data exfiltration, or backdoor actions, and there is no hard-coded secrets or dynamic code execution beyond standard bundling/minification.

Confidence: 1.00

Severity: 0.60

From: pnpm-lock.yamlnpm/solhint@6.0.3npm/eslint@9.39.3npm/ajv@6.14.0

ℹ 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/ajv@6.14.0. 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.

Block Low
Potential code anomaly (AI signal): npm ajv is 100.0% likely to have a medium risk anomaly

Notes: The code implements a standard AJV-like dynamic parser generator for JTD schemas. There are no explicit malware indicators in this fragment. The primary security concern is the dynamic code generation and execution from external schemas, which introduces a medium risk if schemas are untrusted. With trusted schemas and proper schema management, the risk is typically acceptable within this pattern.

Confidence: 1.00

Severity: 0.60

From: pnpm-lock.yamlnpm/solhint@6.0.3npm/@openzeppelin/upgrade-safe-transpiler@0.4.1npm/ajv@8.18.0

ℹ 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/ajv@8.18.0. 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.

Block Low
Potential code anomaly (AI signal): npm ajv is 100.0% likely to have a medium risk anomaly

Notes: The code implements standard timestamp validation with clear logic for normal and leap years and leap seconds. There is no network, file, or execution of external code within this isolated fragment. The only anomalous aspect is assigning a string to validTimestamp.code, which could enable external tooling to inject behavior in certain environments, but this does not constitute active malicious behavior in this isolated snippet. Overall, low to moderate security risk in typical usage; no malware detected within the shown code.

Confidence: 1.00

Severity: 0.60

From: pnpm-lock.yamlnpm/solhint@6.0.3npm/@openzeppelin/upgrade-safe-transpiler@0.4.1npm/ajv@8.18.0

ℹ 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/ajv@8.18.0. 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.

Block Low
Potential code anomaly (AI signal): npm ajv is 100.0% likely to have a medium risk anomaly

Notes: This module generates JavaScript code at runtime via standaloneCode(...) and then immediately executes it with require-from-string. Because the generated code can incorporate user-supplied schemas or custom keywords without sanitization or sandboxing, an attacker who controls those inputs could inject arbitrary code and achieve remote code execution in the Node process. Users should audit and lock down the standaloneCode output or replace dynamic evaluation with a safer, static bundling approach.

Confidence: 1.00

Severity: 0.60

From: pnpm-lock.yamlnpm/solhint@6.0.3npm/@openzeppelin/upgrade-safe-transpiler@0.4.1npm/ajv@8.18.0

ℹ 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/ajv@8.18.0. 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.

Block Low
Potential code anomaly (AI signal): npm axios is 100.0% likely to have a medium risk anomaly

Notes: The code provides a simple, non-obfuscated data-format normalization transform that prepends a zlib header when the incoming first byte is not 0x78. While this can enable downstream consumers that expect a zlib-like header, it can also corrupt data streams that are already compressed or use a different framing. There is no malicious activity detected, but the transformation should be used with clear data-format expectations and possibly a configurable option to enable/disable header insertion.

Confidence: 1.00

Severity: 0.60

From: pnpm-lock.yamlnpm/hardhat-gas-reporter@2.3.0npm/axios@1.13.5

ℹ 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/axios@1.13.5. 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.

Block Low
Potential code anomaly (AI signal): npm glob is 100.0% likely to have a medium risk anomaly

Notes: The Glob utilities implement a conventional and well-structured filesystem glob-walking mechanism with robust control flow (abort signals, backpressure) and safe output semantics. There is no evidence of malicious behavior, backdoors, or data exfiltration within this fragment. Risks mainly relate to how downstream consumers may handle emitted paths, not to the library itself.

Confidence: 1.00

Severity: 0.60

From: package-lock.jsonnpm/glob@13.0.6

ℹ 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/glob@13.0.6. 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.

Block Low
Potential code anomaly (AI signal): npm resolve is 100.0% likely to have a medium risk anomaly

Notes: This manifest uses a non-registry, relative-path dependency ('resolve': '../../../') which is a significant supply-chain risk because it allows arbitrary local code to be pulled in and executed without registry protections. Combined with the 'lerna bootstrap' postinstall script (which can trigger other lifecycle scripts across the monorepo), this setup increases the chance of untrusted code execution and other malicious behavior. Inspect the target of the relative path, all bootstrap-linked packages, and any lifecycle scripts before running npm install in an untrusted environment.

Confidence: 1.00

Severity: 0.60

From: pnpm-lock.yamlnpm/solidity-coverage@0.8.17npm/resolve@1.22.11

ℹ 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/resolve@1.22.11. 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.

View full report

@nugi32
Copy link
Copy Markdown
Author

nugi32 commented Mar 1, 2026

hi?

@Moses-main

This comment was marked as spam.

Copy link
Copy Markdown
Collaborator

@Amxx Amxx Mar 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The DOMAIN_SEPARATOR function is part of ERC-2612. We cannot just remove it from here

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.

3 participants