951–960 of 1001 posts
Earlier quoted context omitted.
This is incredible. At this rate, there's a non-zero chance that one of the transitive dependencies is SQLite itself.
3 different types of sqlite, 14 different versions total: https://github.com/tursodatabase/turso/network/dependencies?...
Earlier quoted context omitted.
> External libraries are not for functionality that is used by most modern software. Where do you draw the line though? It seems like you mostly spend your time writing HTTP servers reading/writing JSON, but is that what everyone else also spends their time doing? You'll end up with a standard library weighing GBs, just because "most developers write HTTP servers", which doesn't sound like a better solution. I'm will…
> everything should be a library. That's exactly npm's problem, though. What everybody is avoiding to say is that you need a concept of "trusted vendors". And, for the "OSS accelerates me" business crowd, that means paying for the stuff you use. But who would want that when you're busy chasing "market fit".
I don't think that's the problem with npm. The problem with npm is that no packages are signed, at all, so it ends up trivial for hackers to push new package versions, which they obviously shouldn't be able to do.
Earlier quoted context omitted.
This is the right answer. I'm willing to stick my head out and assert that languages with a "minimal" standard library are defective by design. The argument of APIs being stuck is mood with approaches like Rust's epocs or "strict mode". Standard libraries should include everything needed to interact with modern systems. This means HTTP parsing, HTTP requests, and JSON parsing. Some laguages are excellent (like python…
Spot on, I rather have a Python, Java,.NET,.. standard library, that may have a few warts, but works everywhere there is full compliant implementation, than playing lego, with libraries that might not even support all platforms, and be more easily open to such attacks. Is java.util.logging.Logger not that great? Sure, yet everyone that used it had a good night rest when Log4J exploit came to be.
Earlier quoted context omitted.
The blessing and curse of frontend development is that there basically isn't a barrier to entry given that you can make some basic CSS/JS/HTML and have your browser render it immediately. There's also the flavor of frontend developer that came from the backend and sneers at actually having to learn frontend because "it's not real development"
> There's also the flavor of frontend developer that came from the backend and sneers at actually having to learn frontend because "it's not real development" What kind of code does this developer write?
So, other packaging environments have a tendency to slow down the rate of change that enters the user's system. Partly through the labor of re-packaging other people's software, but also as a deliberate effort. For instance: Ubuntu or RedHat. Is anyone doing this in a "security as a service" fashion for JavaScript packages? I imagine a kind of package escrow/repository that only serves known secure packages, and acti…
I've worked in companies that do this internally, e.g., managed pull-through caches implemented via tools like Artifactory, or home-grown "trusted supply chain" automation, i.e., policy enforcement during CI/CD prior to actually consuming a third-party dependency. But what you describe is an interesting idea I hadn't encountered before! I assume such a thing would have lower adoption within a relatively fast-moving e…
> The closest thing I can think of (and this isn't strictly what you described) is reliance on dependabot, snyk, CodeQL, etc which if anything probably contributes to change management fatigue that erodes careful review.
It's not glamorous work, that's for sure. And yes, it would have to rely heavily on automated scanning to close the gap on the absolutely monstrous scale that npmjs.org operates at. Such a team would be the Internet's DevOps in this one specific way, with all the slog and grind that comes with that. But not all heroes wear capes.
Earlier quoted context omitted.
This is the right answer. I'm willing to stick my head out and assert that languages with a "minimal" standard library are defective by design. The argument of APIs being stuck is mood with approaches like Rust's epocs or "strict mode". Standard libraries should include everything needed to interact with modern systems. This means HTTP parsing, HTTP requests, and JSON parsing. Some laguages are excellent (like python…
It's not an easy problem to solve. Doing it the right way would create friction, developers might need to actually understand what the code is doing rather than pulling in random libraries. Try explaining to your CTO that development will slow down to verify the entire dependency chain. I'm more thinking C# or Java. If Microsoft or Oracle is providing a library you can hope it's safe. You *could* have a development e…
Then let's add friction. Developers understanding code is what they should be doing.
CTOs understand the high cost of ransomware and disruption of service.
Earlier quoted context omitted.
As a security guy, for years, you get laughed out of the room suggesting devs limit their dependencies and don't download half of the internet while building. You are an obstruction for making profit. And obviously reading the code does very little since modern (and especially Javascript) code just glues together frameworks and libraries, and there's no way a single human being is going to read a couple million lines…
This comes across as not being self-aware as to why security as laughed out of rooms: I read this as you correctly identifying some risks and said only offered the false-dichotomouy of solutions of "risk" and "no risk" without talking middle grounds between the two or finding third-ways that break the dichotomy. I could just be projecting my own bad experiences with "security" folks (in quotes as I can't speak to the…
Earlier quoted context omitted.
It's a lot harder to do useful things with backend languages. JavaScript is more profitable as you can do the crypto wallet attacks without having to exploit kernel zero days.
It's trivial to run an exploit shell from almost any language when you have non-sandboxed code running on the target machine.
Earlier quoted context omitted.
As a security guy, for years, you get laughed out of the room suggesting devs limit their dependencies and don't download half of the internet while building. You are an obstruction for making profit. And obviously reading the code does very little since modern (and especially Javascript) code just glues together frameworks and libraries, and there's no way a single human being is going to read a couple million lines…
The "solution" would be using a language with a strong standard library and then having a trusted 3rd party manually audit any approved packages. THEN use artifactory on top of that. That's boring and slow though. Whatever I want my packages and I want them now. Apart of the issue is the whole industry is built upon goodwill and hope. Some 19 year old hacked together a new front end framework last week, better use it…
The thing is, you don't have to be this undiscerning to end up with tons of packages.
Let's init a default next.js project. How many dependencies are there?
react, react-dom, next, typescript, @types/node, @types/react, @types/react-dom.
OK so 7... seems like a lot in some sense but its still missing many reasonable dependencies. Some sort of styling solution (tailwind, styled components, etc). Some sort of http client or graphql. And more. But lets just use the base dependencies as an example. Is 7 so bad? Maybe, maybe not, but you need to go deeper. How many packages are there?
55. What are they? I have no idea, go read the lock file I guess.
All of this while being pretty reasonable.