Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Snyk] Upgrade solidity-coverage from 0.7.17 to 0.8.4 #61

Open
wants to merge 1 commit into
base: release-v4.5
Choose a base branch
from

Conversation

Woodpile37
Copy link
Owner

This PR was automatically created by Snyk using the credentials of a real user.


Snyk has created this PR to upgrade solidity-coverage from 0.7.17 to 0.8.4.

ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.


  • The recommended version is 15 versions ahead of your current version.
  • The recommended version was released 2 months ago, on 2023-07-04.

The recommended version fixes:

Severity Issue PriorityScore (*) Exploit Maturity
Prototype Poisoning
SNYK-JS-QS-3153490
482/1000
Why? Proof of Concept exploit, CVSS 7.5
Proof of Concept
Regular Expression Denial of Service (ReDoS)
SNYK-JS-SEMVER-3247795
482/1000
Why? Proof of Concept exploit, CVSS 7.5
Proof of Concept
Regular Expression Denial of Service (ReDoS)
SNYK-JS-SEMVER-3247795
482/1000
Why? Proof of Concept exploit, CVSS 7.5
Proof of Concept
Prototype Pollution
SNYK-JS-UNSETVALUE-2400660
482/1000
Why? Proof of Concept exploit, CVSS 7.5
No Known Exploit
Prototype Pollution
SNYK-JS-Y18N-1021887
482/1000
Why? Proof of Concept exploit, CVSS 7.5
Proof of Concept
Prototype Pollution
SNYK-JS-JSON5-3182856
482/1000
Why? Proof of Concept exploit, CVSS 7.5
Proof of Concept
Prototype Pollution
SNYK-JS-JSON5-3182856
482/1000
Why? Proof of Concept exploit, CVSS 7.5
Proof of Concept
Regular Expression Denial of Service (ReDoS)
SNYK-JS-UGLIFYJS-1727251
482/1000
Why? Proof of Concept exploit, CVSS 7.5
No Known Exploit
Denial of Service (DoS)
npm:mem:20180117
482/1000
Why? Proof of Concept exploit, CVSS 7.5
No Known Exploit
Cryptographic Issues
SNYK-JS-ELLIPTIC-1064899
482/1000
Why? Proof of Concept exploit, CVSS 7.5
No Known Exploit
Regular Expression Denial of Service (ReDoS)
SNYK-JS-GLOBPARENT-1016905
482/1000
Why? Proof of Concept exploit, CVSS 7.5
Proof of Concept
Open Redirect
SNYK-JS-GOT-2932019
482/1000
Why? Proof of Concept exploit, CVSS 7.5
No Known Exploit
Open Redirect
SNYK-JS-GOT-2932019
482/1000
Why? Proof of Concept exploit, CVSS 7.5
No Known Exploit
Authentication Bypass
SNYK-JS-HTTPAUTH-471683
482/1000
Why? Proof of Concept exploit, CVSS 7.5
No Known Exploit
Prototype Pollution
SNYK-JS-JSON5-3182856
482/1000
Why? Proof of Concept exploit, CVSS 7.5
Proof of Concept

(*) Note that the real score may have changed since the PR was raised.

