A nodejs module for local and remote Inter Process Communication with full support for Linux, Mac and Windows

Last update: Sep 28, 2022

Related tags

Overview

@achrinza/node-ipc

NOTE: This is a maintenance fork of node-ipc This is intended for packages that directly or indirectly depend on node-ipc where maintainers need a drop-in replacement.

See #1 for more details.

a nodejs module for local and remote Inter Process Communication with full support for Linux, Mac and Windows. It also supports all forms of socket communication from low level unix and windows sockets to UDP and secure TLS and TCP sockets.

A great solution for complex multiprocess Neural Networking in Node.JS

npm install @achrinza/node-ipc

for node

npm install @achrinza/node-ipc@9

including v10 or greater into your code

//es6
import ipc from "@achrinza/node-ipc";

//commonjs
const ipc = require("@achrinza/node-ipc").default;

Older versions of node

the latest versions of @achrinza/node-ipc may work with the --harmony flag. Officially though, we support node v4 and newer with es5 and es6

Testing

npm test will run the jasmine tests with istanbul for node-ipc and generate a coverage report in the spec folder.

You may want to install jasmine and istanbul globally with sudo npm install -g jasmine istanbul

Types of IPC Sockets and Supporting OS
IPC Config
IPC Methods
1. log
2. connectTo
3. connectToNet
4. disconnect
5. serve
6. serveNet
IPC Stores and Default Variables
IPC Events
Multiple IPC instances
Basic Examples
Working with TLS/SSL Socket Servers & Clients
Node Code Examples

Types of IPC Sockets

Type	Stability	Definition
Unix Socket or Windows Socket	Stable	Gives Linux, Mac, and Windows lightning fast communication and avoids the network card to reduce overhead and latency. Local Unix and Windows Socket examples
TCP Socket	Stable	Gives the most reliable communication across the network. Can be used for local IPC as well, but is slower than #1's Unix Socket Implementation because TCP sockets go through the network card while Unix Sockets and Windows Sockets do not. Local or remote network TCP Socket examples
TLS Socket	Stable	Configurable and secure network socket over SSL. Equivalent to https. TLS/SSL documentation
UDP Sockets	Stable	Gives the fastest network communication. UDP is less reliable but much faster than TCP. It is best used for streaming non critical data like sound, video, or multiplayer game data as it can drop packets depending on network connectivity and other factors. UDP can be used for local IPC as well, but is slower than #1's Unix Socket or Windows Socket Implementation because UDP sockets go through the network card while Unix and Windows Sockets do not. Local or remote network UDP Socket examples

OS	Supported Sockets
Linux	Unix, Posix, TCP, TLS, UDP
Mac	Unix, Posix, TCP, TLS, UDP
Win	Windows, TCP, TLS, UDP

IPC Config

ipc.config

Set these variables in the ipc.config scope to overwrite or set default values.

    {
        appspace        : 'app.',
        socketRoot      : '/tmp/',
        id              : os.hostname(),
        networkHost     : 'localhost', //should resolve to 127.0.0.1 or ::1 see the table below related to this
        networkPort     : 8000,
        readableAll     : false,
        writableAll     : false,
        encoding        : 'utf8',
        rawBuffer       : false,
        delimiter       : '\f',
        sync            : false,
        silent          : false,
        logInColor      : true,
        logDepth        : 5,
        logger          : console.log,
        maxConnections  : 100,
        retry           : 500,
        maxRetries      : false,
        stopRetrying    : false,
        unlink          : true,
        interfaces      : {
            localAddress: false,
            localPort   : false,
            family      : false,
            hints       : false,
            lookup      : false
        }
    }

