Warning: JavaScript registry npm vulnerable to 'manifest confusion' abuse The npm Public Registry, a database of JavaScript packages, fails to compare npm package manifest data with the archive of files that data describes, creating an opportunity for the installation and execution of malicious files. In a blog post published on Tuesday, Darcy Clarke, who was staff engineering manager for the npm …
Your POC is unrelated to this new discovery. Your library defines a postinstall script & showcases the fact package managers will happily execute that (which is indeed a feature of those clients). The issue raised here concerns the fact package metadata & a package's contents can/do differ causing a level of inconsistency/confusion that is dangerous for the ecosystem. Package managers have executed lifecycle scripts forever & git repositories specifically have lifecycle scripts executed because they need to be "built" before they can be consumed like all other "packages" (ex. prepack/prepare scripts will be run even when you pass --ignore-scripts to npm install - which is a documented behavior, no matter how you feel about it). The serious cause for concern here is not knowing which defined scripts/dependencies/licensing/version/name etc. to use when referencing/installing a dependency (because these have not been validated/verified to match in the registry itself).
For it's proper use cases - which are not CPU bound - it's far less overhead than shoehorning parallel processing to solve a problem where only concurrency is needed.
A system is said to be concurrent if it can support two or more actions in progress at the same time. A system is said to be parallel if it can support two or more actions executing simultaneously.
Note: It seems that older usage of the term "concurrency" didn't seem to distinguish in the way the above definition does - it was used to refer to two of more parallel actions from a single thread.
So the difference between concurrent and parallel is the same as the difference between "in progress at the same time" and "executing simultaneously".
Hmm. I have to assume that there are particular definitions of "progress", "execution", "at the same time" and "simultaneously" that I'm missing here because I reckon the average English speaker would reckon there was no difference at all here.
That's right.
"executing simultaneously"
- For example the CPUs on a computer are solving a problem that is divided between CPUs acting in concert and in parallel where the CPU's are near 100% usage at all times. Generally this is done by spinning up one thread per task, and writing the code with mutexes and joins to keep the CPU's busy but not overloaded, with the logic to glue it all together.
"in progress at the same time"
- For example a web page is displaying and user is clicking, which triggers events. Some of those events trigger page fetches from external servers, or database requests, the responses to which are also events. The CPU load is small, maybe one CPU is enough. The program contains the state logic for handling all the events and generating requests, and it is run in a single thread, which has an event manager built into the language. From a logical perspective, the state logic may be described as multiple tasks running concurrently
- For example one server thread is handling a thousand user connections using concurrent programming, so each connection is a task in progress. This is more effective than spinning up 1000 threads, one per user.
You could just as well say that human and the external servers were "executing simultaneously" and that would not be factually wrong. The terminology is a way to distinguish between thread based (parallel) and event based (concurrent) programming.
cracked: For it's proper use cases - which are not CPU bound - it's far less overhead than shoehorning parallel processing to solve a problem where only concurrency is needed.
cow: What are those use cases ? Serving files with basically no actual logic in your own code ? If so why bother with Node then ?
> it's far less overhead than shoehorning parallel processing
There are 2 kinds of overhead: In code, and in the runtime.
Regarding code, I think I don't have to argue why
go request_handler.ServeHTTP(w, request)
or a similar call to a worker pool manager is simpler than the async/await/.then().then().then().then().then()/callback-hell. The code is linear, easy to read, easy to reason about, easy to follow, easy to write.
Then there is the runtime overhead. Outside of really naive implementations, which birth actual OS threads the moment they are needed, instead of using greenlets or a worker pool, the runtime overhead barely exists any more.
I remember when I got "asynchronous programming" explained to me the first time. I remember that I asked the lecturer: "So, basically, this is cooperative multitasking in userspace...the same idea that OS development gave up on in the early 90s, yes?"
Plus, I don't need to have an event loop running in userspace. Instead I can use the far more powerful scheduler the OS has out of the bix to do that for me.
Bonus 1: I get parallelism and concurrency in one package. The system handles concurrent, IO-bound tasks the exact same way, and with the exact same code, as it does CPU-bound tasks.
Bonus 2: The system scales equally well horizintally as it does vertically.
Multithreaded JavaScript, what could possibly go wrong?
How about Web pages slamming your 16 core, 32 thread CPU into 100% usage - and I'm just referring to the usual inept Web coding that is displaying another one of those bleeping auto-scrolling image backdrops!
Gosh, if only we could limit the resources that an individual tab / page / domain / window takes up in the browser to ensure it only ever gets a fair share of what the user wants it to have.
It's almost like that would solve all such problems and show which sites truly are taking the mick.
I can remember when I could also stop ALL moving images and plugins on a page so nothing showed me distracting moving images unless I clicked on them specifically. Those days are gone too.
Browsers need to start limiting resources, because there's basically nothing stopping someone running Quake or a Bitcoin Miner in your browser when you visit their website, and they can easily do so silently and without output.
WASM etc. is incredible technology, but it needs resource limits. I can literally compile one of my old SDL / OpenGL games with Emscripten and run it in a browser unmodified. If I can do that, then someone can do far worse with just a simple Javascript include on an seemingly innocuous webpage if they want.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
