Read this: Maintenance Fork

[achrinza]

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?

1. Currently, the latest published versions of v9, v10, and v11 still contain 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).
2. 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:

1. Provide clean versions of the upstream package.
2. Follow upstream as closely as possible
3. Publish dependency version bumps
4. Run tests against new versions of Node.js and fix any issues
5. Act as a drop-in replacement for node-ipc

Addition of new features is out-of-scope.

FAQ

This FAQ is split into 2 sections:

1. Governance FAQ: Queries with how this package is maintained.
2. Technical FAQ: Queries with how to use this package.

Governance FAQ

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/v12?

node-ipc v11.0.0, v11.1.0 anv v12.0.0 are functionally identical to v10.1.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.

The difference between v12.0.0 and v10.1.0 can be found in RIAEvangelist/node-ipc@a98efae.

The commits showing changes between v11.x and v10.1.0 were deleted by the original maintainer and are no longer available.

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.

• v9: 84dce1b...v9
• v10/11: f23a409...main

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	v9 v10 v11 (via v10)	v9 (via @node-ipc/compat) v10 (via v11) v11
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.

Technical FAQ

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 overrides key will only be considered when it is in the root
package.json file for a project. overrides in installed dependencies
(including workspaces) will not be considered in dependency tree
resolution. Thus, there is no cascading overrides between multiple
different package.json files at any given time.

Published packages may dictate their resolutions by pinning dependencies or
using an npm-shrinkwrap.json file.

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-ipc

It's also possible to use package aliases to rename the DefinitelyTyped package to @types/achrinza__node-ipc.

[AaronDewes]

@achrinza Would you be interested in collaborating on this at @node-ipc? I'm happy to give you access both there and on the npm org.

But I'm also planning to add new changes & improvements over upstream, like porting it to promises instead of callback functions, in a separate branch (probably as a separate package).

I already published v11 on @node-ipc/node-ipc and v9 on @node-ipc/compat and forked some dependencies.

[achrinza]

Hi @AaronDewes,

Would you be interested in collaborating on this at https://github.com/node-ipc?

Sure thing; I'm open to working on @node-ipc

But I'm also planning to add new changes & improvements over upstream, like porting it to promises instead of callback functions, in a separate branch (probably as a separate package).

Sounds great!

[AaronDewes]

I've just invited you to both the GitHub and npm org, please let me know if you got access to both.

[achrinza]

Yup, managed to accept both invitations

[AaronDewes]

@achrinza Not sure if you'd count it as new feature, but adding a .d.ts file to this repo would be great, because @types/node-ipc won't work with this repo.

[achrinza]

@AaronDewes There's a workaround by using the NPM CLI package aliases feature that I recently added above:

Q: I want to import using the original package name

NPM CLI v6.9.0 and Yarn v0.24.3 support package aliases, 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.

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-ipc

The rationale is that the DefinitelyTyped typedef may not be stable since they map to the same semver major (e.g. @types/node-ipc@10 is for node-ipc@10), which means breaking changes is allowed within semver major. This means that keeping up-to-date with the upstream typedef may be difficult.

By using this workaround, we would keep the familiar DefinitelyTyped contract in place.

It's a different approach to the same problem.

[AaronDewes]

Some feedback regarding your info about @node-ipc/node-ipc

Bundled snapshot of DefinitelyTyped

Actually, it's written in/ported to TypeScript, so the Type definitions are not a snapshot of DefinitelyTyped.

For the versions, v10 is not published to the npm registry, so please replace it with this:

v9 (via @node-ipc/compat), v10 (via v11), v11.

[achrinza]

Thanks, I've made the changes.

[lukas-mertens]

"dependencies": {
  "node-ipc": "npm@achrinza/node-ipc@9"
}

should be

"dependencies": {
  "node-ipc": "npm:@achrinza/node-ipc@9"
}

[achrinza]

@lukas-mertens Thanks for catching that! I've updated all the package aliases in the FAQ.

[maa105]

Yup, managed to accept both invitations

is this still valid? cause I see you are now working on the original repo no?

[achrinza]

Hi @maa105, I've not contirbuted and do have push rights to the original repo, nor do I have any push nor publish rights for the original package on NPM registry.

Between @achrinza/node-ipc and @node-ipc/node-ipc, I support both projects. Both projects don't really require much upkeep from me, hence most changes I make to them (if any) is just for maintenance. Though @node-ipc/node-ipc is ultimately @/AaronDewes' project, so any major updates should be from, or approved by him.

See "Q: How does this differ from @node-ipc/node-ipc?" above for more info on why the forks are managed separately.