variable	documentation
appspace	used for Unix Socket (Unix Domain Socket) namespacing. If not set specifically, the Unix Domain Socket will combine the socketRoot, appspace, and id to form the Unix Socket Path for creation or binding. This is available in case you have many apps running on your system, you may have several sockets with the same id, but if you change the appspace, you will still have app specic unique sockets.
socketRoot	the directory in which to create or bind to a Unix Socket
id	the id of this socket or service
networkHost	the local or remote host on which TCP, TLS or UDP Sockets should connect
networkPort	the default port on which TCP, TLS, or UDP sockets should connect
readableAll	makes the pipe readable for all users including windows services
writableAll	makes the pipe writable for all users including windows services
encoding	the default encoding for data sent on sockets. Mostly used if rawBuffer is set to true. Valid values are : `ascii` `utf8` `utf16le` `ucs2` `base64` `hex` .
rawBuffer	if true, data will be sent and received as a raw node `Buffer` NOT an `Object` as JSON. This is great for Binary or hex IPC, and communicating with other processes in languages like C and C++
delimiter	the delimiter at the end of each data packet.
sync	synchronous requests. Clients will not send new requests until the server answers.
silent	turn on/off logging default is false which means logging is on
logInColor	turn on/off util.inspect colors for ipc.log
logDepth	set the depth for util.inspect during ipc.log
logger	the function which receives the output from ipc.log; should take a single string argument
maxConnections	this is the max number of connections allowed to a socket. It is currently only being set on Unix Sockets. Other Socket types are using the system defaults.
retry	this is the time in milliseconds a client will wait before trying to reconnect to a server if the connection is lost. This does not effect UDP sockets since they do not have a client server relationship like Unix Sockets and TCP Sockets.
maxRetries	if set, it represents the maximum number of retries after each disconnect before giving up and completely killing a specific connection
stopRetrying	Defaults to false meaning clients will continue to retry to connect to servers indefinitely at the retry interval. If set to any number the client will stop retrying when that number is exceeded after each disconnect. If set to true in real time it will immediately stop trying to connect regardless of maxRetries. If set to 0, the client will *NOT* try to reconnect.
unlink	Defaults to true meaning that the module will take care of deleting the IPC socket prior to startup. If you use `node-ipc` in a clustered environment where there will be multiple listeners on the same socket, you must set this to `false` and then take care of deleting the socket in your own code.
interfaces	primarily used when specifying which interface a client should connect through. see the socket.connect documentation in the node.js api

IPC Methods

These methods are available in the IPC Scope.

log

ipc.log(a,b,c,d,e...);

ipc.log will accept any number of arguments and if ipc.config.silent is not set, it will concat them all with a single space ' ' between them and then log them to the console. This is fast because it prevents any concatenation from happening if the ipc.config.silent is set true. That way if you leave your logging in place it should have almost no effect on performance.

The log also uses util.inspect You can control if it should log in color, the log depth, and the destination via ipc.config

ipc.config.logInColor = true; //default
ipc.config.logDepth = 5; //default
ipc.config.logger = console.log.bind(console); // default

connectTo

ipc.connectTo(id,path,callback);

Used for connecting as a client to local Unix Sockets and Windows Sockets. This is the fastest way for processes on the same machine to communicate because it bypasses the network card which TCP and UDP must both use.

variable	required	definition
id	required	is the string id of the socket being connected to. The socket with this id is added to the ipc.of object when created.
path	optional	is the path of the Unix Domain Socket File, if the System is Windows, this will automatically be converted to an appropriate pipe with the same information as the Unix Domain Socket File. If not set this will default to `ipc.config.socketRoot`+`ipc.config.appspace`+`id`
callback	optional	this is the function to execute when the socket has been created.

examples arguments can be ommitted so long as they are still in order.

ipc.connectTo("world");

or using just an id and a callback

ipc.connectTo("world", function () {
  ipc.of.world.on("hello", function (data) {
    ipc.log(data.debug);
    //if data was a string, it would have the color set to the debug style applied to it
  });
});

or explicitly setting the path

ipc.connectTo("world", "myapp.world");

or explicitly setting the path with callback

    ipc.connectTo(
        'world',
        'myapp.world',
        function(){
            ...
        }
    );

connectToNet

ipc.connectToNet(id,host,port,callback)

Used to connect as a client to a TCP or TLS socket via the network card. This can be local or remote, if local, it is recommended that you use the Unix and Windows Socket Implementaion of connectTo instead as it is much faster since it avoids the network card altogether.

