Drop-in fork of `node-ipc`.
License: MIT License
I'm Rifa. You can find a general self-introduction in https://www.achrinza.com.
Here on GitHub, I maintain a handful of open-source projects. Some examples include:
node-ipc forkI also enjoy contributing to other FOSS projects as well!
It seems Node.js v19 is not yet supported?
yarn install v1.22.19
[1/4] Resolving packages...
[2/4] Fetching packages...
error @achrinza/[email protected]: The engine "node" is incompatible with this module. Expected version "8 || 9 || 10 || 11 || 12 || 13 || 14 || 15 || 16 || 17 || 18". Got "19.0.0"
error Found incompatible module.@achrinza/node-ipc
@achrinza/node-ipc@10 (dependencies: @achrinza/event-pubsub@5, @node-ipc/js-queue@2)@achrinza/[email protected] (dependencies: nil)@achrinza/strong-type
@achrinza/[email protected] (dependencies: @node-ipc/vanilla-test@1)@achrinza/[email protected] (dependencies: @node-ipc/vanilla-test@1 (cyclic))@achrinza/event-pubsub
@achrinza/[email protected] (dependencies: @achrinza/strong-type@0, @node-ipc/vanilla-test@1)@node-ipc/vanilla-test
@node-ipc/[email protected] (dependencies: @achrinza/strong-type@1 (cyclic))v9.2.0, v9.2.1, v10.1.2Subscribe to this issue to receive critical updates on this advisory.
Applies to:
@achrinza/node-ipc@^9@achrinza/node-ipc@^10Deprecated:
@achrinza/[email protected]@achrinza/[email protected]@achrinza/[email protected]Replacement:
@achrinza/[email protected]@achrinza/[email protected]Out of an abundance of caution, v9.2.0, v9.2.1, v10.1.2 have been deprecated in favor of v9.2.2 and v10.1.3 as they contained nested transitive production dependencies that are managed by @/riaevangelist (The original author of node-ipc).
The offending transitive development dependencies are:
@achrinza/[email protected]/v9.2.1/v10.1.2
[email protected]
2.0.2
easy-stack@^1.0.1
1.0.1v9.2.2 and v10.1.3 resolve this issue by switching js-queue to @node-ipc/js-queue, which depends on a pinned version of easy-stack. There are no functional code changes in v9.2.2 and v10.1.3.
At the time of writing, we have no reason to believe that any of these dependencies had any malicious code. However, this may change in the future and we strongly recommend upgrading the v9 and v10 version range to ^9.2.2 and ^10.1.3 respectively.
Can we get this working for Node 20.10.0
See this error trying to install latest release of Angular.
error @achrinza/[email protected]: The engine "node" is incompatible with this module. Expected version "8 || 9 || 10 || 11 || 12 || 13 || 14 || 15 || 16 || 17 || 18". Got "20.10.0"
error Found incompatible module.When using version 9 and calling serve with just a callback to use the default path, I get the following error:
/home/tyilo/tmp/node-ipc-test/node_modules/@achrinza/node-ipc/services/IPC.js:111
this.log(
^
TypeError: Cannot read properties of undefined (reading 'log')
at serve (/home/tyilo/tmp/node-ipc-test/node_modules/@achrinza/node-ipc/services/IPC.js:111:14)
at Object.<anonymous> (/home/tyilo/tmp/node-ipc-test/index.js:4:1)
at Module._compile (node:internal/modules/cjs/loader:1246:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1300:10)
at Module.load (node:internal/modules/cjs/loader:1103:32)
at Module._load (node:internal/modules/cjs/loader:942:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:83:12)
at node:internal/main/run_main_module:23:47
Node.js v19.6.0
Steps to reproduce:
$ mkdir node-ipc-test
$ cd node-ipc-test
$ npm init
...
$ npm add @achrinza/node-ipc@9
$ cat > index.js
const ipc = require("@achrinza/node-ipc");
const {serve} = ipc;
serve(() => {
console.log("Serving");
});
^D
$ node index.js
/home/tyilo/tmp/node-ipc-test/node_modules/@achrinza/node-ipc/services/IPC.js:111
this.log(
^
TypeError: Cannot read properties of undefined (reading 'log')
at serve (/home/tyilo/tmp/node-ipc-test/node_modules/@achrinza/node-ipc/services/IPC.js:111:14)
at Object.<anonymous> (/home/tyilo/tmp/node-ipc-test/index.js:4:1)
at Module._compile (node:internal/modules/cjs/loader:1246:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1300:10)
at Module.load (node:internal/modules/cjs/loader:1103:32)
at Module._load (node:internal/modules/cjs/loader:942:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:83:12)
at node:internal/main/run_main_module:23:47
Node.js v19.6.0
Advisories convey critical information relating to the @achrinza/node-ipc that may require manual action from users.
This issue is to track all advisories, Subscribe to this issue to receive critical updates on @achrinza/node-ipc. Updates to existing advisories will only be posted in the advisory itself.
Sorted latest to oldest
Hi!
When installing the v9 branch of this package (currently version 9.2.4) on Node.js >= 18 with yarn I get the following error:
error @achrinza/[email protected]: The engine "node" is incompatible with this module. Expected version "8 || 9 || 10 || 11 || 12 || 13 || 14 || 15 || 16 || 17 | 18". Got "18.1.0"
error Found incompatible module.
I think that is because of a typo in the package.json where it needs to be || instead of |:
Line 10 in 07c72fd
v10.1.5, v10.1.6, v10.1.7, v10.1.8, v10.1.9Subscribe to this issue to receive critical updates on this advisory.
Applies to:
@achrinza/node-ipc@^10Deprecated:
@achrinza/[email protected]@achrinza/[email protected]@achrinza/[email protected]@achrinza/[email protected]@achrinza/[email protected]Replacement:
@achrinza/[email protected]Out of an abundance of caution, v10.1.5, v10.1.6, v10.1.7, v10.1.8, v10.1.9 have been deprecated in favor of v10.1.10 as they contained nested transient production dependencies that are managed by @/riaevangelist (The original author of node-ipc).
The offending transient development dependencies are:
@achrinza/[email protected]/10.1.6/10.1.7/10.1.8/10.1.9
[email protected]
1.1.8
vanilla-test@*v10.1.10 resolves this issue by replacing [email protected] with @achrinza/strong-type, which depends on pinned versions of @node-ipc/vanilla-test. There are no functional code changes in v10.1.10.
At the time of writing, we have no reason to believe that any of these dependencies had any malicious code. However, this may change in the future and we strongly recommend upgrading the v10 version range to ^10.1.10.
v10.1.4Subscribe to this issue to receive critical updates on this advisory.
Applies to:
@achrinza/node-ipc@^10Deprecated:
@achrinza/[email protected]Replacement:
@achrinza/[email protected]Out of an abundance of caution, v10.1.4 have been deprecated in favor of v10.1.5 as they contained nested transient production dependencies that are managed by @/riaevangelist (The original author of node-ipc).
The offending transient development dependencies are:
@achrinza/[email protected]@achrinza/[email protected]
[email protected]
0.1.5
vanilla-test@*v10.1.5 resolves this issue by upgrading to @achrinza/[email protected], which depends on pinned versions of @node-ipc/vanilla-test. There are no functional code changes in v10.1.5.
At the time of writing, we have no reason to believe that any of these dependencies had any malicious code. However, this may change in the future and we strongly recommend upgrading the v10 version range to ^10.1.5.
This is an interim checklist of common security-related things that should be resolved:
lockfile-lint)
package.json)
npm pack and minimal test app)
riaevangelist has publishing rights
--ignore-scripts (with CI testing)
pkg:npm/licensee)
tried npm update, install, yarn upgrade and install with no luck
when i run vue add electron-builder, the error show me do not support the version 18 of node
This Git Repository houses the codebase for @achrinza/node-ipc, which is meant to be a maintenance fork of the node-ipc project. This was done in response to the original package maintainer publishing malicious versions of the package to NPM.
Why create a fork?
peacenotwar package that, although not destructive, may not be preferable (It's also GPL 3.0, which is incompatible with node-ipc's MIT license).node-ipc has nested transient dependencies on other packages controlled by the maintainer. Malicious versions of these packages can be published in the future. Pinning node-ipc is not suffice to protect against this attack vector.Hence, this fork is intended to:
node-ipcAddition of new features is out-of-scope.
This FAQ is split into 2 sections:
Q: Who maintains this fork?
Rifa Achrinza is an existing member of the Technical Steering Committee for LoopBack, which is a FOSS project under the OpenJS Foundation alongside other projects such as ESlint and Node.js. For avoidance of doubt, this is not an OpenJS Foundation Project.
Q: Which versions are being published?
v9 (v9 Git Branch) and v10 (main Git Branch).
Q: Where's v11?
node-ipc v11.0.0 and v11.1.0 are functionally identical to v10.2.0 (of which is the latest v10 release at time of writing). Hence, you may install @achrinza/node-ipc@10 as a drop-in replacement of v11.
Q: Where's <v9?
There are no plans to maintain any version older than v9.
Q: What changes were made?
One of the principles of this fork is to modify the original code as little as possible. This eases review of the changes and deviations from upstream. As a drop-in fork, no functional changes are made.
Q: Will new features be accepted?
No. We intend to keep this strictly as a maintenance fork to fulfill the need of a drop-in replacement that's managed by someone else.
Q: Will bug fixes be accepted?
Please try to submit the bug fix to the upstream project (node-ipc) first. Since this fork intends to follow upstream closely, we are able to apply upstream patches when they are released. If it's not possible, we may consider accepting the bug fix on a case-by-case basis.
Q: What is a "maintenance fork"?
A maintenance fork is only maintained for upkeep, and not for the addition of new features.
Q: Will there be a non-maintenance fork?
There currently are no plans to maintain a "non-maintenance fork" under this Node.js package. This is to ensure that we can fulfill the mission of being a drop-in replacement.
For a non-maintenance fork, see @node-ipc/node-ipc instead.
Q: How is this package's security ensured?
See #4 for the security checklist.
See #15 for a list of advisories.
Q: Why are there so many deprecations?
At the time of writing (25 March 2022), all deprecation were due to transient dependencies maintained by @/riaevangelist. Unfortunately, we currently do not have the tools necessary to programmatically find all of these. This issue is being tracked in #24.
Q: How is provenance/pedigree/SBOM provided?
For weak provenance: The NPM public registry exposes a gitHead property, which can be retrieved with npm view <package spec> gitHead. This can be used to map the release to the original Git Commit on this Git Repository. Note that this field does not have strong integrity protections. Nonetheless, it is a good starting point for comparisons.
For strong provenance: Follow the command sequence below:
VERSION=10.1.4 # Replace this version accordingly
git clone https://github.com/achrinza/node-ipc.git
cd node-ipc
git checkout "refs/tags/v$VERSION"
npm ci
npm diff --diff="@achrinza/$VERSION" --diff=.If the output is a blank line, there are no differences. If they differ, use the gitHead from above as a starting point for identifying the correct Git Commit Hash. Usually, this discrepency is caused by creation of the version bump Git Commit after npm publish. Hence, the correct Git Commit is typically the previous one (i.e. git checkout refs/tags/v10.1.0^)
For pedigree: Pedigree is not provided at the moment. We're working to generate SLSA and CycloneDX documents for pedigree.
For SBOM: @achrinza/node-ipc is used as a library / dependency of other projects. This means that the dependency tree of the same @achrinza/node-ipc version can vary between installations due to transient depenencies. This is a difficult issue to solve as we would need to account for every permutation of the dependency tree. This is being tracked in loopbackio/security#19. It's better that each dependent project use a frozen lockfile in production and leverage that lockfile to provide insights into their specific dependency tree.
Q: How does this differ from @node-ipc/node-ipc?
Ultimately, both projects have different end-goals and it is up to each project to evaluate their suitability.
Here's a quick summary:
@achrinza/node-ipc |
@node-ipc/node-ipc |
|
|---|---|---|
| Fork type | Maintenance | Maintenance + new features |
| Fork scope | node-ipc, strong-type, event-pubsub |
node-ipc, event-pubsub, js-queue, vanilla-test |
node-ipc published versions |
|
|
node-ipc tested Node.js versions |
v9: 8,9,10,11,12,13,14,15,16,17,18,19,20,21,22 v10: 14,16,17,18,19,20,21,22 |
v9: ? v11: 14,16,17 |
node-ipc TypeScript typedefs |
DefinitelyTyped (See "Q: I want to use the DefinitelyTyped type definitions") | Rewritten in TypeScript |
| No transient dependencies by @/riaevangelist | v9: since v9.2.2 v10: since v10.1.5 |
v9: since v9.2.5 v11: since v11.0.3 |
| Champion | @achrinza | @AaronDewes |
| Maintainers | @achrinza | @achrinza + others |
| Signed Git Tags | Yes | No |
| Security program | #TODO: See OpenSSF Guide | ? |
| OpenSSF Best Practices | #TODO | ? |
| Open Source Criticality Score | #TODO | ? |
| License compliance | #TODO | ? |
| Dependency version bumps | #TODO | ? |
Where applicable, @achrinza/node-ipc leverages @node-ipc packages for direct dependencies instead of maintaining its own fork. Under certain circumstances (such as where the @node-ipc package does not exist or has been extensively re-written), a separate @achrinza fork is leveraged instead.
Q: I have a deep/nested dependency which depends on node-ipc. How can I point it to this fork?
NPM CLI v8.3.0 onwards support overrides, which was designed for a similar purpose.
In package.json, add the following:
"overrides": {
"node-ipc@11": "npm:@achrinza/node-ipc@10",
"node-ipc@10": "npm:@achrinza/node-ipc@10",
"node-ipc@9": "npm:@achrinza/node-ipc@9"
}Note that if you have a direct dependency on node-ipc, you must explicitly switch over to @achrinza/node-ipc to avoid spec conflicts.
overrides are only honored in the root package. This means that overrides cannot be used by a library maintainer to alter their package users' dependency tree. From https://github.com/npm/rfcs/blob/main/accepted/0036-overrides.md:
The
overrideskey will only be considered when it is in the root
package.jsonfile for a project.overridesin installed dependencies
(including workspaces) will not be considered in dependency tree
resolution. Thus, there is no cascading overrides between multiple
differentpackage.jsonfiles at any given time.Published packages may dictate their resolutions by pinning dependencies or
using annpm-shrinkwrap.jsonfile.
Q: I want to import using the original package name
NPM CLI v6.9.0 and Yarn v0.24.3 onwards support package aliases RFC, which allows transparent re-mapping of package names. In package.json:
"dependencies": {
"node-ipc": "npm:@achrinza/node-ipc@9"
}Replace the trailing 9 with the appropriate @achrinza/node-ipc version accordingly.
See the above linked RFC for more complex package alias rules that may better cater to your needs.
Q: I want to use the DefinitelyTyped type definitions
Follow the steps in "Q: I want to import using the original package name" above and install the type definitions:
npm install --save-dev @types/node-ipcIt's also possible to use package aliases to rename the DefinitelyTyped package to @types/achrinza__node-ipc.
When calling emit right before disconnect the emit will not be sent to the server making it unpredictable behaviour.
E.g. following code:
import ipc from "node-ipc";
ipc.config.id = "foo";
ipc.serve(() => {
ipc.config.id = "bar";
ipc.connectTo("foo", () => {
ipc.of["foo"].emit("test", "test");
ipc.disconnect("foo");
})
})
ipc.server.on("test", console.log);
ipc.server.start();will never log. In the debug output it shows
This behaviour is required because I want one of the possible execution paths to send a single message to the server and then close the application (other paths would use the socket as a long time connection)
Line 10 in 2883c46
This change broke builds requiring @vue/cli-shared-utils and non-lts versions of node.js
I have a pipeline requireing node 15.x for package compatibility reasons but changing the supported versions of node.js from >=8.0.0 to 8 || 10 || 12 || 14 || 16 || 17 causes the following error:
error @achrinza/[email protected]: The engine "node" is incompatible with this module. Expected version "8 || 10 || 12 || 14 || 16 || 17". Got "15.6.0"
error Found incompatible module.
I'm curious as to why was this change made, and can it be reverted?
Thanks.
v10.1.0 and v10.1.1Subscribe to this issue to receive critical updates on this advisory.
Applies to:
@achrinza/node-ipc@^10Deprecated:
@achrinza/[email protected]@achrinza/[email protected]Replacement:
@achrinza/[email protected]Out of an abundance of caution, v10.1.0 and v10.1.1 have been deprecated in favor of v10.1.2 as they contained nested transitive development dependencies that are managed by @/riaevangelist (The original author of node-ipc).
The offending transitive development dependencies are:
node-cmd@^4.0.0vanilla-test@^1.4.8
1.4.8
ansi-colors-es6@^5.0.0strong-type@^1.0.1
1.0.1
vanilla-test@*1.1.0
vanilla-test@*1.4.9
ansi-colors-es6@^5.0.0strong-type@^1.1.0
1.1.0
vanilla-test@*v10.1.2 resolves this issue by pinning to [email protected] and switching vanilla-test to @node-ipc/vanilla-test. There are no code changes in v10.1.2.
At the time of writing, we have no reason to believe that any of these dependencies had any malicious code. However, this may change in the future and we strongly recommend upgrading the v10 version range to ^10.1.2.
v10.1.3Subscribe to this issue to receive critical updates on this advisory.
Applies to:
@achrinza/node-ipc@^10Deprecated:
@achrinza/[email protected]Replacement:
@achrinza/[email protected]Out of an abundance of caution, v10.1.3 have been deprecated in favor of v10.1.4 as they contained nested transient production dependencies that are managed by @/riaevangelist (The original author of node-ipc).
The offending transient development dependencies are:
@achrinza/[email protected]
[email protected]
5.0.3
strong-type@^0.1.3
0.1.3
node-http-server@^8.1.30.1.4
node-http-server@^8.1.3vanilla-test@^1.4.20.1.5
node-http-server@*vanilla-test@*0.1.6
node-http-server@*vanilla-test@*strong-type@^1.0.11.0.1v10.1.4 resolves this issue by switching event-pubsub to @achrinza/event-pubsub, which depends on pinned versions of node-http-server and vanilla-test, and pins the version of strong-type. There are no functional code changes in v9.2.2 and v10.1.3.
At the time of writing, we have no reason to believe that any of these dependencies had any malicious code. However, this may change in the future and we strongly recommend upgrading the v10 version range to ^10.1.4.
The macOS and Windows tests are flaky. Specifically, this test:
1) TCP Socket verification of client Verify retry attempts by TCP client to connect to the server as per the value set in "maxRetries" parameter.
Message:
Expected 2 to be 3.
Stack:
Error: Expected 2 to be 3.
at Timeout.testDelay [as _onTimeout] (/Users/runner/work/node-ipc/node-ipc/spec/support/jasmineTest/TCP/tcpSocketClient.spec.js:48:44)
at ontimeout (timers.js:436:11)
at tryOnTimeout (timers.js:300:5)
npm ERR! Test failed. See above for more details.
at listOnTimeout (timers.js:263:5)
11 specs, 1 failure
Example run: https://github.com/achrinza/node-ipc/runs/5631442749?check_suite_focus=true
This issue is track for a potential solution to improving the tests.
NPM is working on getting access to the original modules back after the account was hacked in march. I would like to review and merge your modifications when that happens as well as put you on as the lead maintainer. Once NPM and I get things sorted perhaps we could set up a video meeting to discuss?
It seems Node.js v20 is not yet supported?
yarn install v1.22.19
[1/4] Resolving packages...
[2/4] Fetching packages...
error @achrinza/[email protected]: The engine "node" is incompatible with this module. Expected version "8 || 9 || 10 || 11 || 12 || 13 || 14 || 15 || 16 || 17 || 18 || 19". Got "20.0.0"
error Found incompatible module.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.please support node: 'v20.4.0', npm: '9.7.2'
thanks
At the time of writing, all deprecation of @achrinza/node-ipc were due to transient dependencies managed by @/riaevangelist. This is due to the difficulty of checking each dependency manually for their maintainers.
This issue is to track finding/creating a solution which can scan the dependency tree, retrieve their maintainers from the registry, and compare it to a blocklist.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.