this post was submitted on 06 Aug 2023
145 points (97.4% liked)

Programming

17509 readers
8 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
 

Steps to reproduce:

  1. Start a Node project that uses at least five direct dependencies.
  2. Leave it alone for three months.
  3. Come back and try to install it.

Something in the dependency tree will yell at you that it is deprecated or discontinued. That thing will not be one of your direct dependencies.

NPM will tell you that you have at least one security vulnerability. At least one of the vulnerabilities will be impossible to trigger in your particular application. At least one of the vulnerabilities will not be able to be fixed by updating the versions of your dependencies.

(I am sure I exaggerate, but not by much!)

Why is it like this? How many hours per week does this running-to-stay-in-place cost the average Node project? How many hours per week of developer time is the minimum viable Node project actually supposed to have available?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 30 points 1 year ago* (last edited 1 year ago) (3 children)

If you set the versions of your dependencies in the package.json file, you’ll reinstall exactly the same ones.

You may get new vulnerability warnings popping up, but what is the issue here ? You’d rather not be aware that a vulnerability has been found since your last development ?

If you are not happy with others modules, dev your own and no one will let you know about security issues 😝

[–] [email protected] 11 points 1 year ago (2 children)

I'm struggling to understand how there can be so many security flaws, even in things that don't seem to matter for security. I think the bar for a security problem might be too low; a lot of these look like footguns that could give my package a security hole, rather than genuine security flaws in the packages they are reported on.

Here's a progress bar package with a "high" security vulnerability because it contains an internal utility that merges objects and doesn't stop you writing to the prototype. Did the progress bar package ever promise to provide an object merge function that was safe to use on untrusted user input?

Here's a notification UI element that bills using HTML in your notification messages as a feature. It has a "medium" level "XSS" security vulnerability where the message parameter is not sanitized to remove HTML. A CVE was issued for this.

Here's an arbitrary code execution vulnerability in sqlite3! High severity! The bug is that, if you tell sqlite3 to substitute an object into an SQL statement, it will run the ToString() method on the object. If an evil hacker has broken into your lead developer's house and written a malicious ToString() method into one of the classes of object you use as a database query parameter, then that code would run! The fix here was, instead of letting the normal Javascript stringification rules apply, to hardcode all objects to be inserted into the database as "[object Object]", because surely that is what the programmer meant to store.

[–] [email protected] 8 points 1 year ago (1 children)

You don't need to do anything when you get a security advisory if you're not impacted or the risk is acceptable. They're just there to advise you.

[–] atheken 8 points 1 year ago

The problem is that when you are alerted for trivial/non-actionable stuff it contributes to “alert-fatigue” and you just start ignoring all of the alerts.

As far as I’m aware, there’s also no way to triage an alert from an install other than to upgrade the offending package, which means you can’t really discriminate on the basis of “acceptable risk”

[–] [email protected] 4 points 1 year ago (2 children)

You’d rather not be aware that a vulnerability has been found since your last development ?

I'd rather develop with dependencies that don't have so many vulnerabilities.

[–] [email protected] 13 points 1 year ago (1 children)

Yeah we all wanna do that, but nobody writes perfect code.

[–] [email protected] 5 points 1 year ago* (last edited 1 year ago)

That's why people came up with defensive programming and functional correctness.

Just seems to be difficult for the webdev industry. Seems easier to push fixes from time to time.

[–] [email protected] 9 points 1 year ago (1 children)

Then you're in the wrong industry...

[–] [email protected] 3 points 1 year ago

If you mean web development, you're right.

If you mean computer science, then I'd say that webdevs have little in common with the industry that came up with stuff like ADA or functional correctness.

[–] [email protected] 2 points 1 year ago (1 children)

If you set the versions of your dependencies in the package.json file

Or if you leave that alone, and update your package-lick.json so can install exact dependencies with npm ci