Are there any closed source dependecies used by Storj software (Satellite, SNO, client)?
Are there many open source dependencies used by Storj software?
Is there a safety protocol for verifying and testing each version for each dependencie that gets used in the project?
Is this protocol followed to the letter?
I don’t look for specific answears, I just want to know that Storj Inc. is doing everything it can to prevent side channel attacks, because any dev. can go rogue or have his github account compromised.
I’m not a programmer, but I read articles about compromised open source software that keep me up at night…
And I don’t approve of any closed source dependencie used in an open source project.
Please check our GitHub repo, the file go.mod in particular in any repo:
You may check the license of a each dependency yourself.
1 Like
And this is the procedure of adding / auditing new dependencies: Dependencies · storj/storj Wiki · GitHub
4 Likes
I share your concerns and I’ll try to answer as clearly as possible without diving too deep.
Are there any closed source dependecies used by Storj software (Satellite, SNO, client)?
The short answer, yes, it’s open source. You can even setup a local testing network via GitHub - storj/up: Docker-compose files for running full Storj network locally.
The only private part what we use for runtime is some branding / style customization, everything else is open source. We have some internal tools / configuration sets / deployment descriptors / tooling which are not open source, but they are not a strong requirement for running an independent Satellite. And we try to open source these, when it makes sense (for example the batch payment scripts are open sources after a refactor: GitHub - storj/crypto-batch-payment: A high volume ERC20 token payment application.)
Also: our runtime environment has some dependencies to restricted resources (like GeoIP database, or payment services). We use them, but they are optional…
Are there many open source dependencies used by Storj software?
Depends on what your definition of “many” is.
We try to keep external dependencies minimal and weigh between adding a dependency, forking and minimizing the library and writing from scratch. Each approach has their own pros/cons. I even wrote a tool to better understand and remove dependencies https://github.com/loov/goda.
You can look at the respective go.mod / package.json for the exact number.
Is there a safety protocol for verifying and testing each version for each dependencie that gets used in the project?
Our checklist for adding or updating dependencies is listed in docs/code/Dependencies.md at 3e04affad8f37b661c08cf37e02c4d46e1ae5c76 · storj/docs · GitHub
Is this protocol followed to the letter?
The strictness depends on a few factors – is it in a critical part of the system and how trusted is the third-party. e.g. dependencies from Google are more trusted than dependencies maintained by a single person.
Reviewing code for every single compiler and tool we use is unfortunately impossible for a company the size of Storj. Only companies such as Google, Facebook or Amazon have enough resources to do it.
I don’t look for specific answers, I just want to know that Storj Inc. is doing everything it can to prevent side channel attacks, because any dev. can go rogue or have his github account compromised.
As usual, the answer has to be nuanced, because “doing everything” is unattainable for many companies. You could take this to the extreme of starting producing your own chips that definitely don’t have any malware embedded, then creating custom network hardware, then rewriting a new OS from scratch etc… Of course, I understand that’s probably not what you mean by “doing everything”.
In other words, we do consider side-channel attacks and audit the code (with varying thoroughness).
… but I read articles about compromised open source software that keep me up at night…
Likewise.
And I don’t approve of any closed source dependencies used in an open source project.
Github, MacOS, Windows, Discord, Slack, Google Cloud, AWS… etc are all closed source. Most (if not all) of the hardware you daily use is closed source. So much of open-source does depend on closed-source… the question is where do you draw the line on what you consider a dependency. So, if you simply look at the “source code dependencies” then that isn’t sufficient for a full security analysis.
Either way, I didn’t want to be nitpicky on the questions – I was mainly trying to shed light on the nuances of these problems. I do share the sentiment on being concerned about third-party dependencies.
I’m not sure whether this is the answer you were looking for, but hopefully it does give some better understanding.
6 Likes
Yes, I don’t want specifics to give others some secret insight or bad ideas. I’m not familiar with a developement enviroment, meaning a software company with it’s rules, but I wanted to bring in discussion this quick topic. Now I think I get the general picture. Thanks!
1 Like