For TLS and SSL Sockets see the node-ipc TLS and SSL docs. They have a few additional requirements, and things to know about and so have their own doc.

variable	required	definition
id	required	is the string id of the socket being connected to. For TCP & TLS sockets, this id is added to the `ipc.of` object when the socket is created with a reference to the socket.
host	optional	is the host on which the TCP or TLS socket resides. This will default to `ipc.config.networkHost` if not specified.
port	optional	the port on which the TCP or TLS socket resides.
callback	optional	this is the function to execute when the socket has been created.

examples arguments can be ommitted so long as they are still in order.
So while the default is : (id,host,port,callback), the following examples will still work because they are still in order (id,port,callback) or (id,host,callback) or (id,port) etc.

ipc.connectToNet("world");

or using just an id and a callback

    ipc.connectToNet(
        'world',
        function(){
            ...
        }
    );

or explicitly setting the host and path

    ipc.connectToNet(
        'world',
        'myapp.com',serve(path,callback)
        3435
    );

or only explicitly setting port and callback

    ipc.connectToNet(
        'world',
        3435,
        function(){
            ...
        }
    );

disconnect

ipc.disconnect(id)

Used to disconnect a client from a Unix, Windows, TCP or TLS socket. The socket and its refrence will be removed from memory and the ipc.of scope. This can be local or remote. UDP clients do not maintain connections and so there are no Clients and this method has no value to them.

variable	required	definition
id	required	is the string id of the socket from which to disconnect.

examples

ipc.disconnect("world");

serve

ipc.serve(path,callback);

Used to create local Unix Socket Server or Windows Socket Server to which Clients can bind. The server can emit events to specific Client Sockets, or broadcast events to all known Client Sockets.

variable	required	definition
path	optional	This is the path of the Unix Domain Socket File, if the System is Windows, this will automatically be converted to an appropriate pipe with the same information as the Unix Domain Socket File. If not set this will default to `ipc.config.socketRoot`+`ipc.config.appspace`+`id`
callback	optional	This is a function to be called after the Server has started. This can also be done by binding an event to the start event like `ipc.server.on('start',function(){});`

examples arguments can be omitted so long as they are still in order.

ipc.serve();

or specifying callback

    ipc.serve(
        function(){...}
    );

or specify path

ipc.serve("/tmp/myapp.myservice");

or specifying everything

    ipc.serve(
        '/tmp/myapp.myservice',
        function(){...}
    );

serveNet

serveNet(host,port,UDPType,callback)

Used to create TCP, TLS or UDP Socket Server to which Clients can bind or other servers can send data to. The server can emit events to specific Client Sockets, or broadcast events to all known Client Sockets.

variable	required	definition
host	optional	If not specified this defaults to the first address in os.networkInterfaces(). For TCP, TLS & UDP servers this is most likely going to be 127.0.0.1 or ::1
port	optional	The port on which the TCP, UDP, or TLS Socket server will be bound, this defaults to 8000 if not specified
UDPType	optional	If set this will create the server as a UDP socket. 'udp4' or 'udp6' are valid values. This defaults to not being set. When using udp6 make sure to specify a valid IPv6 host, like `::1`
callback	optional	Function to be called when the server is created

examples arguments can be ommitted solong as they are still in order.

default tcp server

ipc.serveNet();

default udp server

ipc.serveNet("udp4");

or specifying TCP server with callback

    ipc.serveNet(
        function(){...}
    );

or specifying UDP server with callback

    ipc.serveNet(
        'udp4',
        function(){...}
    );

or specify port

ipc.serveNet(3435);

or specifying everything TCP

    ipc.serveNet(
        'MyMostAwesomeApp.com',
        3435,
        function(){...}
    );

or specifying everything UDP

    ipc.serveNet(
        'MyMostAwesomeApp.com',
        3435,
        'udp4',
        function(){...}
    );

IPC Stores and Default Variables

