Why do we need these frameworks/libraries though ?
<package-manager> add/install vue
and that’s it! It downloads everything it needs to run and you are good to go. Based on the environment (dev/prod/test) in which the app needs to run, you can configure which packages you need for your app to run in that specific environment.
What happens internally when we install packages ?
Every engineer working with npm or any other package manager should know the answer to the above question. A detailed answer can be found here else if you are feeling lazy and just want to know the basics then keep on reading. Every new package brings with itself other packages which are required for it to run smoothly and those other packages install even more packages for them and before you know it your project has a set of packages about which you have no clue. Lets say if you install a package
Bfor your app
Athen you have a direct dependency on this package and if it needs a package
Cthen you have a transitive dependency on package
C and so on.
Why should we bother about transitive dependencies ?
In any application, the graph of dependencies is complex and is not visually appealing also 😛 when compared to the graph below. Depending on what packages you are using for your project the graph can have many more levels and many more nodes to it. Basically, longer and wider.
Let’s imagine a slightly more practical scenario where the graph looks something like below for your project. As you can see that there are multiple paths which lead to package
X Consider B1 & B2 as two different packages and the same for C1 and C2 since the numbers 1 & 2 are not to be confused with the versions of packages B & C.
A -> B2 -> C1 -> X & A -> B1 -> C2 -> X
X since it’s marked in red represents something which can cause problems for your project in some ways. Lets have a look at the two popular scenarios where things can go wrong due to package
Packages such as vue, jquery etc. have a MIT license, which can be paraphrased as saying,
It lets people do anything they want with your code as long as they provide attribution back to you and don’t hold you liable
pdf.js uses Apache License 2.0 which quotes
Similar to the MIT License, but also provides an express grant of patent rights from contributors to users
Both the above licenses seem fine and seem to pose no threats no matter what type of use you put them to, even commercial. No matter how restrictive a license is for a third party package it is not an issue until it is distributed to the public (unless the package license terms state explicitly that its illegal to use privately also) and it’s also ok to distribute the package to employees who are part of the same organisation.
Now you might think that since your software/service is distributed over a network for a SaaS (Software as a Service) based product of yours and is not present on a user’s machine that it’s ok to use any third party package — but licenses like GNU AGPLv3 also considers network usage as a distribution of the software.
How can the above security and legal issues be prevented ?
Now that we know what the problems are, a reasonable solution, from the top of my head is to come up with a way where by we can look at each package which is used (directly/indirectly) by my project starting from the
package.json file (for npm). This is something which is called a
deep scan of dependencies. Your deep scan should be able to look at each package and make a decision whether it is safe to use or not from both security and legal perspectives. This whole process has three parts to it :
- To be able to scan efficiently and properly all the dependencies in your project.
- To be able to make a decision on whether it’s safe to use a package from security and legal point of view.
- Doing 1 & 2 repeatedly
To summarise, the concept of npm and package managers is awesome but always keep your eyes open for what your dependencies are bringing with them for you. Cheers!
Some sources which can be further useful