Hacker News

points by ang_cire 16 hours ago | 0 comments

"I don't trust code that I don't understand, or that I don't know someone experienced has reviewed."

proceeds to install 200 random npm dependencies

This joke is made a lot but I think most good developers take care in considering the npm dependencies they install. You can get a ton of dependencies pretty easily by just installing very popular ones like react, tailwind, nextjs, etc. If there's ever a dependency that I'm not familiar with then I make sure to take at least a cursory look over the repo to make sure it has a decent number of stars/community, is well maintained, has multiple contributors, etc.

[–] ang_cire 16 hours ago

That is great, but the reality is that your OS, the productivity software you use daily, and the dependencies downstream of the ones you review, are not actually being checked by you for code quality.

Part of using software is just going off how well it works.

When one Linux flavor starts to have issues, most people don't do a dissection on why, they just switch distros. Or web browsers (I've lost count of the back-and-forth between FF and Chrome performance over the years, nevermind all their precursors). Or office suites.

Pretending that the code is what really matters, and not what the code does, is elevating the paint quality over the painting.

[–] xmprt 16 hours ago

I didn't mention the code once in my reply. Code is only one aspect of reviewing a dependency. Much more important is the community and support around the tool/dependency.

When dealing with LLM output, you're getting a 1 of 1. There's no way to measure the community, number of contributors, or how maintainable it is.

[–] ang_cire 15 hours ago

Beyond ongoing support, community/number of contributors doesn't indicate anything, though?

And maintainability is a function of code, as it relates to humans, so it is a measure of the code itself.

One of the things I've actually seen companies considering (due to supply chain compromise attacks), is not just having an in-house package repo that trails public versions, but instead fully in-housing critical dependencies and essentially making them private forks that they (probably use LLMs to) maintain.

Basically cutting out the Chainguard-like companies that made private deps their business model.

[–] xmprt 10 hours ago

You can argue that correlation doesn't imply causation, but typically more contributors means more people who have played a part in the code and so more eyes on the project to catch issues as well as a higher bus factor and less key person risk.

And larger community means there's more rewards for a successful attack and therefore fewer latent security issues (ie, obvious ones are more likely to be caught).

I think companies considering building in-house packages are just trading one risk for another. Especially with LLMs, it's going to be a lot easier to find vulnerabilities in your internal dependency than it would be in a battle hardened dependency used by 100s of others.

[–] x3haloed 15 hours ago

Honestly, I see good points in both of your comment sets.

But there really is a floor on how deeply a person can understand their own software. There has to be a "good enough" somewhere. As a C# dev, I can understand my entire codebase pretty deeply. And I've read enough of the .NET Core framework to understand some of the nuances of how a lot of the methods we rely on every day are implemented. But I've never once looked at the CIL that Roslyn has produced, and certainly not inspected the machine code that the runtime has compiled. I can't read or write Assembly. I don't really know anything about the x86 or ARM instruction sets. My understanding of the CPU is barely better than "it's transistors," and even lower than that, I have a vague awareness that neutrinos from space can flip bits and there are error correcting mechanisms for that, but I have no idea how they work. And yet, I'm able to write fast and reliable software.

There are super knowledgeable devs out there who pretty much DO understand the whole thing, but it's impossible to memorize every line of every version of framework that you're using or the unique alterations and upgrades to every piece of silicon that your program will run on, and as you guys pointed out, proprietary operating systems are basically completely opaque to our understanding.

So the question is really "where is the practical floor that you stand on?" And for me, personally, there is room for at least some areas of code at the application level that I'm OK with never having read myself.

[–] andrewstuart 15 hours ago

>> I think most good developers take care in considering the npm dependencies they install

Evidence?!

No they don’t - developers just fly past installing whatever they need to make the damn thing work.

They don’t sit there thinking carefully about what each dependency means.

[–] saltcured 14 hours ago

I think the person above is stating that this is distinguishing characteristic of "good" developers. By extension, the ones you are referring to are not good.

[–] senordevnyc 8 hours ago

In other words, no true Scotsman…

[–] athorax 16 hours ago

I don't think this is the class of developer the article is referencing

[–] Buttons840 15 hours ago

We need to build systems where trust in the code is not needed.

I don't trust the JavaScript code I run in my browser, I don't need to.

A language with a strong enough type system and effects system could say, "this function updates the users preferences, and may not access the network, and may not access data from other users", and the compiler can ensure these constraints AT COMPILE TIME! Provably correct code.

[–] ang_cire 15 hours ago

Who knew it's possible to simply have perfect vuln-free code!

We security engineers are definitely shaking in our boots.

[–] Buttons840 14 hours ago

That's a strawman argument. I'm just saying that we need to find ways to wrangle the mountains of code coming out of LLMs into something we can trust, as best we can.

[–] nozzlegear 16 hours ago

Probably not the same people.

[–] viklove 16 hours ago

Where do you find these guys? I haven't worked on a project with more than 20 dependencies, and usually those dependencies have 0 subdependencies so they're quite easy to audit.

[–] user43928 16 hours ago

Then you probably haven't worked much with JS.

The Jest test runner alone has 250 dependencies in its latest version, and v25 had over 500.

[–] viklove 7 hours ago

Not sure how you operate, but I've never worked on any project in my 10+ years as a professionally employed JS dev where we've shipped Jest in our release.

I don't audit all the code I run (I don't think anyone does), but I do audit all the code I _release_. What's actually important to you?

[–] ang_cire 6 hours ago

You don't have to ship a dependency for it to be a vulnerability; the shai hulud worm was attacking dev machines and cicd environments to steal credentials. The deps you run are absolutely just as critical.

[–] xnorswap 16 hours ago

Are you including transient dependencies in that count?

[–] meindnoch 16 hours ago

*transitive

[–] viklove 16 hours ago

Yes 20 total dependencies including transients. If a lib has many subdependencies I take this as a red flag and try to avoid it.

[–] exe34 16 hours ago

No react then?

https://news.ycombinator.com/item?id=39019001

[–] viklove 7 hours ago

React has no dependencies: https://www.npmjs.com/package/react?activeTab=dependencies https://github.com/react/react/blob/main/package.json

If you read the first comment on your link, you'd see why you're wrong:

> That's not _React_, that's `create-react-app`

[–] devin 16 hours ago

The good devs I know avoid dependencies like the plague.