Are the Nodejs bcrypt packages on the path to fail?

Before you read this post, I have to give credit to the class I’ve taken at RIT called Humanitarian and Free Open Source Software. Open-source work done at RIT can be found here.

Analyzing packages on npm is very hard. Not just npm but every open source project has to be assessed before implementing it to your project. If it is a one-time project you are doing for fun and it is just for personal use then it’s very likely to be ok. For projects that are going to be used by end-users and not just you, then the assessment should kick in.

I have been using a package called “bcrypt” on Node Package Manager. For a while, I never actually looked into whether a package is headed toward failure or growth. Taking a class at RIT, I started to gain the habit of doing research about not just packages but their communities as well. They go hand in hand which is very important.

Some of the things that are a MUST have:

• Licenses that cover every file of the project
• Community engagement and communication channels (mailing lists, discord, google groups, etc.)
• Issue Trackers
• Community Guidelines
• Onboarding documentation/instructions
• Release documentation
• Code documentation

Why did I start getting concerned about bcrypt?

At the time of writing this post, I just started to code microservices for a startup called Vela. Feel free to go check our website and blogs 🙂 I was looking into the packages I used in past projects and checking to see whether, in the long term, they are worth keeping to work with.

The next package on my list was bcrypt. To my surprise, it wasn’t quite popular as I thought (looking at downloads/forks/stars. I remember seeing it used in a blog post and used it from thereon. What a big mistake I made. I’m glad that I haven’t used it somewhere I have to depend on it.

The funniest thing is that I still see it everywhere in blog posts, Stack Overflow, GitHub issue discussions, and more. I also found two more implementations of bcrypt:

• Fast Web Assembly Version: bcrypt-fast-wasm
• Optimized and No Dependency Version: bcryptjs

It is even more interesting that these packages have not been active for a while as well. Even though it is a package focusing on hashing, you would expect developers using it (seems like 1M+ on just bcrypt and bcryptjs, and that is known) to want it to be active and improving. That is what was catching my attention.

Cauldron Analysis

Cauldron analysis is what can be done to analyze the health of communities behind projects. To see the cauldron analysis that I created for all three of the repositories covered in this post, here is the link.

Now let’s take a look at their graphs individually.

First up, bcrypt-fast-wasm

As I mentioned, this is the fast implementation of the main bcrypt project. It is implemented using web assembly which makes it much faster compared to the other two.

This is very much a personal project that has no community around it that is contributing. Just a one-off commit and publish is the case for this one. The graph on the left shows that there were only three commits, and the one on the right shows that there was only one author.

Looking at the repository there doesn’t seem to be issues created or any other commit after the ones in 2019. The analysis also shows that the activity has been very stagnant. The activity and community stats can be seen below.

Next up, bcryptjs

A third-party package having no dependencies can be advantageous in some situations. In a case where you depend on a package, if there is a security vulnerability or stagnancy in one of the packages you depend on you should be very worried and hope that it gets patched up really quickly. That’s an important point in having no dependencies. This is why it is a good option aside from bcrypt.

Unlike bcrypt-fast-wasm, this project is much more active even though there has been a no-commit period. The growth is going down over time but the promising side of this repository is that there are more than 600 thousand people using it and there is active discussion on the Github issues page.

This is much better than the fast implementation version. Quite important to have a community surrounding it. It means that there could be action taken quicker if there is a security concern. If you have any questions, there is someone that can respond. There is also the possibility that a discussion can spark up a new feature.

There are many more positive aspects of this repository compared to the fast implementation. Looking at the activity and community stats, however, there are some concerns. Year-over-year stats show that there is a -100% decrease, so nothing. Eventually, this is going to push the ones that are interested to move away from this project.

Moving on to the final one, bcrypt

Let’s take a look at the original one, bcrypt. This is the one that is the oldest one among the options. The first commit seems to be back in April 2010. There are also two dependencies that can be seen in the package.json file. Here are the two packages that it depends on from the latest commit:

"dependencies": {
    "@mapbox/node-pre-gyp": "^1.0.7",
    "node-addon-api": "^3.1.0"
  },

It’s critical to note that yes, you always should be checking how many packages a project depends on. Because later on if there is a security vulnerability, it will trickle down the ladder and a lot of people are affected by it. There has been a similar situation with the Log4j vulnerability where a lot of companies and people who were customers of the companies providing a service got affected.

In this case, the two dependencies are related to using C++ binaries or using Nodejs API from C++. So they are important libraries that have a lot of contributions and activities. If you would like to check out the packages here are the links to the repositories of @mapbox/node-pre-gyp and node-addon-api.

This package is the one I trust among the three of them because of the activity and the number of authors. It means that there is interest and a community that is ready to act upon anything that could trigger something negative.

Here are some stats of this repository:

As it can be seen, it is still concerning that overall activity is decreasing, it is much better than bcryptjs and bcrypt-fast-wasm.

Overall

Licenses

All packages seem to be good on licenses, they cover the whole repository and any dependent package. This is very good, and it is a protection for your project, and the community surrounding it because they are the ones contributing to it.

Release Notes

One thing missing in the bcrypt-fast-wasm package is that there are no release notes, aka changelogs, for new versions or updates. This could be because the author of the repository was just aiming for a one-off commit. The other two have changelogs and are also more than one, meaning they are being updated and are also documented appropriately.

Code Documentation

This section is a bit tricky in my opinion because they are quite small packages, it’s not really expected to have a web page where there are full detailed explanations. In my experience, such packages use the readme-files to document their usage.

A big thumbs up goes to the package bcrypt here. They have a wiki page in the GitHub repository that covers comparisons between the package bcryptjs, instructions for installation, security issues and concerns, common issues, and their solutions. These are very helpful when using the package.

For the bcryptjs project, the wiki contains benchmarks, which could be helpful if you are looking for a performance gain. Otherwise, all three utilize the readme file to document and give examples to use the package. Unfortunately, the bcrypt-fast-wasm readme page isn’t quite the best.

Code of Conduct and Contributions

None of the packages have either a code of conduct or a guideline to contribute. The importance of these two for the community is massive. A code of conduct is a way to tell users what is and is not tolerated in the community. Contribution guidelines help the developer get up and running with setups for communication, creating issues, pull requests, and more. These allow less distraction to the developers/contributors that have already been working. This also tells me that community engagement is very low for all packages.

Should I use these packages? Are they on the path to failure?

I wouldn’t say they are on the path to failure. All of them for sure have margins to improve on community engagement and documentation.

If I’m starting a project and debating which one to use, I would say weigh the pros and cons between the bcrypt and the bcryptjs package as there is definitely a visible difference in activity surrounding them. If you prefer no dependencies, go with bcryptjs, if you need more activity and people in the community, and more communication, go with bcrypt. If you have an idea to contribute to either I would say try bcrypt first since communication activity is much greater. There could be more effective debates on whether or not it would work, and if it can, how to implement it.