variable	definition
ipc.of	This is where socket connection refrences will be stored when connecting to them as a client via the `ipc.connectTo` or `iupc.connectToNet`. They will be stored based on the ID used to create them, eg : ipc.of.mySocket
ipc.server	This is a refrence to the server created by `ipc.serve` or `ipc.serveNet`

IPC Server Methods

method	definition
start	start serving need to call `serve` or `serveNet` first to set up the server
stop	close the server and stop serving

IPC Events

event name	params	definition
error	err obj	triggered when an error has occured
connect		triggered when socket connected
disconnect		triggered by client when socket has disconnected from server
socket.disconnected	socket destroyedSocketID	triggered by server when a client socket has disconnected
destroy		triggered when socket has been totally destroyed, no further auto retries will happen and all references are gone.
data	buffer	triggered when ipc.config.rawBuffer is true and a message is received.
*your event type*	*your event data*	triggered when a JSON message is received. The event name will be the type string from your message and the param will be the data object from your message eg : `{ type:'myEvent',data:{a:1}}`

Multiple IPC Instances

Sometimes you might need explicit and independent instances of node-ipc. Just for such scenarios we have exposed the core IPC class on the IPC singleton.

    import {IPCModule} from '@achrinza/node-ipc';

    const ipc=new RawIPC;
    const someOtherExplicitIPC=new RawIPC;


    //OR

    const ipc=from '@achrinza/node-ipc');
    const someOtherExplicitIPC=new ipc.IPC;


    //setting explicit configs

    //keep one silent and the other verbose
    ipc.config.silent=true;
    someOtherExplicitIPC.config.silent=true;

    //make one a raw binary and the other json based ipc
    ipc.config.rawBuffer=false;

    someOtherExplicitIPC.config.rawBuffer=true;
    someOtherExplicitIPC.config.encoding='hex';

Basic Examples

You can find Advanced Examples in the examples folder. In the examples you will find more complex demos including multi client examples.

Server for Unix Sockets, Windows Sockets & TCP Sockets

The server is the process keeping a socket for IPC open. Multiple sockets can connect to this server and talk to it. It can also broadcast to all clients or emit to a specific client. This is the most basic example which will work for local Unix and Windows Sockets as well as local or remote network TCP Sockets.

import ipc from "@achrinza/node-ipc";

ipc.config.id = "world";
ipc.config.retry = 1500;

ipc.serve(function () {
  ipc.server.on("message", function (data, socket) {
    ipc.log("got a message : ".debug, data);
    ipc.server.emit(
      socket,
      "message", //this can be anything you want so long as
      //your client knows.
      data + " world!"
    );
  });
  ipc.server.on("socket.disconnected", function (socket, destroyedSocketID) {
    ipc.log("client " + destroyedSocketID + " has disconnected!");
  });
});

ipc.server.start();

Client for Unix Sockets & TCP Sockets

The client connects to the servers socket for Inter Process Communication. The socket will receive events emitted to it specifically as well as events which are broadcast out on the socket by the server. This is the most basic example which will work for both local Unix Sockets and local or remote network TCP Sockets.

import ipc from "@achrinza/node-ipc";

ipc.config.id = "hello";
ipc.config.retry = 1500;

ipc.connectTo("world", function () {
  ipc.of.world.on("connect", function () {
    ipc.log("## connected to world ##".rainbow, ipc.config.delay);
    ipc.of.world.emit(
      "message", //any event or message type your server listens for
      "hello"
    );
  });
  ipc.of.world.on("disconnect", function () {
    ipc.log("disconnected from world".notice);
  });
  ipc.of.world.on(
    "message", //any event or message type your server listens for
    function (data) {
      ipc.log("got a message from world : ".debug, data);
    }
  );
});

Server & Client for UDP Sockets

UDP Sockets are different than Unix, Windows & TCP Sockets because they must be bound to a unique port on their machine to receive messages. For example, A TCP, Unix, or Windows Socket client could just connect to a separate TCP, Unix, or Windows Socket sever. That client could then exchange, both send and receive, data on the servers port or location. UDP Sockets can not do this. They must bind to a port to receive or send data.

