Closed harsh-kaleris closed 5 days ago
One more
application/node_modules/@esbuild/linux-x64/bin/esbuild (gobinary) Total: 1 (CRITICAL: 1)
┌─────────┬────────────────┬──────────┬────────┬───────────────────┬─────────────────┬────────────────────────────────────────────────────────────┐
│ Library │ Vulnerability │ Severity │ Status │ Installed Version │ Fixed Version │ Title │
├─────────┼────────────────┼──────────┼────────┼───────────────────┼─────────────────┼────────────────────────────────────────────────────────────┤
│ stdlib │ CVE-2024-24790 │ CRITICAL │ fixed │ 1.20.7 │ 1.21.11, 1.22.4 │ golang: net/netip: Unexpected behavior from Is methods for │
│ │ │ │ │ │ │ IPv4-mapped IPv6 addresses │
│ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2024-24790 │
└─────────┴────────────────┴──────────┴────────┴───────────────────┴─────────────────┴────────────────────────────────────────────────────────────┘
Does anyone know how to solve it while there's no update?
I have a ci/cd that is using TrivyDB, and I can't deploy the application.
Does anyone know how to solve it while there's no update?
I have a ci/cd that is using TrivyDB, and I can't deploy the application.
I'll start by saying, you should consider this suggestion only if you're confident you're not really impacted by the vulnerability. By ignoring the CVE you're "accepting" the risk, willfully.
Trivy will respect a .trivyignore
file's contents and skip over any CVEs you list within that file.
https://aquasecurity.github.io/trivy/v0.48/docs/configuration/filtering/#trivyignore
Note that esbuild's network features are not security sensitive as they are intended to only be used in development, not in production. You're welcome to DoS your own development server if you'd like to, but you're only harming yourself. None of these CVEs are actually relevant for esbuild. This is all just noise and false positives.
@evanw, by when can we expect these changes to be published to npm?
I have no specific date, but now that it's in main
it will go out with the next release.
I saw the bump related to crypto.getRandomValues
; the change that made it required in Go was https://go-review.googlesource.com/c/go/+/463975, but that's pretty easy to undo in userspace since they were already patching the crypto module.
For better or for worse, TypeScript still builds/tests on Node 14, so I was planning on re-applying that before importing esbuild for our build. Are you planning on using any other new syntax from newer versions of Node now that the engines has bumped to Node v18? I'm hoping not, but I totally understand that there's no guarantee of that anymore.
The requirement is specifically from the esbuild-wasm
package, which you might not even be using. I tried to patch it myself which worked for the package shim, since that's code that I control. But that didn't fix esbuild's WebAssembly tests, which do GOOS=js GOARCH=wasm go test
which runs the WebAssembly binary directly via node using Go's internal JavaScript host without the possibility of shimming it AFAIK. At that point I realized that node 18 is the oldest version of node that hasn't been abandoned yet so I figured it'd make sense to just require node 18. I wanted to be able to run tests on the versions of node and Go that I'm committing to support. If I remember correctly, another upcoming problem was that GitHub Actions is deprecating old node images and is going to remove them at some point, in which case esbuild's CI itself will break unless esbuild runs tests with a supported version of node.
For better or for worse, TypeScript still builds/tests on Node 14
What exactly is TypeScript using node 14 for? From what I understand, the published code in the typescript
package is generated using esbuild but esbuild isn't actually a dependency of the typescript
package, so the version of esbuild that's used to build TypeScript shouldn't impact what people can use the typescript
package. Are you saying you need to support people building the TypeScript compiler using node 14 (which reached end of life over a year ago)?
Are you planning on using any other new syntax from newer versions of Node now that the engines has bumped to Node v18? I'm hoping not, but I totally understand that there's no guarantee of that anymore.
I'm not currently using any newer syntax. The syntax target is actually still locked to node 10.
So I think as long as you aren't using WebAssembly, esbuild's API should still work in old versions of node without you needing to shim anything related to crypto
. The node compatibility differences with this release are a) esbuild's WebAssembly shim now won't work below node 18 and b) most of esbuild's tests are no longer run on node versions earlier than node 18, so those node versions no longer have much test coverage.
What exactly is TypeScript using node 14 for? From what I understand, the published code in the typescript package is generated using esbuild but esbuild isn't actually a dependency of the typescript package, so the version of esbuild that's used to build TypeScript shouldn't impact what people can use the typescript package. Are you saying you need to support people building the TypeScript compiler using node 14 (which reached end of life over a year ago)?
TypeScript itself still supports running within Node 14, but since our build uses esbuild's API, it would be a little awkward to restructure things like the testing task to build with one version of Node then switch to another for the tests.
So I think as long as you aren't using WebAssembly, esbuild's API should still work in old versions of node without you needing to shim anything related to crypto.
Oh, duh, of course, I forgot that we just use the binary, nevermind. Not using the wasm there at all. I'm not sure how I made that mistake! So it's just the syntax, of course.
Our project is utilising Esbuild. However there is an issue with the Go dependency at the latest Esbuild version of v0.21.5, as it us being flagged out with a number of vulnerabilities. It would be really nice to push the Go dependency version to newer version and resolve this. This affects the credibility of esbuild, we do not want to use something else but we may have to only for this issue.
List of vulnerabilities for reference - CVE-2023-45288, CVE-2023-45289, CVE-2023-45290, CVE-2024-24783, CVE-2024-24784, CVE-2024-24785, CVE-2024-24789, CVE-2024-24790