100MB of Node.js modules shipped in the Boost release tarball
There are 482 Node.js modules included in the boost-1_91_0.tar.bz2 tarball, totalling more than 100MB, which is nearly 10% of the size of the entire tarball. Some of these node modules contain known CVEs, e.g. Boost.Redis bundles axios-1.10.0 which is affected by several denial of service and information disclosure CVEs. This causes Boost to be flagged when scanning for software supply chain problems. Do these modules really need to be shipped in the release, or are they only used to generate the HTML docs and could be omitted from the release tarball? I tried removing libs/redis/doc/node_modules/* and building from the release tarball, and everything succeeded. That suggests they're not needed.
Node.js modules included in the boost
Hi Jonathan, I believe this is solved, going forward, with boost 1.92.0. Download the latest boost 1.92.0 snapshot: https://archives.boost.io/develop/ https://archives.boost.io/develop/boost_1_92_0-snapshot.tar.bz2 No node_modules in the archive, right? On Wed, Jun 17, 2026 at 12:08 PM Jonathan Wakely via Boost < boost@lists.boost.org> wrote:
There are 482 Node.js modules included in the boost-1_91_0.tar.bz2 tarball, totalling more than 100MB, which is nearly 10% of the size of the entire tarball.
Some of these node modules contain known CVEs, e.g. Boost.Redis bundles axios-1.10.0 which is affected by several denial of service and information disclosure CVEs. This causes Boost to be flagged when scanning for software supply chain problems.
Do these modules really need to be shipped in the release, or are they only used to generate the HTML docs and could be omitted from the release tarball?
I tried removing libs/redis/doc/node_modules/* and building from the release tarball, and everything succeeded. That suggests they're not needed. _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/APKJIASX...
On Wed, 17 Jun 2026 at 19:18, Sam Darwin <samuel.d.darwin@gmail.com> wrote:
Node.js modules included in the boost
Hi Jonathan,
I believe this is solved, going forward, with boost 1.92.0.
Download the latest boost 1.92.0 snapshot: https://archives.boost.io/develop/ https://archives.boost.io/develop/boost_1_92_0-snapshot.tar.bz2
No node_modules in the archive, right?
Good to know, thanks. Will that be true for the final 1.92.0 release? I've lost count of the number of times that something gets fixed in the 'develop' branch and never makes it into a Boost release. Do you happen to know what fixed this, so I can point to an issue or pull request that made the change?
Will that be true for the final 1.92.0 release?
Yes, the final release is a copy of a snapshot.
Do you happen to know what fixed this, so I can point to an issue or pull request
On Wed, 17 Jun 2026, 19:33 Sam Darwin, <samuel.d.darwin@gmail.com> wrote:
Will that be true for the final 1.92.0 release?
Yes, the final release is a copy of a snapshot.
Great.
Do you happen to know what fixed this, so I can point to an issue or pull request
Nice, thanks! I didn't know about the release-tools repo, I'll try to remember that.
On 17 Jun 2026 21:17, Sam Darwin via Boost wrote:
Node.js modules included in the boost
Hi Jonathan,
I believe this is solved, going forward, with boost 1.92.0.
Download the latest boost 1.92.0 snapshot: https://archives.boost.io/develop/ https://archives.boost.io/develop/boost_1_92_0-snapshot.tar.bz2
No node_modules in the archive, right?
Given that these modules are downloaded during Boost build and have known vulnerabilities, this may pose a security thread to Boost building infrastructure. Is it possible to remove this dependency download or at the very least change the building process to rely only on the fixed, known good versions, with checksum/signature verification?
fixed known good versions
The nodejs installations use package-lock.json files to lock the versions. At the time of a boost release, a completely new archive isn't generated, suddenly introducing a problem. Rather, a previous snapshot is renamed. If a vulnerability appeared during the lock-down period, we would at least have some chance to react.
On 17 Jun 2026 21:58, Sam Darwin wrote:
fixed known good versions
The nodejs installations use package-lock.json files to lock the versions.
Does this mechanism guarantee fixed versions of the downloaded components of the entire dependency chain? That is, does it prevent a dependency from updating from one Boost build to another without our consent?
At the time of a boost release, a completely new archive isn't generated, suddenly introducing a problem. Rather, a previous snapshot is renamed. If a vulnerability appeared during the lock-down period, we would at least have some chance to react.
Then compromising a snapshot build is just as dangerous as compromising the release.
On Wed, Jun 17, 2026 at 1:53 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 17 Jun 2026 21:17, Sam Darwin via Boost wrote:
Node.js modules included in the boost
Hi Jonathan,
I believe this is solved, going forward, with boost 1.92.0.
Download the latest boost 1.92.0 snapshot: https://archives.boost.io/develop/ https://archives.boost.io/develop/boost_1_92_0-snapshot.tar.bz2
No node_modules in the archive, right?
Given that these modules are downloaded during Boost build and have known vulnerabilities, this may pose a security thread to Boost building infrastructure. Is it possible to remove this dependency download or at the very least change the building process to rely only on the fixed, known good versions, with checksum/signature verification?
Which code is downloading them? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net
On 17 Jun 2026 22:04, René Ferdinand Rivera Morell via Boost wrote:
On Wed, Jun 17, 2026 at 1:53 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 17 Jun 2026 21:17, Sam Darwin via Boost wrote:
Node.js modules included in the boost
Hi Jonathan,
I believe this is solved, going forward, with boost 1.92.0.
Download the latest boost 1.92.0 snapshot: https://archives.boost.io/develop/ https://archives.boost.io/develop/boost_1_92_0-snapshot.tar.bz2
No node_modules in the archive, right?
Given that these modules are downloaded during Boost build and have known vulnerabilities, this may pose a security thread to Boost building infrastructure. Is it possible to remove this dependency download or at the very least change the building process to rely only on the fixed, known good versions, with checksum/signature verification?
Which code is downloading them?
I don't know. I'm assuming they are downloaded as part of the documentation build process, perhaps via npm.
Hi! On Wed, 17 Jun 2026 at 20:08, Jonathan Wakely via Boost <boost@lists.boost.org> wrote:
There are 482 Node.js modules included in the boost-1_91_0.tar.bz2 tarball, totalling more than 100MB, which is nearly 10% of the size of the entire tarball.
Some of these node modules contain known CVEs, e.g. Boost.Redis bundles axios-1.10.0 which is affected by several denial of service and information disclosure CVEs. This causes Boost to be flagged when scanning for software supply chain problems.
Thanks for reporting this. Axios is a dependency of Antora, our build toolchain. I've submitted a PR to upgrade the package lock file and get rid of the vulnerable packages: https://github.com/boostorg/redis/pull/429 Even with that, the latest Antora release depends on js-yaml prior to 4.1.1, which is flagged as containing a moderate vulnerability (Quadratic-complexity DoS in merge key handling via repeated aliases - https://github.com/advisories/GHSA-h67p-54hq-rp68). I don't think it imposes a risk to us at this time, but I'll try to check in a few days and update if they fix it.
Do these modules really need to be shipped in the release, or are they only used to generate the HTML docs and could be omitted from the release tarball?
I tried removing libs/redis/doc/node_modules/* and building from the release tarball, and everything succeeded. That suggests they're not needed.
The npm packages are only required at doc build time, so it makes sense to not include them in the release tarball. Thanks, Ruben.
On Thu, 18 Jun 2026 at 10:19, Ruben Perez <rubenperez038@gmail.com> wrote:
Hi!
On Wed, 17 Jun 2026 at 20:08, Jonathan Wakely via Boost <boost@lists.boost.org> wrote:
There are 482 Node.js modules included in the boost-1_91_0.tar.bz2 tarball, totalling more than 100MB, which is nearly 10% of the size of the entire tarball.
Some of these node modules contain known CVEs, e.g. Boost.Redis bundles axios-1.10.0 which is affected by several denial of service and information disclosure CVEs. This causes Boost to be flagged when scanning for software supply chain problems.
Thanks for reporting this. Axios is a dependency of Antora, our build toolchain. I've submitted a PR to upgrade the package lock file and get rid of the vulnerable packages: https://github.com/boostorg/redis/pull/429
Even with that, the latest Antora release depends on js-yaml prior to 4.1.1, which is flagged as containing a moderate vulnerability (Quadratic-complexity DoS in merge key handling via repeated aliases - https://github.com/advisories/GHSA-h67p-54hq-rp68). I don't think it imposes a risk to us at this time, but I'll try to check in a few days and update if they fix it.
Any non-zero number of npm packages seems likely to contain at least one known CVE at any given time :-)
Do these modules really need to be shipped in the release, or are they only used to generate the HTML docs and could be omitted from the release tarball?
I tried removing libs/redis/doc/node_modules/* and building from the release tarball, and everything succeeded. That suggests they're not needed.
The npm packages are only required at doc build time, so it makes sense to not include them in the release tarball.
Yes. Vulnerability scanners don't care whether a package is actually used during the build, they just see a vulnerable version and flag it. So removing them from the release tarball shipped to users seems like the right thing to do. Presumably the limited uses of those packages within the doc generation aren't actually affected by most of the CVEs, e.g. I doubt anybody is concerned about information leakage or a proxy bypass when Axios is used to fetch some files during the doc generation step. But again, the scanners don't understand such nuances. Thanks for everybody's prompt responses to this (and to Sam for pointing me to the release tools change that removed them from the snapshots).
Presumably the limited uses of those packages within the doc generation aren't actually affected by most of the CVEs, e.g. I doubt anybody is concerned about information leakage or a proxy bypass when Axios is used to fetch some files during the doc generation step. But again, the scanners don't understand such nuances.
I get that. We had also trouble with test certificates that were used in CI to verify the TLS integration. They were flagged as if we had committed our .env to the repo ;). We've eventually got rid of these too.
Thanks for everybody's prompt responses to this (and to Sam for pointing me to the release tools change that removed them from the snapshots).
Thank you for reporting the issue.
participants (5)
-
Andrey Semashev -
Jonathan Wakely -
René Ferdinand Rivera Morell -
Ruben Perez -
Sam Darwin