DEV Community: Pooya Parsa

Why I dislike GitHub security alerts? (and how to disable them)

Pooya Parsa — Thu, 06 Jun 2019 18:32:29 +0000

You may have heard about Github Security Alerts and received some for your projects (if you are an open source maintainer, probably a LOT of them!)

Well, that sounds so promising, doesn't it? But the truth is that most the cases are false-positive, non-effective or a security alert doesn't provide any solution! In this article, I will try to explain about reasonings why GitHub security is not good protection and a workaround to avoid spams in your email.

For npm package maintainers

Package dependencies are usually specified with a caret (^) or tile (~) range (learn more about semver). This means even if you don't explicitly upgrade to a patch or minor version of a dependency, fresh installs of your package receive the patch of the dependencies so you shouldn't worry.

dependabot (which is acquired by Microsoft/GitHub and now enabled by default on all repositories) tries to just update lock-file in the repository. This doesn't fix anything for your package users as lock file is not published with your package and will not be used by package managers when someone installs your package. So what's the benefit? Probably nothing! unless dependency is harmless itself by execution (for example running malicious code or leaking tokens) which in this cases npm security team will take fast action and remove tarball from the registry, before any disclosure. Also, many security alerts are usually related to devDependencies which are totally irrelevant as these dependencies are probably used for your local environment and not affecting end-users if there is a bug into them. (at least is not a security problem!)

For end-projects

If you have a GitHub project that powers a public website or an API, it really matters that you receive security patches ASAP and deploy them. But personally, still don't feel good about having GitHub eyes on all of my projects by default:

Many of my personal GitHub repositories are temporary projects or examples and are not going to be updated. A regex DDOS is irrelevant for them and it is just annoying about GitHub that frequently requests me to update their dependencies.
Many of security alerts are false-positive or related to devDependencies. Like a potential bug in a jest dependency. Certainly, an attacker does not write a test that runs in CI to break it and it is not really a security alert.

I wish it could be enabled on only projects that I need, not everything! and also there were some options specifying behavior. I don't want to advertise but I had a much better experience and customizability by using Renovate Bot. Another option is snyk which regularly checks your project against known security alerts and more importantly, it provides automated patches for high-impact vulnerabilities (not just alerting)

Disabling GitHub Notifications

Go to the notifications section of your GitHub profile and change preferences according to your needs:

Skipping email alerts from inbox (Gmail)

Even by disabling notifications you will still receive LOTS of emails from GitHub security. You can label them to skip the inbox and go to a specific category or archive by default.

First, open Gmail and search for to:(Security alert <security_alert@noreply.github.com>). Using the dropdown button right to the search box, open more options:

Then click on Create filter to create a filter and configure it according to your preferences:

Disable automated pull-requests

Unfortunately, automated pull-requests are enabled by default for all of your repositories but the good news is that you can still disable them one by one by going to "Security" tab of each repository and selecting "Off: Automated security fixes" from the dropdown:

Conclusion

Never ignore security for your project. If you are the author of a popular npm package or critical website. In this article, I tried to explain why (current) GitHub security is not probably the best tool and provide a way to give back freedom choosing tooling for security checks.

GitHub platform is powering thousands of opensource projects and for sure there is a good intention about new integrated security checks. But it could be better, allowing more customization and considering the facts about semver versioning and also the freedom to opt-in for security alerts. Having lots of irrelevant security alerts makes it harder to observe real security bugs.

Node.js fork is not what you think!

Pooya Parsa — Thu, 24 Jan 2019 23:44:07 +0000

Today I realized that in Node.js, neither cluster.fork or child_process.fork act like something you expect in a C environment. Actually, it is shortly mentioned in docs:

Unlike the fork(2) POSIX system call, child_process.fork() does not clone the current process.

The child_process.fork() method is a special case of child_process.spawn() used specifically to spawn new Node.js processes. Like child_process.spawn(), a ChildProcess object is returned. The returned ChildProcess will have an additional communication channel built-in that allows messages to be passed back and forth between the parent and child.

So what it means?

Taking a simple C code that forks 5 processes:

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>

int main()
{
   printf("Shared Code\n");

   for (int i = 0; i < 5; i++)
   {
      int pid = fork();
      if (!pid)
      {
       return printf("Worker %d\n", i+1);
      }
   }

   return 0;
}

Compiling and running this code gives us a result like this:

Shared
Worker 1
Worker 2
Worker 3
Worker 4
Worker 5

What operating system does under the hoods, is when we call fork(), it copies entire process state to a new one with a new PID. Return value in the worker process is always 0 so we have a way to find-out if rest of the code is running in forked process or master. (Thanks to @littlefox comment🧡)

The important point is that forked process continues from where fork() was called. Not from the beginning so Shared is printed once.

Running a similar code in Node.js:


const { fork, isMaster } = require('cluster')

console.log('Shared')

if (isMaster) {
  // Fork workers.
  for (let i = 0; i < 5; i++) {
    fork();
  }
} else {
  // Worker
  console.log(`Worker`);
}

The output is amazingly different:

Shared
Shared
Worker
Shared
Worker
Shared
Worker
Shared
Worker
Shared
Worker

The point is that each time a worker forked, it started with a fresh V8 instance. This is not a behavior that it's name tells. Fork in Node.js is actually doing exec/spawn which causes shared code running each time.

OK. So let's move `console.log('Shared')` into `if (isMaster)` :P

Well. Yes. You are right. That's the solution. But just for this example case!

In a real-world application that needs a cluster, we don't immediately fork workers. We may want to set up our web framework, parse CLI args and require a couple of libs and files. All of this steps has to be repeated on each worker that may introduce lots of unnecessary overhead.

Final Solution

Now that we know what exactly cluster.fork does under the hood, we can split our worker logic into a seperate worker.js file and change default value of exec which is process.argv[1] to worker.js :) This is possible by calling cluster.setupMaster() on master process.