support insecure-algorithms manifest permissions flag

[phillipivan]

Combines with this PR for companion-module-base to address this issue.

//@ts-expect-error can be removed once PR for companion-module-base is merged and released

Summary by CodeRabbit

• Bug Fixes

  • Apply legacy OpenSSL provider when requested in manifest permissions for compatibility with packages requiring insecure algorithms.
  • Improve permission determination for modules with unsupported API versions to avoid incorrect permission exposure.

• New Features

  • More granular filesystem read/write allowances for native addons, packaged modules, and certain network paths to prevent permission failures.
  • Automatically allow reading the host package when present to support dev-version integrations.

[coderabbitai]

📝 Walkthrough

Walkthrough

Builds Node.js permission arguments incrementally, extracts manifestPermissions earlier, conditionally applies --openssl-legacy-provider for insecure algorithms, short-circuits surface/node18 paths, adds host package read permission, and introduces Windows/network forceReadWriteAll logic to broaden final fs read/write allowances.

Changes

Cohort / File(s)

Summary

Node permission and manifest handling companion/lib/Instance/NodePath.ts

Switches from returning pre-built arrays to incrementally pushing permission args; extracts manifestPermissions earlier; conditionally emits --openssl-legacy-provider when manifest.runtime.permissions.insecure-algorithms is truthy; short-circuits surface and node18 flows; adds host package read permission for non-packaged runs; adds forceReadWriteAll for Windows/network paths and expands final --allow-fs-read / --allow-fs-write pushes for native addons/filesystem/forceReadWriteAll cases.

Poem

🛠️ Flags assemble, step by step,
Manifests checked, no misstep,
Legacy cipher gently called,
Host paths welcomed, permissions tallied,
Network quirks met with a careful sweep —
Ships set sail, the guards now keep.

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'support insecure-algorithms manifest permissions flag' directly and clearly describes the main feature being added, aligning well with the PR's core objective.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Julusian]

your addition probably wants to be above this enableInspect check, so that it applies when that is enabled.

Probably needs this line split up a bit to allow different routes.

[phillipivan]

This should be addressed now, Julian.

[coderabbitai]

🧹 Nitpick comments (1)

companion/lib/Instance/NodePath.ts (1)

43-46: Optional: doesModuleSupportPermissionsModel semantically gates an unrelated flag.

--openssl-legacy-provider is an OpenSSL crypto flag, independent of the Node.js permission model. Right now it can only be reached because insecure-algorithms is new enough (companion-module-base ≥ 1.15.0 > 1.12.0) that any module setting it will always pass the doesModuleSupportPermissionsModel check — so there's no practical bug today.

That said, if you ever want to make the intent clear and guard against future drift, you could hoist the OpenSSL push above the permissions-model gate:

✨ Optional refactor to decouple OpenSSL from the permissions model gate

 const args: string[] = []
 if (manifest.type === 'surface') return args
-if (!doesModuleSupportPermissionsModel(moduleApiVersion)) return args
 const manifestPermissions = manifest.runtime.permissions || {}
 //@ts-expect-error until companion-module-base 1.15.0 released and included
 if (manifestPermissions['insecure-algorithms']) args.push('--openssl-legacy-provider')
+if (!doesModuleSupportPermissionsModel(moduleApiVersion)) return args

Totally fine to leave as-is for now — just something to keep in mind if the module-base version coupling ever changes.

[coderabbitai]

🧹 Nitpick comments (2)

companion/lib/Instance/NodePath.ts (2)

46-52: The insecure-algorithms handling looks good! Small thought on the @ts-expect-error.

The placement of --openssl-legacy-provider before the --permission block is correct, and it's nice that node18 and inspect early-returns still carry this flag through.

One small thought: the @ts-expect-error comment mentions "until companion-module-base 1.15.0 released and included" — might be worth adding a tracking issue link or TODO tag so it's easy to find and clean up later. Totally up to you though!

---

63-67: Heads up: the ../../.. traversal from the resolved path could be fragile.

The number of parent directory hops depends on where require.resolve('@companion-module/host') lands (e.g., dist/index.js vs index.js). If the package's entry point depth changes, this could resolve to an unexpectedly broad or narrow directory.

Since this is dev-only, it's not critical — just something to keep in mind. You could consider resolving the package.json of @companion-module/host directly (e.g., via require.resolve('@companion-module/host/package.json')) and then using path.dirname() once for a more stable reference. No pressure though — totally a "nice to have"!