A single Node of failure [LWN.net]

A single Node of failure

Posted Mar 31, 2016 17:51 UTC (Thu) by MattJD (subscriber, #91390)
In reply to: A single Node of failure by Sesse
Parent article: A single Node of failure

Yes, that does let you have multiple ABIs (the same thing sonames do).

I don't see how either version deals with security fixes across multiple ABIs. With sonames, I still need to upgrade each of the ABI versions, same as with npm. Assuming both use the proper versioning scheme (semantic versioning for node), I can upgrade all the packages to have that new version.

Now, wiht npm I may get stuck with a large dependency tree that I can't audit and may have a vulnerability I can't easily upgrade, no question. In theory if everyone maintains there package it works out. In practise, running `npm --depth 999 outdated` on my one project using node for preprocessing makes me want to never run node over untrusted data.

to post comments

A single Node of failure

Posted Mar 31, 2016 19:38 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> Yes, that does let you have multiple ABIs (the same thing sonames do). ... I don't see how either version deals with security fixes across multiple ABIs. With sonames, I still need to upgrade each of the ABI versions, same as with npm.

Sonames don't address that problem, but symbol versioning does. That is how you can have a single version of libc that remains ABI-compatible with ancient applications and libraries, despite changes in the libc ABI over time. The backward-compatible symbol is generally a shim over the new ABI rather than a separate implementation, which helps keep the security fixes confined to one place. (Unfortunately, there aren't many other projects besides libc willing to expend the necessary effort to version their symbols.)

A single Node of failure

Posted Mar 31, 2016 19:45 UTC (Thu) by Sesse (subscriber, #53779) [Link] (2 responses)

The point isn't that it allows you to have multiple ABIs, it allows you to declare an ABI in the first place.

A single Node of failure

Posted Mar 31, 2016 19:58 UTC (Thu) by MattJD (subscriber, #91390) [Link] (1 responses)

Then npm has the same functionality through semantic versioning (Semver). The major number would then be similar to the soname, incremented when the ABI breaks. Semver only works when everyone follows it, and is in general a more loose policy then soname IMHO. But we have C libraries that don't follow the rules either, so it isn't universal.

Unless you mean Node developers have less standards then C developers on maintaining compatibility? That becomes a function on who the developer is. Anyone (C or Node) can accidentally (or on purpose) change their ABI and break downstream users (even the kernel will do that occasionally, they just have a very strict policy on what happens). Node developers may in general be worse (I don't have statistics, so I can't say either way), but npm does provide tools to deal with it. It isn't a tooling problem, but a people problem that affects all languages.

Anyways, I was originally responding to your comment about how they deal with differing module dependencies (that they do indeed pull in multiple version, and it can actually work in practise). And you can fix a security issue in multiple versions. Whether people actually do that is a whole other point.

A single Node of failure

Posted Mar 31, 2016 20:11 UTC (Thu) by Sesse (subscriber, #53779) [Link]

Sure, semantic versioning is a nice policy, but it's not “law” the same way C sonames are, and it needs to be pretty much universal for people to depend on it. (Also, infrastructure choices matter here; it _is_ technically possible for a C binary to depend on version 1.6.7 of a given library instead of ABI version 1, but you have to go out of your way to do it, so people don't.)

I'm sure there _are_ C libraries out there that don't care about sonames, but they're so rare I can't name a single one offhand. (And if you get it wrong out of ignorance, your Linux distribution maintainer will basically hit you with the cluebat and/or bump it for you whenever you break, plus usually take care of reverse dependencies so that the distribution as a whole only needs to carry one or at most a few versions of every module.)

And yes, it is my impression (although obviously somewhat subjective) that programmers of almost all newer languages are much worse than the average C programmer in maintaining backwards compatibility.