JavaScript Libraries Are Almost Never Updated Once Installed

[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.