Semi related to this I think a good way to avoid back doors in open source software is to have as few dependencies as possible. So I appreciate that this is a thing.
Maybe it avoids backdoors but it also avoids the maturity and security of using shared implementations for common tasks in favour of half-assed implementations in your own code.
Speaking specifically about npm: A ton of packages used as dependencies for a million different things have very loose quality control, some even merge community PRs straight to release without checking the code in any way. More often than not I have run into packages maintained by people with no connection to the original dev and don’t even know how its code actually works.
I remember a couple years ago I needed to read zip64 files so I picked up the zip file definition and implemented the read operation for it in the package we were using for zips. I only implemented a very small subset of the format to strictly solve my problem. I opened a pr to them saying “here’s some quickstart of you plan to add full support for zip64” - next time I checked they has merged my pr as if was and now were having folks registering issues for incomplete zip64 support.
And you think the same language ecosystem that produces those results will suddenly produce better ones when the same code is inlined, probably as a copy of some Stackoverflow code or potentially code they found on GitHub in some random fork of some other repository?
True, but the opposite is true too, just because you or one of your team members wrote it that doesn’t mean it is a good implementation. Especially considering your team can not have domain experts on everything. There is reason the rule is “never roll your own crypto” and not “crypto is security relevant, always roll your own”.
Semi related to this I think a good way to avoid back doors in open source software is to have as few dependencies as possible. So I appreciate that this is a thing.
Maybe it avoids backdoors but it also avoids the maturity and security of using shared implementations for common tasks in favour of half-assed implementations in your own code.
Speaking specifically about npm: A ton of packages used as dependencies for a million different things have very loose quality control, some even merge community PRs straight to release without checking the code in any way. More often than not I have run into packages maintained by people with no connection to the original dev and don’t even know how its code actually works.
I remember a couple years ago I needed to read zip64 files so I picked up the zip file definition and implemented the read operation for it in the package we were using for zips. I only implemented a very small subset of the format to strictly solve my problem. I opened a pr to them saying “here’s some quickstart of you plan to add full support for zip64” - next time I checked they has merged my pr as if was and now were having folks registering issues for incomplete zip64 support.
And you think the same language ecosystem that produces those results will suddenly produce better ones when the same code is inlined, probably as a copy of some Stackoverflow code or potentially code they found on GitHub in some random fork of some other repository?
Yes, I trust my coworkers and our company’s workflow enough to produce better code than that.
Just because someone else wrote it, doesn’t mean it’s a good implementation, or worth bringing its pile or dependencies into your project.
True, but the opposite is true too, just because you or one of your team members wrote it that doesn’t mean it is a good implementation. Especially considering your team can not have domain experts on everything. There is reason the rule is “never roll your own crypto” and not “crypto is security relevant, always roll your own”.
Only if this does not mean that all dependencies are bundled.