Release notes
Package name: solidity-coverage
  • 0.8.4 - 2023-07-04

    What's Changed

    New Contributors

    Full Changelog: v0.8.2...v0.8.4

  • 0.8.3 - 2023-06-22
  • 0.8.2 - 2022-09-08

    What's Changed

    New Contributors

    Full Changelog: v0.8.1...v0.8.2

  • 0.8.1 - 2022-09-06

    What's Changed

    • Bug fix: restore missing web3-utils dependency by @ cgewecke in #743

    Full Changelog: v0.8.0...v0.8.1

  • 0.8.0 - 2022-09-05

    Hi!

    ⚠️ This version requires Hardhat >= 2.11.0 (Ethereum Merge)

    New Features

    A central focus of the 0.8.0 release is improving the coverage tool's branch detection.

    Beginning with this version the following syntax is measured as a branch:

    OR conditions

    When a logical expression is composed with the || operator, both sides can be considered branches. To test the entire expression

    if (a == 1 || a == 2)

    ... a must equal 1, 2 and neither of those values. (Thanks to Gnosis engineer @ rmeissner for proposing this in #175)

    Screen Shot 2021-01-12 at 9 41 09 PM

    Ternary Conditionals

    Long ago, when Solidity was 0.4, solidity-coverage treated ternary conditionals like regular if/else statements. Some language improvements v0.5 subsequently made this impossible. Now it's back...

    Screen Shot 2021-01-12 at 9 47 43 PM

    Modifier Invocations

    Solidity-coverage already covers the code within modifier definitions. However, each modifier invocation at the function level should really be considered its own branch. Some of the most critical logic in Solidity contracts is handled this way (ex: onlyOwner). Testing the pass/fail cases for each occurrence of these gates protects you from accidentally removing them during a refactor.

    Because it's possible to write a modifier which performs a preparatory task and never reverts, there's a new option (modifierWhitelist) which allows you to exclude specific modifiers from branch measurement.

    And if you don't like modifier invocation coverage you can turn it off by setting the option measureModifierCoverage to false.

    (Many thanks to OpenZeppelin engineer @ nventuro for proposing this improvement in #286 and helping to design it.)

    Screen Shot 2021-01-12 at 10 07 13 PM

    Test Matrix

    The hardhat and truffle plugins support a new cli flag: --matrix. (Short for "test matrix".)

    This flag generates a JSON object that maps which tests in your suite hit which lines of code. (An example can be seen at docs/matrix.md. More info can be found in the advanced docs, here.)

    This data is useful for many advanced testing applications - Security researcher @ JoranHonig has written two that are worth checking out.

    Coverage is often a core component of fuzzing and generative test strategies because it helps narrow the range of inputs required to traverse every path in the code. If you're working on applications like this and have ideas for how solidity-coverage might serve your ends, please feel free to open an issue.

    Note to Truffle users

    solidity-coverage for Truffle is moving to its own repository and published under a different name (details soon...).

  • 0.8.0-rc.test.0 - 2022-04-26
  • 0.8.0-rc.1 - 2022-03-29
  • 0.8.0-beta.1 - 2022-03-29
  • 0.8.0-beta.0 - 2021-01-13

    Hi!

    This beta contains several new features. A central focus of the next major release is improving the coverage tool's branch detection.

    Beginning with this version the following syntax is measured as a branch:

    OR conditions

    When a logical expression is composed with the || operator, both sides can be considered branches. To test the entire expression

    if (a == 1 || a == 2)

    ... a must equal 1, 2 and neither of those values. (Thanks to Gnosis engineer @ rmeissner for proposing this in #175)

    Screen Shot 2021-01-12 at 9 41 09 PM

    Ternary Conditionals

    Long ago, when Solidity was 0.4, solidity-coverage treated ternary conditionals like regular if/else statements. Some language improvements v0.5 subsequently made this impossible. Now it's back...

    Screen Shot 2021-01-12 at 9 47 43 PM

    Modifier Invocations

    Solidity-coverage already covers the code within modifier definitions. However, each modifier invocation at the function level should really be considered its own branch. Some of the most critical logic in Solidity contracts is handled this way (ex: onlyOwner and nonReentrant). Testing the pass/fail cases for each occurrence of these gates protects you from accidentally removing them during a refactor or emergency patch.

    Because it's possible to write a modifier which performs a preparatory task and never reverts, there's a new option (modifierWhitelist) which allows you to exclude specific modifiers from branch measurement.

    And if you don't like modifier invocation coverage you can turn it off by setting the option measureModifierCoverage to false.

    (Many thanks to OpenZeppelin engineer @ nventuro for proposing this improvement in #286 and helping to design it.)

    Screen Shot 2021-01-12 at 10 07 13 PM

    Test Matrix

    The hardhat and truffle plugins support a new cli flag: --matrix. (Short for "test matrix".)

    This flag generates a JSON object that maps which tests in your suite hit which lines of code. (An example can be seen at docs/matrix.md. More info can be found in the advanced docs, here.)

    This data is useful for many advanced testing applications - Consensys security researcher @ JoranHonig has written two that are worth checking out.

    Coverage is often a core component of fuzzing and generative test strategies because it helps narrow the range of inputs required to traverse every path in the code. If you're working on applications like this and have ideas for how solidity-coverage might serve your ends, please feel free to open an issue.

    What's Coming!

    We're hoping to get a major release out by the beginning of February (2021). It will include two additional features you can run in CI to get better feedback about what's changing in your code from PR to PR.

    • A unified diff of the public API changes in your contracts
    • Natspec documentation coverage
  • 0.7.22 - 2022-09-05
  • 0.7.21 - 2022-04-24
  • 0.7.20 - 2022-02-15
  • 0.7.19 - 2022-02-09
  • 0.7.18 - 2022-01-17
  • 0.7.18-eip165.0 - 2021-08-28
  • 0.7.17 - 2021-08-27
from solidity-coverage GitHub release notes
Commit messages
Package name: solidity-coverage

Compare


Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.

For more information:

🧐 View latest project report

🛠 Adjust upgrade PR settings

🔕 Ignore this dependency or unsubscribe from future upgrade PRs

@changeset-bot
Copy link

changeset-bot bot commented Aug 24, 2023

⚠️ No Changeset found

Latest commit: e9f2b7d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants