Modern Software Recapitulates Greek Mythology

The Titan Kronos (Saturn) ate his children.

Modern software developers are doing the same.

Kronos was afraid being overthrown by his sons. So he eliminated them.

Many modern software developers seem hell bent on devouring the past. But they have less reason to do so than did Kronos.

Few of us remember mainframe computers (although they still exist). During their heyday from the 1950s through the 1990s the unbreakable rule was “backwards compatibility”. It was a great sin to change an API (Application Programming Interface) to an operating system or library in a way that could cause existing software to go awry or fail.

This honoring of the past worked: There are many mainframe financial applications, written (often in the 1959 language Cobol) between 1960 and 1990 that are still in heavy use today.

However, today the concept of backward compatibility is no longer universally respected. Today many software developers and providers do not bother to pause and think of the consequences before racing forward and breaking with the past.

We are forcing people to fix what is not broken. We are forcing people to rewrite working code or abandon working products simply because someone, somewhere has decided to cancel existing, working software foundations, often for no reason more substantial than that those foundations are older and perhaps less “elegant” in the eyes of some.

Perhaps the worst case is the near Vandalism of Adobe Flash. Yes, Flash became a monstrosity, a kitchen sink filled with everybody’s favorite idea, and more security holes than one could shake a stick at.

Yes, Flash deserved to be stopped in its tracks.

But stopping is not the same as destroying.

Rather than patching security holes or wrapping the whole thing with “Danger, Danger, Experts Only!!. Use With Caution!!” warnings. Adobe and operating system updates actually disabled or removed Flash.

Flash was useful, there was (and remains) a mountain of legacy software that depended on it. For instance the management interface for the once popular Cisco UC320W (a small office phone system) was entirely in Flash. Without Flash those still usable PBX systems become e-waste. And there is a lot of old visual, pre-YouTube, content on the web that has now become largely non-viewable.

We see something similar happening with security and message digest algorithms. Every now and then a flaw is found or a method is found to break an encryption method or message digest, or it has become potentially practical to use brute-force horsepower to break the key or modify content without affecting the digest. As a result security algorithms are “deprecated” and removed from libraries. The result is that a device that previously was able to establish a connection can no longer do so because the other end no longer supports a compatible algorithm. For personal computers and servers this may be repairable via software updates. But for embedded systems or Internet of Things devices, this may be impossible.

It is as if we ourselves had intentionally set fire to the Library at Alexandria; we burned our history.

We are destroying the compatibility that permits end-to-end communications across the Internet.

It’s not just Flash, it is Python 2.x. Python 3 is arguably better and there are some (sometimes) helpful conversion utilities. But there remain millions upon millions of lines of running Python 2.x code. Fortunately Python 2.x can, for now, still be loaded onto many platforms. But the library/modules are starting to disappear. For instance the pyyaml package now has to be found and compiled from source. That ability to build from source is a credit to open source, but it is a real nuisance, especially when the toolchain needed for the rebuild has itself been “updated” so that it can no longer build the old code. Moreover, those source code repositories have a habit of quietly vanishing as their maintainers get bored (or themselves vanish).

What should be done?

In the case of a “deprecated” security algorithms, the people who are maintaining libraries, such as OpenSSL, should not be so quick to remove and disable that algorithm. They should issue warnings but allow the option of continuing use of that algorithm. Perhaps it would be appropriate to deny use in servers that hold sensitive materials, but the choice whether to allow or deny ought to be made in the context of the actual risk not some industry-wide blanket ban.

In the case of Python 2 and other computer language systems (including the supporting libraries), the code, and packages built from that code, could be frozen but still be provided from the standard or extended repositories for the various operating system distributions.

What about APIs? We’ve long seen how API’s can evolve with new methods with new parameters but with the old remaining in place, usable. IBM and Microsoft have long done this.

Basically we need to stop sabotaging existing code that is shipped and installed in fielded systems worldwide. Leave it alone. Forcing software developers to invest man years of effort to rewrite that code avails us nothing.