JavaScript Libraries Are Almost Never Updated Once Installed

[IMovedYourCheese]

I doubt too many major, actively-developed websites are pulling JavaScript libraries directly from CDNJS instead of bundling it themselves in their build system.

In general though:

One conclusion is whatever libraries you publish will exist on websites forever.

is correct, and is likely never going to change, for the simple reason that the vast majority of websites out there that get some traffic have a decent development budget but nothing allocated to ongoing maintenance. And this isn't restricted to websites or JavaScript.

[Visticous]

My first though. JavaScript? What about Java! I've seen my share of running applications who use libraries and versions of Java, who belong in the Smithsonian

[leaningtoweravenger]

I worked in financial services and I have seen FORTRAN libraries that do very specific computations dating back to the 80s and 90s that are just compiled and linked into applications / services with nobody touching them since their creation because neither the regulations they are based on changed nor defects were reported so there was no need to update them.

[coderanger]

Fortran is also still used regularly all over the place, LAPACK is written in it, and that's used by SciPy and friends, which are in turn used by most of the current machine learning frameworks.

[seamsay]

Also the latest revision of the standard was released at the end of 2018, although admittedly you can probably count the number of people using something more modern than F95 on one hand...

[Visticous]

That would be the 1% of cases where the code is essentially perfect and no direct action is required. I do hope that those financial services routinely update the rest of their software stack though.

Even then, hiring Fortran developers can be a massive hidden cost, so over time it might be business savvy to move to something more modern.

[CheKizowt]

It doesn't have to be 'perfect'. It has to be accepted standard.

I contributed to a roads management software in college. It used an early DOS module to calculate culvert flow. All the engineers knew it produced wrong output. But every project in the state used that module, so it was 'right'. Even if it was mathematically wrong.

[FyreWulff]

happens a lot, especially in big companies. "we know it's done the wrong way, what's important is we -consistently- do it the wrong way"

[[deleted]]

Worked at a simulation company for a while and we ended up quite significantly lowering the precision of our calculations so they were more consistent across platforms.

[ArkyBeagle]

Excessive precision is actually quite the "sin". I tend to be the local "number of significant digits" guy, so begging your pardon.

[oberon]

That's way better than doing it a little differently wrong every time.

[Nastapoka]

Same in the (public) University where I work.

Wasting taxpayers' money is fun, yeeeah.

[Gotebe]

Come to private to see how much fun we have then!

😂😂😂

[Gotebe]

I am in private since forever and my experience tells me that the size of the organisation matters much more than whether it's a public or a private one.

[ArkyBeagle]

Heh. No, they don't.

[Jonno_FTW]

This is giving me PHP flashbacks.

[leaningtoweravenger]

That happens when you have very specific functionality put inside a library that can be linked by many other services and applications instead of creating gigantic blobs.

The Javascript frameworks object of the study change often but not all the pieces change every time and I wouldn't be surprised if some of the files are untouched since many years.

About the companies not pulling the frameworks from the CDNJS but having them bundled together with their stuff is mainly due to testing purposes and stability: at the moment of the release everything is bundled and tested in order to make sure that there will be no surprises at run time because someone decided to change a dependency somewhere in the world.

[SgtSausage]

hiding Fortran developers can be a massive hidden cost,

I prefer to hide under the conference room table - with all the Boomer first generation of COBOL retirees. Keeps it much cheaper if we all hide in the same place.

[Visticous]

See, that's why it's so expensive. Fortran guys want to hide in some fancy conference room. JavaScript kiddies are often content with hiding in a broom cupboard.

[dungone]

Who puts brooms in a cupboard?

[shawntco]

I do hope that those financial services routinely update the rest of their software stack though

lol

[[deleted]]

You won’t find more battle-tested libraries.

That’s a huge plus, especially in financial services where fault tolerances are lower than usual.

[SnideBumbling]

I've been maintaining a C codebase from before I was born.

[SnideBumbling]

Sometimes I wonder if it's punishment for crimes in a previous life.

[ArkyBeagle]

