Describe the bug
Deny check doesn't respect namespaces of denied packages, thus denying incorrect/different packages.
To Reproduce
Steps to reproduce the behavior:
- Go to any project with some packages.
(ex.: a repo that has the valid eslint pkg as a dependency)
- Have a config with a denied package, that has the same name, but a different namespace.
(ex.: deny the malware @typescript_eslinter/eslint pkg)
- Run the action.
- See that it fails and lists the regular
eslint as a denied package.
Expected behavior
I would expect the deny check to respect namespaces and only deny the actual packages provided.
Action version
uses: actions/dependency-review-action@v4
Examples
Example: content-services/content-sources-frontend#716 (comment)
Additional context
We do pipe a lot of malicious/malware packages (we take that info from the aikido intel malware database) into the denied packages option in this task. So we ran into this issue, because of the "fake" packages with the same names, but different namespaces.
This is happening because this check doesn't look at the pkg namespaces.
Describe the bug
Deny check doesn't respect namespaces of denied packages, thus denying incorrect/different packages.
To Reproduce
Steps to reproduce the behavior:
(ex.: a repo that has the valid
eslintpkg as a dependency)(ex.: deny the malware
@typescript_eslinter/eslintpkg)eslintas a denied package.Expected behavior
I would expect the deny check to respect namespaces and only deny the actual packages provided.
Action version
uses: actions/dependency-review-action@v4Examples
Example: content-services/content-sources-frontend#716 (comment)
Additional context
We do pipe a lot of malicious/malware packages (we take that info from the aikido intel malware database) into the denied packages option in this task. So we ran into this issue, because of the "fake" packages with the same names, but different namespaces.
This is happening because this check doesn't look at the pkg namespaces.