This means a UDP Client and Server are the same thing because in order to receive data, a UDP Socket must have its own port to receive data on, and only one process can use this port at a time. It also means that in order to emit or broadcast data the UDP server will need to know the host and port of the Socket it intends to broadcast the data to.

This is the most basic example which will work for both local and remote UDP Sockets.

UDP Server 1 - "World"

import ipc from "@achrinza/node-ipc";

ipc.config.id = "world";
ipc.config.retry = 1500;

ipc.serveNet("udp4", function () {
  console.log(123);
  ipc.server.on("message", function (data, socket) {
    ipc.log(
      "got a message from ".debug,
      data.from.variable,
      " : ".debug,
      data.message.variable
    );
    ipc.server.emit(socket, "message", {
      from: ipc.config.id,
      message: data.message + " world!",
    });
  });

  console.log(ipc.server);
});

ipc.server.start();

UDP Server 2 - "Hello"

note we set the port here to 8001 because the world server is already using the default ipc.config.networkPort of 8000. So we can not bind to 8000 while world is using it.

ipc.config.id = "hello";
ipc.config.retry = 1500;

ipc.serveNet(8001, "udp4", function () {
  ipc.server.on("message", function (data) {
    ipc.log("got Data");
    ipc.log(
      "got a message from ".debug,
      data.from.variable,
      " : ".debug,
      data.message.variable
    );
  });
  ipc.server.emit(
    {
      address: "127.0.0.1", //any hostname will work
      port: ipc.config.networkPort,
    },
    "message",
    {
      from: ipc.config.id,
      message: "Hello",
    }
  );
});

ipc.server.start();

Raw Buffer or Binary Sockets

Binary or Buffer sockets can be used with any of the above socket types, however the way data events are emit is slightly different. These may come in handy if working with embedded systems or C / C++ processes. You can even make sure to match C or C++ string typing.

When setting up a rawBuffer socket you must specify it as such :

ipc.config.rawBuffer = true;

You can also specify its encoding type. The default is utf8

ipc.config.encoding = "utf8";

emit string buffer :

//server
ipc.server.emit(socket, "hello");

//client
ipc.of.world.emit("hello");

emit byte array buffer :

//hex encoding may work best for this.
ipc.config.encoding = "hex";

//server
ipc.server.emit(socket, [10, 20, 30]);

//client
ipc.server.emit([10, 20, 30]);

emit binary or hex array buffer, this is best for real time data transfer, especially whan connecting to C or C++ processes, or embedded systems :

ipc.config.encoding = "hex";

//server
ipc.server.emit(socket, [0x05, 0x6d, 0x5c]);

//client
ipc.server.emit([0x05, 0x6d, 0x5c]);

