4 ms·
Do not use dependencies. Implement everything from scratch. Maybe having a huge reviewed std library solves this, if you never need to import anything from a th
by hpeter 3y ago
Do not use dependencies. Implement everything from scratch. Maybe having a huge reviewed std library solves this, if you never need to import anything from a third party.
As long as there are supply chains there are attacks. reduce your dependencies to bare minimum.
- leros 3y agoYou can use dependencies. You just need to cache them internally, review them meticulously, and never upgrade them without going through the review process again. It's a huge pain but some companies do it.
- brianhama 3y agoOut of date dependencies also introduces vulnerabilities though. So you’re screwed no matter what.
- leros 3y agoThat is true. So you need to continually audit those dependencies as well and upgrade them when security requires it.
- uecker 3y agoEssentially this is was distributions such as Debian do for your (if you trust them and their security enough which depends on your requirements). xz is noteworthy because someone spent more than two years trying to subvert this. Note that the distributions used by package managers such npm, pip, or cargo do not do this. So be wary of the "all old is bad and needs to be rewritten and C does not even have a proper package manager" crowd. (memory safety is a good thing though)
- hackable_sand 3y agoOr fork and cache with dedicated maintenence, if that's what you were indicating above.
- leros 3y agoNot forking. There are systems for internal dependency management. You can have an internal npm or maven or whatever with only approved packages and versions.
- cdmckay 3y agoThis is not realistic for most startups. You’d spend all your time reviewing packages and no time building.
- leros 3y ago100%. It's also awful inside a big corporation. Imagine waiting weeks or months to get a new package approved.
- deleted 3y ago[deleted]
- bennettnate5 3y agoA big issue with this is that programmers re-implementing parsing code--be it for network protocols, file formats, or the like--are bound to make the same mistakes that lead to DOS/memory corruption vulnerabilities. Pulling code into the standard library for every possible network protocol, file format, compression standard, etc. would engorge the stdlib to the point that it would be impossible to both maintain and stringently audit incoming changes. That being said, I am a big proponent of keeping dependencies slim, and library authors should especially aim for minimal dependencies where they can--that would help account for the deeply-nested dependency issue we see in npm and the like.