Cookie code compromise caper caught and crumbled NPM, the biz responsible for the Node Package Manager for JavaScript and Node.js, has caught a miscreant trying to tamper with web cookie modules on Wednesday and managed to exile the individual and associated code before significant harm was done. It's a good sign for the code registry which over the past few years has had to …
It depends. The more sensible web developer (i.e. one who has a clue and values any form of repeatability and determinism, also testing) will use a framework where the dependencies are either very well known and stable and version linked or are downloaded for local caching/deployment allowing the developer to only deploy a known, stable set of dependencies.
Many desktop developers, who admittedly are getting rarer now and are busy idiotically trying to build desktop type applications in a web browser (single page web applications - or multi-faceted disasters as they should be known), would link to arbitrary external libraries anyway. While the DLL hell of windows tended to reduce this somewhat, the lack of built-in library/component versioning in the OS made it inevitable that version mismatches would happen.
> "...could some cynical bastard explain it in terms of alcohol and sexual innuendo?"
Okay, I'll bite. ;-/
Node.js is a local, open source app that can be "extended" easily by strangers, and be made to do lots of bendy stuff. Being Javascript based, rafts of people can easily fiddle with it, and how!
The bigliest use-case (I believe) is as a local dev environment that handles serving, complying.. excuse me, compiling, and many other automated dev tasks.
I can't find a way to include alcohol in this discussion, but node doubt it's "in there" somewhere.
> I can't find a way to include alcohol in this discussion, but node doubt it's "in there" somewhere.
The alcohol comes in when you're left troubleshooting a node app that someone else cobbled together just before they fucked off, and seemingly whilst under the influence of something.
Yes. Look for a framework, any "modern" hugely inefficient one will do, where the standard practice of all developers is to download updates to every library every time the application is built. Genuine testing capacblity is pretty much zero as well as any genuine knowledge of the mash of dependencies the application somehow requires.
Just glad I've been doing this web programming lark for so long now that I've built my own framework (probably started before any of the current ones were even thought of). Anything I now add to it has to have a damn good reason for being there. If I need to add new functionality I investigate implementations elsewhere, rip them apart to see what makes them tick, so that I fully understand them before constructing my own (usually far smaller and less bloated) version.
Nodejs badly needs a standard library.
Trouble is node does not make money and npm corp. (Presumably) does.
Node was built on community engagement via npm so nobody wants a stdlib but still it cant be pit off forever.
Both Debian and Redhat provide curated libraries. That is a good start if you find npm a risk.
There are many, many code-repository services; and they can't all be doing security the same way. Some will inevitably be infected by bad actors. I'm worried that conventional ratings services, which depend on historical data, won't do anything to deal with an initial planting of infected code. It would be really nice if the repositories--the ones actually making an effort--would set out to create a community-driven effort to reach out to other repositories and establish a set of conventions, or even an actual standard, for securing code repositories. And, some basic questions need to be answered, such as: who moderates submitted code, how do you ensure accounts are legitimate and aren't compromised, what kind of scanning can be done to detect bad actors, etc.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