Writing explicit buffers, int types, doubles, floats etc. as well as big endian and little endian data to raw buffer nostly valuable when connecting to C or C++ processes, or embedded systems (see more detailed info on buffers as well as UInt, Int, double etc. here)[https://nodejs.org/api/buffer.html]:

ipc.config.encoding = "hex";

//make a 6 byte buffer for example
const myBuffer = Buffer.alloc(6).fill(0);

//fill the first 2 bytes with a 16 bit (2 byte) short unsigned int

//write a UInt16 (2 byte or short) as Big Endian
myBuffer.writeUInt16BE(
  2, //value to write
  0 //offset in bytes
);
//OR
myBuffer.writeUInt16LE(0x2, 0);
//OR
myBuffer.writeUInt16LE(0x02, 0);

//fill the remaining 4 bytes with a 32 bit (4 byte) long unsigned int

//write a UInt32 (4 byte or long) as Big Endian
myBuffer.writeUInt32BE(
  16772812, //value to write
  2 //offset in bytes
);
//OR
myBuffer.writeUInt32BE(0xffeecc, 0);

//server
ipc.server.emit(socket, myBuffer);

//client
ipc.server.emit(myBuffer);

Server with the `cluster` Module

@achrinza/node-ipc can be used with Node.js' cluster module to provide the ability to have multiple readers for a single socket. Doing so simply requires you to set the unlink property in the config to false and take care of unlinking the socket path in the master process:

Server

import fs from "fs";
import ipc from "@achrinza/node-ipc";
import { cpus } from "os";
import cluster from "cluster";

const cpuCount = cpus().length;

const socketPath = "/tmp/ipc.sock";

ipc.config.unlink = false;

if (cluster.isMaster) {
  if (fs.existsSync(socketPath)) {
    fs.unlinkSync(socketPath);
  }

  for (let i = 0; i < cpuCount; i++) {
    cluster.fork();
  }
} else {
  ipc.serve(socketPath, function () {
    ipc.server.on("currentDate", function (data, socket) {
      console.log(`pid ${process.pid} got: `, data);
    });
  });

  ipc.server.start();
  console.log(`pid ${process.pid} listening on ${socketPath}`);
}

Client

import fs from "fs";
import ipc from "@achrinza/node-ipc";

const socketPath = "/tmp/ipc.sock";

//loop forever so you can see the pid of the cluster sever change in the logs
setInterval(function () {
  ipc.connectTo("world", socketPath, connecting);
}, 2000);

function connecting(socket) {
  ipc.of.world.on("connect", function () {
    ipc.of.world.emit("currentDate", {
      message: new Date().toISOString(),
    });
    ipc.disconnect("world");
  });
}

Licensed under MIT license

See the MIT license file.

Comments

@vue/cli-shared-utils dependency install breaks on npm / yarn install when using non-lts versions of node
https://github.com/achrinza/node-ipc/blob/2883c46b511398e7f76ea6c8f7d029c3481b2366/package.json#L10

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.
opened by RedNuttyGuy 5
Advisories
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.

Advisories

Sorted latest to oldest

Deprecation of v10.1.4

Deprecation of v10.1.3

Deprecation of v9.2.0, v9.2.1, v10.1.2

Deprecation of v10.1.0 and v10.1.1
opened by achrinza 4
Issue with Version 9.2.4 on Node.js 18
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 |:

https://github.com/achrinza/node-ipc/blob/07c72fdf8f45ba7f93874cf8bd49c17d500ed87e/package.json#L10
bug v9
opened by rubengees 3

Support Node.js v19

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.

opened by jokay 2

Update node 18
Node 18 is out. vue create depends on this library somehow and chokes on node 18.

error @achrinza/[email protected]: The engine "node" is incompatible with this module. Expected version "8 || 10 || 12 || 14 || 16 || 17". Got "18.0.0" error Found incompatible module.

I ran npm test with node 18 and the tests seem to pass. You might have to release a patch release after this.

node --version v18.0.0
opened by erg 1
Deprecation of `v10.1.4`
Deprecation of v10.1.4

Subscribe to this issue to receive critical updates on this advisory.

Summary

Applies to:

@achrinza/node-ipc@^10

Deprecated:

@achrinza/[email protected]

Replacement:

@achrinza/[email protected]

Description

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.

References

https://github.com/achrinza/node-ipc/pull/27

https://github.com/achrinza/node-ipc/commit/3a909b05c20980cfc4f0ab24112db70eb755cb76

https://github.com/achrinza/event-pubsub/issues/6
opened by achrinza 0
Deprecation of `v10.1.3`
Deprecation of v10.1.3

Subscribe to this issue to receive critical updates on this advisory.

Summary

Applies to:

@achrinza/node-ipc@^10

Deprecated:

@achrinza/[email protected]

Replacement:

@achrinza/[email protected]

Description

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.3

0.1.4

node-http-server@^8.1.3

vanilla-test@^1.4.2

0.1.5

node-http-server@*

vanilla-test@*

0.1.6

node-http-server@*

vanilla-test@*

strong-type@^1.0.1 - 1.0.1

v10.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.

References

https://github.com/achrinza/node-ipc/pull/22
opened by achrinza 0
Deprecation of `v9.2.0`, `v9.2.1`, `v10.1.2`
Deprecation of v9.2.0, v9.2.1, v10.1.2

Subscribe to this issue to receive critical updates on this advisory.

Summary

Applies to:

@achrinza/node-ipc@^9

@achrinza/node-ipc@^10

Deprecated:

@achrinza/[email protected]

@achrinza/[email protected]

@achrinza/[email protected]

Replacement:

@achrinza/[email protected]

@achrinza/[email protected]

Description

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.1

v9.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.

References

https://github.com/node-ipc/node-ipc/issues/2

https://github.com/achrinza/node-ipc/pull/16

https://github.com/achrinza/node-ipc/pull/17
opened by achrinza 0
chore: switch to `@node-ipc/js-queue`

This removes a transitive nested dependency that's managed by @/riaevangelist (The original author of node-ipc) - easy-stack@^1.0.1.

see: https://github.com/node-ipc/node-ipc/issues/2

Signed-off-by: Rifa Achrinza [email protected]

opened by achrinza 0
chore: switch to `@node-ipc/js-queue`

This removes a transitive nested dependency that's managed by @/riaevangelist (The original author of node-ipc) - easy-stack@^1.0.1.

Changes in @node-ipc/js-queue compared to upstream: https://github.com/node-ipc/js-queue/compare/78b31b864b2b9db931911d605c1f68efecdd3b63...a699ff0d6e51590ccf567e2ae514ff346f9fe8a5

see: https://github.com/node-ipc/node-ipc/issues/2

Signed-off-by: Rifa Achrinza [email protected]

opened by achrinza 0
Deprecation of `v10.1.0` and `v10.1.1`
Deprecation of v10.1.0 and v10.1.1

Subscribe to this issue to receive critical updates on this advisory.

Summary

Applies to:

@achrinza/node-ipc@^10

Deprecated:

@achrinza/[email protected]

@achrinza/[email protected]

Replacement:

@achrinza/[email protected]

Description

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.0

vanilla-test@^1.4.8

1.4.8

ansi-colors-es6@^5.0.0

strong-type@^1.0.1

1.0.1

vanilla-test@*

1.1.0

vanilla-test@*

1.4.9

ansi-colors-es6@^5.0.0

strong-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.
opened by achrinza 0

chore: Fix support for Node.js 18 with yarn

yarn install was failing with the following error:

error @achrinza/[email protected]: The engine "node" is incompatible with this module. Expected version "13 || 14 || 16 || 17". Got "18.7.0"
error Found incompatible module.

opened by slaweet 1

Configure Renovate
Welcome to Renovate! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin.

🚦 To activate Renovate, merge this Pull Request. To disable Renovate, simply close this Pull Request unmerged.

Detected Package Files

.github/workflows/ci.yaml (github-actions)

package.json (npm)

Configuration

🔡 Renovate has detected a custom config for this PR. Feel free to ask for help if you have any doubts and would like it reviewed.

Important: Now that this branch is edited, Renovate can't rebase it from the base branch any more. If you make changes to the base branch that could impact this onboarding PR, please merge them manually.

What to Expect

With your current configuration, Renovate will create 5 Pull Requests:

chore(deps): update dependency esbuild to ^0.15.0

Schedule: ["at any time"]

Branch name: renovate/esbuild-0.x

Merge into: main

Upgrade esbuild to ^0.15.0

fix(deps): update dependency strong-type to v1.1.0

Schedule: ["at any time"]

Branch name: renovate/strong-type-1.x

Merge into: main

Upgrade strong-type to 1.1.0

chore(deps): update actions/checkout action to v3

Schedule: ["at any time"]

Branch name: renovate/actions-checkout-3.x

Merge into: main

Upgrade actions/checkout to v3

chore(deps): update actions/setup-node action to v3

Schedule: ["at any time"]

Branch name: renovate/actions-setup-node-3.x

Merge into: main

Upgrade actions/setup-node to v3

chore(deps): update dependency node-cmd to v5

Schedule: ["at any time"]

Branch name: renovate/node-cmd-5.x

Merge into: main

Upgrade node-cmd to 5.0.0

🚸 Branch creation will be limited to maximum 2 per hour, so it doesn't swamp any CI resources or spam the project. See docs for prhourlylimit for details.

❓ Got questions? Check out Renovate's Docs, particularly the Getting Started section. If you need any further assistance then you can also request help here.

This PR has been generated by Mend Renovate. View repository job log here.
opened by renovate[bot] 0

Flaky v9 macOS and Windows tests

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.

opened by achrinza 0

Automated scanning of dependency tree for blocklisted maintainers

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.

opened by achrinza 1
Security Checklist
This is an interim checklist of common security-related things that should be resolved:

[x] GitHub 2FA

[x] GitHub branch protection

[x] main

[x] v9

[x] hotfix-*

[x] GitHub PGP-signed Git Commit enforcement

[x] NPM owners' account 2FA

[x] NPM publishing 2FA enforcement

[x] NPM lockfiles

[x] v9

[x] v10

[ ] Automatic upstream backport

[x] NPM lockfile linting (Using lockfile-lint)

[x] v9 - PR: https://github.com/achrinza/node-ipc/pull/13

[x] v10 - PR: https://github.com/achrinza/node-ipc/pull/12

[ ] Package support information (via package.json)

[ ] v9

[ ] v10

[x] Code of Conduct

[x] v9 - PR: https://github.com/achrinza/node-ipc/pull/10

[x] v10 - PR: https://github.com/achrinza/node-ipc/pull/9

[x] Foundational CI testing

[x] v9

[x] v10

[ ] Installation CI testing (with npm pack and minimal test app)

[ ] v9

[ ] v10

[x] No transient direct or nested dependency where riaevangelist has publishing rights

[x] v9 (since v9.2.2) - PR: https://github.com/achrinza/node-ipc/pull/17

[x] v10 (since v10.1.5) - PR: https://github.com/achrinza/node-ipc/pull/11, https://github.com/achrinza/node-ipc/pull/16, https://github.com/achrinza/node-ipc/pull/27

[x] Instalable with --ignore-scripts (with CI testing)

[x] v9

[x] v10

[ ] Coverage reporting (via Coveralls)

[x] v9 - PR: https://github.com/achrinza/node-ipc/pull/19

[ ] v10

[ ] CI Code Security Analysis

[ ] OpenSSF Scorecard

[ ] GitHub CodeQL

[ ] v9

[ ] v10

[ ] OpenSSF Best Practices Badge

[ ] CI publishing (with changelog generation)

[ ] v9

[ ] v10

[ ] Dependency update bumps (via Renovate)

[ ] v9

[ ] v10

[ ] Security Program

[ ] Security e-mail with PGP key

[ ] SECURITY.md

[ ] Security Advisory Database

[ ] License compliance

[ ] REUSE compliance

[ ] v9

[ ] v10

[ ] License scanning (via FOSSA / pkg:npm/licensee)

[ ] Changelog (with Conventional Changelog)

[ ] v9

[ ] v10

[ ] CycloneDX (changelog + predigree)

[ ] v9

[ ] v10

[ ] SLSA (predigee)

[ ] v9

[ ] v10
opened by achrinza 0
Read this: Maintenance Fork
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?

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).

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:

Provide clean versions of the upstream package.

Follow upstream as closely as possible

Publish dependency version bumps

Run tests against new versions of Node.js and fix any issues

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:

Governance FAQ: Queries with how this package is maintained.

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?

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.

v9: https://github.com/achrinza/node-ipc/compare/84dce1b4b28ac4fc66179ee3dcd5bc6d6c1032f1...v9

v10/11: https://github.com/achrinza/node-ipc/compare/f23a40906266a343c00cce8d4905602743d888d3...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 https://github.com/achrinza/node-ipc/issues/4 for the security checklist.

See https://github.com/achrinza/node-ipc/issues/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 https://github.com/achrinza/node-ipc/issues/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 https://github.com/loopbackio/security/issues/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
v10: 14,16,17,18,19 | 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.
opened by achrinza 10