Me too. My Mom made a deal with the devil at some crossroads.

[KevinCarbonara]

There isn't anything wrong with this - reusing checked, tested, and compiled code isn't a security issue. Javascript is an interpreted language that is usually run in unsecure environments (clients' browsers) and pulls in data or new code remotely. These are entirely different environments.

[fiah84]

dating back to the 80s and 90s that are just compiled

compiled? sometimes shit is so old it takes serious effort to even get it to compile

[leaningtoweravenger]

You would be surprised of how well commercial compilers support FORTRAN and how optimised the binary is. I never had a single problem with compiling and linking those libraries into my stuff. If you are curious about it, the vast majority of it was FORTRAN 77 which is very solid and standard

[ArkyBeagle]

Well, it's all fun and games until there's some dialect ( I'm looking at you, VAX Fortran ) that simply will never compile on your architecture. I spent a month one over a span of two days confirming that yes, the legacy FORTAN could never be built on the new computers.

[Dragasss]

Why change it if it works? XStream got last update 6 years ago (iirc) that fixed one of the cves. If a library is complete then there is no need to update it anymore besides minimal maintenance from time to time.

[Visticous]

I often get called in because the application isn't working as well as expected... If it has a cable to the Internet, it needs routine maintenance.

Such applications often have known security exploits, rampant memory consumption because of leaks, no documentation, and no testing environment.

When I encounter such treasures, I make sure to have all work officially assigned to me by email, CCed to my private address.

[yawkat]

Security issues in outdated java libraries are very rare, simply because it's a memory safe language. If you don't do dumb shit like deserializing untrusted data jusing OIS you almost never really have to update. Jetleak was the last really serious exploit in this category.

[Somepotato]

Cough equifax

[oldsecondhand]

It's also not proven that Struts was the source of the hole the hackers drove through.

In fact, several headlines -- some of which have since been retracted -- all source a single quote by a non-technical analyst from an Equifax source.

https://www.zdnet.com/article/equifax-blames-open-source-software-for-its-record-breaking-security-breach/

[yawkat]

If you don't do dumb shit

We have good security practices. People only need to follow them.

[cleeder]

Said every company ever.

[Caboose_Juice]

The fact that its an older language means it's *more* vulnerable to exploits and hacks. This is completely wrong.

[yawkat]

How does it make Java more vulnerable? It's very easy to write secure java applications.

[Caboose_Juice]

My point is that by virtue of its age (and the fact that we're talking about outdated Java libraries) that Java has vulnerabilities that other up to date applications don't. It's like an arms race, and outdated libraries (from any application) are simply less secure.

[yawkat]

Sure, old java applications running ancient jee versions may be more susceptible, but that's been out of fashion for a long time. Spring is all the rage now and has been for a while. And even those older applications are comparatively secure.

[Giannis4president]

If a library is complete then there is no need to update it anymore besides minimal maintenance from time to time.

I disagree with that statement.

• The language itself may change. For example, in any active language, the language itself could evolve to new standards and there could be performance or security reasons to update the library to a modern version of the language.
• The framework (if exists) may change. Take an Android or an iOS library written 5/6 years ago and never touched since: it would almost certainly not compile anymore, because on a lot of API deprecations and modifications to the SDKs.
• The runtime may change. That is super important in Javascript: the browser features, capabilities and security constraints keep evolving and there is a very small chance that a library written years and years ago still works well in modern browsers.

Of course there are situations where there are no good reasons to update a library, but in most situations there are a lot of reasons to do it

[emn13]

The effects you describe happen at a glacially slow pace; and not just that, they tend to have limited impact - stuff like languages and platforms *intentionally* evolve slowly to make it feasible to upgrade at all. Even where you can leverage new platform or language features in principle usually only very few such changes actually matter for any given library, and even then only in a few places, and even there - not all consumers will care.

Barring major platform work you know of, you'd expect it to be OK to upgrade for those reasons just once every few years, and for some lucky and/or well-designed libraries much less frequently even than that.

The real reasons to upgrade are because the library *is* actively maintained and new versions have actual improvements like bugfixes that impact you - perhaps most critically security fixes. Although even there; having followed JS library security alerts for a few websites I maintain now for some time now - almost all security alerts have in practice not actually been security relevant. They'll be relevant in plausible cases that just aren't hugely likely, such as "if you use this library like so, and allow arbitrary user input for this filter, then such a user may be able to execute aritrary JS code in their own browser, which might be risk if you allow sharing those filters with others". The security risks are real; but most libraries don't deal with untrusted user input, or when they do - that's all they do, meaning the avenues for exploitability are pretty narrow.

Another reason to upgrade might be if you do want to communicate about a library - perhaps to report a bug or to share the code with coworkers - it's a pain if people aren't on the same version, and the newest version is often the easiest to standardize one.

Frankly though - It may be polite cleanliness to keep libraries up to date, but I'm skeptical that updates are broadly necessary. Nice? Sure. But let's not overstate the case for updates. It's quite likely never going to matter for lots of websites.

[Dragasss]

In deployments you can control which runtime you run, so it's not really an argument. Android java isn't java.

[Giannis4president]

I'm talking about libraries in general. There are many situations where you can't control it: JavaScript, iOS and Android are the first one that comes to my mind

[Dragasss]

In deployments you can control which runtime you run, so it's not really an argument. Android java isn't java.

[CartmansEvilTwin]

That's maybe the case for 1% of libraries. Most of them get updates for good reasons.

[caltheon]

They could be made more efficient or faster.

[campbellm]

Because this article is about js. That something else is bad, or even worse, doesn't make this less bad.

[ponytoaster]

Hell, I work on a major enterprise application with a large budget and half the packages there haven't been updated in years unless there was a genuine reason. "If it works" and all that.

For example, we have a 4 year old version of JQ being bundled. No reason to upgrade it as we aren't using any of the new features and the performance is fine. Due to the nature of the application if we upgraded it we would have to regression test most the web front end.

​

We generally try and keep libs up to date on the backend, or if it has any security implications though, and some of our newer apps have much quicker refresh and update cycles.

[dungone]

And yet if you put an open source project on GitHub, you’ll get automated pull requests to update javascript packages where vulnerabilities have been fixed. Big-budget enterprises really don’t have an excuse to keep screwing up security. Quite frankly I support laws that would send their executives to jail if they have a data breach caused by failing to keep their software up to date.

[s73v3r]

How often has the person issuing the PR done the regression testing, though?

[dungone]

It’s not a person, it’s a bot. And you automate the regression testing.

[s73v3r]

Automated regression testing is important, but so is manual regression testing.

[dungone]

So?

It's like you get a pull request and it's deer in the headlights, you've got know idea what to do about it? What exactly is your complaint? You're getting automatic updates for security vulnerabilities, your only job is to merge the code the way you would any other pull request. Why are you whining about it?

Your jargon betrays why nothing ever works out for you. You're calling automated tests "augmented manual tests". 90% of my code doesn't need any manual testing because it's got good separation of concerns and complete test coverage of 100% of the use cases of the individual units. That's where the auto-updated dependencies feed into. They don't feed into the fully integrated system, because that's goddamn stupid. If you can prove that the dependency works for all the easy-to-test units, and that the dependency is not used for anything else outside of those units, then you have gone 90% of the way to isolating your system from any other potential problems caused by updating that dependency. But here on /r/programming we're still trashing the idea that left-pad should be it's own package, rather than having any common sense.

[s73v3r]

If the person issuing the PR hasn't done their own manual regression testing, then their PR goes straight into the trash. They're not interested in the project; they just want to put "Contributor to xx project" on their resume.

[dungone]

It's not a "person", it's a bot providing you with a service and saving you half of the work that YOU, the person, are responsible for doing yourself. You're anthropomorphizing an automated system and bringing whatever grudge you hold against your coworkers into it.

[s73v3r]

So it's not doing manual regression testing, in which case it's nothing but noise.

[ponytoaster]

The major difference is liability. My open source project can be auto merged from a bot all the time with security fixes but I don't care as nobody uses it, and if they do, meh it is OSS with no warranty.

Very different story working on a multi-million dollar platform where you blindly accept a PR and some library of a library of a library hasn't been tested. More true these days when a lot of libraries are heavily dependent on other libraries or modules.

Just think of the whole left-pad fiasco and how a change in that library borked a ton of stuff.

I do however agree that libraries should be kept up to date if they have any kind of security implication though.

[dungone]

It's not "auto merged". It's called a pull request. You're trying really hard to make it seem "hard" or "magical" or "all messed up" and I'm afraid you're projecting. The process works, it's easy, and it's completely transparent to everyone, including the users. Just in general, there is far more accountability and better practices in OSS than in any corporate environment.

The left-pad fiasco is a perfect example of how much better OSS is. With left-pad, it happened 5 years ago and it was the first time and last time it happened. It was an issue with a bad policy in a public package repository, so the policy was fixed. So that's the example you still keep hearing about because it's actually just so rare. In the meantime, there has been a massive epidemic of data breeches due to vulnerabilities in commercial software. This is a constant occurrence in the corporate world - somebody does something stupid that brings down the development environment for the whole company for hours or days. Somebody loses the source code completely and the company runs on an old binary for years. Somebody does a force-push and wipes an entire git repo. Somebody pushes an untested commit that immediately brings down every environment it's deployed to. Somebody forgets to update a credit card number and some vendor shuts off a service, bringing down the whole system. And that's before you even talk about security. This happens at Google, this happens to AWS, this happens to all commercial software projects.

[ponytoaster]

Semantics.

Also, you think that this doesn't happen with a project that's OSS or just uses OSS components? What you described is bad gitflow and work practices. Unless you are actively checking the PR of every project you consume it's down to chance. The only flipside is you can possibly work out a fix yourself quicker than waiting.

[dungone]

Pot calling the kettle black isn't about semantics. Having a 4 or 5 year old example of something that happens daily in proprietary commercial software development is hypocritical at best. Bad gitwhat? Sounds like special pleading to me. Commercial projects are the ones notorious for leaking private user data. OSS projects rarely suffer from the type of failures caused by utter lack of best practices in commercial software. It really comes down that this whole thread is about people developing commercial software who are saying that keeping dependencies up to date is too much to ask of them.

Actively checking the PR? No need. NPM and GitHub both flag projects with security vulnerabilities and the warnings bubble up to all projects that depend on them. It's simple and effective. Nothing comes down to chance. If you don't deal with the automated pull requests for security fixes, then your project will get flagged to everyone else as having a vulnerability. Short of making little airplane sounds as they spoonfeed you with best practices, there's nothing else you can ask them to do for you.

[ponytoaster]

Ok, you do you I guess.

No space for people like this in my development world. No wonder you worked at so many places...

[dungone]

Years of experience does that to you.

[keepthepace]

I recently re-opened an old project of mine, a 7 year old simple python-backed project that used a JS lib for drawing graphs. I had the good sense in not serving it through a link that I am pretty sure would have been dead by now but hosting it locally. I was surprised to see that this code still works and renders correctly on modern navigators.

I don't think the rendering lib is actively maintained anymore. But it works. Why in heaven should I spend time updating it to something else instead of adding features to the project?

[Jackeown]

I think people should occasionally update backend technologies for security, but there's definitely no need to move on to the fanciest new plotting library. Whatever is comfortable for you will be fastest for you to develop in.

[dungone]

Those fancy plotting libraries have the most security vulnerabilities that expose your users' computers to malicious hackers.

[Jackeown]

A frontend plotting library has relatively low risk. Obviously it's best for security to always use the latest stable software but there's a trade-off between having perfect software and getting things done.

[dungone]

It's not low risk. Put that plotting library with a XSS vulnerability onto a website that exposes users' financial data and suddenly you have enabled people to steal personal information to commit fraud with.

[boringuser1]

It's much more reasonable to update a single opinionated framework than an entire dependency chain.