this post was submitted on 09 Apr 2024
164 points (99.4% liked)
Open Source
31122 readers
281 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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".