Research and update dependencies

[plocket]

[It seems the newest version of da uses npm v23, which seems to not run pdfjs at all without an update to pdfjs (or at least I can't get it to). The da docs don't say when that happened, so I'm not sure how imminent the necessity is since folks haven't brought it up, but we might as well keep ahead of it.]

Anyone approaching this can use npm audit to see the current state of affairs. Research so far:

node v22

[Conclusion
Move to node v22, but build in a way for ALKiln to warn ALKilnInThePlayground users that they need to get a new version of ALKilnInThePlayground (ALKiP) in order to keep running the latest versions of ALKiln.

Docassemble os switched to node v22 in 2024/03: https://github.com/search?q=repo%3Ajhpyle%2Fdocassemble-os+node&type=commits. The current authors we're aware of have, I believe, updated their docassemble image since then. I believe their ALKilnInThePlayground tests work with the current version of our tests because ALKilnInThePlayground builds its own node environment in /var/www/.npm-global.

Important

Does this constitute a breaking change in ALKilnInThePlayground? This update doesn't require authors to update their code, just their version of ALKilnInThePlayground. On the other hand, without that update, if they update ALKiln's version their tests will error.

]

Discussion

What version of node does a docassemble container currently use? When did that transition happen? That is, how sure are we that our authors are using v22? If not, we probably can't update to 22.

If our authors can indeed update, though, it might also be a good idea to force our internal developers to use node v22 (from stackoverflow):

You can set the engines field in your package.json and set requirements for either node or npm versions or both:

  "engines" : { 
    "npm" : ">=8.0.0 <9.0.0",
    "node" : ">=16.0.0 <17.0.0"
  }

To enforce this via npm you need to create an .npmrc file (and commit it to the repository) and set the engine-strict option to true, which will cause npm commands such as npm install to fail if the required engine versions to not match:

# .npmrc
engine-strict=true

Without that file, every developer will need to run npm config set engine-strict true in their local workspace to switch on this option.

- [x] pdfjs v5 (depending on node)

Summary

Supposedly high, but unlikely to be any actual security issue for our specific use case. [On the other hand, the current version keeps breaking our code as the node version increases. The suggestion below may work in old versions of node and pdfjs-dist too, so we might as well give it a shot.]

PDF.js vulnerable to arbitrary JavaScript execution upon opening a malicious PDF - GHSA-wgrm-67xf-hhpq

Our users have control of their PDFs.

(Some of this information also in #957)

Research:

Be careful not to update this until we've fully figured out if we can use it. I'm not sure if old versions are available through npm.

If we can update to node >22 we might be able to skip straight to pdfjs v5 to avoid the bug we were unable to overcome. I'm not sure. We have to see if we can get off the legacy build or, alternatively, if there's a way to use the legacy build instead (ideally without typescript).

For the legacy build with node >= v22, we might be able to use Promise.withResolvers to get around import() (lack of support for Common JS).

With node < v22, this might be an option if we can use an async function (though I actually don't know the current filepath and am concerned pdfjs-dist might not have a v5):

async function importPdfLib() {
  const pdfjsLib = await import("pdfjs-dist/nonexistant/legacy/build/pdf.mjs");
  return pdfjsLib;
}

// Or, a bit more ugly
async function importPdfLib(name) {
  const module = eval(`(async () => {return await import("pdfjs-dist/nonexistant/legacy/build/pdf.mjs")})()`);
  return module;
}

async function getPdf(params) {
  const { getDocument } = await importPdfLib();
  return getDocument(params);
}

You can see something like the pretty version here. You can see something like the ugly version here. I've tried to adjust to remove typescript for the moment.

Like I said, I'm not sure where the actual filepath is. I was only able to find a reference to pdfjs-dist in the code here and in the FAQ here. The info from the FAQ implies it's only available by CDN, even though we continue to get it from npm as pdfjs-dist <=4.1.392. (Which is why I suspect there are no more new versions of pdfjs-dist.)

As far as the pdfjs changes go, I've checked the [api-minor] and [api-major] change and the only possible issue I can see is that they don't support older versions of Chrome. I'm not sure we need to do anything about that, but it might be worth looking into. Or just testing first.

- [x] tar-fs

Summary

Supposedly high, but again, the current problem with it probably not relevant to us, but still worth looking into.

Vulnerable to Link Following and Path Traversal via Extracting a Crafted tar File - GHSA-pq67-2wwv-3xjx

I think our users don't use arbitrary tar files.

Research:

Haven't seen conflicts

- [x] axios

Summary

Supposedly high, but again, probably not crucial in our case.

Server-Side Request Forgery in axios - GHSA-8hc4-vh64-cxmj
axios Requests Vulnerable To Possible SSRF and Credential Leakage via Absolute URL - GHSA-jr5f-v2jv-69x6

ALKiln is the only one making axios requests.

Research:

Haven't seen conflicts

- [x] @babel/runtime

Summary

moderate
Babel has inefficient RegExp complexity in generated code with .replace when transpiling named capturing groups - GHSA-968p-4wvh-cqc8

Research:

Haven't seen conflicts

- [x] micromatch

Summary

moderate
Regular Expression Denial of Service (ReDoS) in micromatch - GHSA-952p-6rrq-rcjv

Research:

Haven't seen conflicts

- [x] nanoid

Summary

moderate
Predictable results in nanoid generation when given non-integer values - GHSA-mwcw-c2x4-8c55

Research:

Haven't seen conflicts

- [x] serialize-javascript 6.0.0 - 6.0.1

Summary

moderate
Cross-site Scripting (XSS) in serialize-javascript - GHSA-76p7-773f-r4q5
fix available via npm audit fix --force

Research:

Haven't seen conflicts

---

Non-vulnerability updates

---

---

Avoid upadtes

---

- [ ] @cucumber/cucumber 9.3.0 to TBD

No vulnerabilities.

AVOIDING UPDATE. Potential conflict - v10 drops support for node v19 and below. I'm not sure if this would impact our build, but I'd prefer to wait till we think more docassemble servers are past node v19

- [ ] @axe-core/puppeteer 4.7.3 to TBD

No vulnerabilities.

AVOIDING UPDATE. We need to do this when we have time to deal with the possibility of new failing accessibility tests.

---

- [x] @faker-js/faker 7.3.0 to v9.8.0

Only supports node >18.

There are API changes. We'll run and see what breaks

Of possible interest:

• test: introduce seededTests factory
• Faker might be able to do images. Not sure if you have to provide your own files.

- [ ] chai 4.2.0 to TBD

- [ ] cheerio 1.0.0-rc.10 to TBD

- [ ] deep-equal-in-any-order 2.0.0 to TBD

- [ ] diff 5.0.0 to TBD

- [ ] dotenv 8.2.0 to TBD

- [ ] fast-glob 3.2.12 to TBD

- [ ] minimatch 3.0.5 to TBD

- [ ] minimist 1.2.8 to TBD

- [ ] puppeteer 22.15.0 to TBD

- [ ] qs 6.10.3 to TBD

- [ ] sanitize-filename 1.6.3 to TBD

- [ ] uuid 8.3.2 to TBD

[ST-DDT]

As for upgrading faker-js to latest: IMO it is easy, though it might be a bit tedious to update depending on how many calls to faker there are.
Most of the changes can be covered by string.replace and since there is usually a shared prefix such as faker. or faker.person. you are unlikely to hit many issues.

Of possible interest:

• test: introduce seededTests factory

The test factory is mostly conceptually relevant since it runs the same tests multiple times and compares the result with a snapshot (with the ability to easily run it with multiple parameter sets).

https://github.com/faker-js/faker/blob/549d71cf3361cca787d685a1c053ef8135e13641/test/modules/number.spec.ts#L29-L44
https://github.com/faker-js/faker/blob/549d71cf3361cca787d685a1c053ef8135e13641/test/modules/__snapshots__/number.spec.ts.snap#L25-L35

• Faker might be able to do images. Not sure if you have to provide your own files.

Faker hosts AI generated portraits, that you can use.

https://fakerjs.dev/api/image.html#personportrait

There are also some third party image services for general pictures, but they tend to change frequently.

[plocket]

We took care of the highest priority items, so I'm removing that label.