Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps

UX / User Research
#1

Bonjour,

After reading and checking the sources, it looks like this was a deliberate act of sabotage by the developer of a widely used Free Software library. I’m inserting this here because, to my knowledge, this is the first occurrence at this scale. It’s not the first time a developer inserts something malicious in their code though, of course :wink:

This is only tangentially related to the federation of forges and I don’t see how it would have happened differently in a federated universe. The solution to the problem is trivial and has been around for decades: packager teams bundle software and promise to deliver a set that is well maintained. That’s what Debian GNU/Linux does for operating systems. It introduces more friction in the development cycle but it is worth it.

Thoughts?

#2

Here are Hacker News discussions on the topic:

Would like to highlight that what happened here is very interesting from the perspective of #socialcoding too. One of the challenges to tackle.

I agree with the solution you mention. But it is only trivial in theory, and mostly in that the solution can be mentioned in a single sentence. In the case of Linux there are a unique set of circumstances that led to such a strong ecosystem. There’s also a concrete goal: Packaging an OS environment and apps. Which is a bit different than validating libs for general-purpose use anywhere.

What we don’t know is how many OS’es fail to gain traction because they cannot get such a vibrant packaging ecosystem in place, while maybe they are much more innovative and potentially more user-friendly.

Well, that depends. Not in a federated universe that can only do Microblogging well. But forge federation on the other hand provides foundational building blocks to build a rich ecosystem on top of [cross-referencing “United Software Development” where we first started to discuss this].

A dev’s long-term maintenance is still part of the project development lifecycle. And the maintainer burning out, getting mental issues, or become otherwise unavailable or untrustworthy (e.g. selling their project to an ad-tech or malware company) is a risk that must be managed. A challenge to deal with.

Being part of the lifecycle I think of FSDL. And on the ecosystem side I see a fedi-supported crowdsourced community that dedicates to reviewing libraries as soon as a new release is checked into a federated forge. Together offering a service that you include in your project and that gives you a label and metrics report on the health of your dependency trees.

#3

I don’t see how it is different. People pulling from development repositories are taking a risk and sometime they pay the price. People who want to be safe do not do that and rely on third party distributions with a commitment to provide stability and security instead. It actually is that simple. It’s even been the business model of Red Hat for the past 25 years or so.

#4

It is different in the incentives. People want to be part of Debian GNU/Linux because that’s a concrete end deliverable. I don’t know what their motivations are. But lacking an end deliverable will be a change. (the end deliverable is a validated release, and on that you can attach incentives like showing who validated it, or something)

#5

I don’t understand? If someone needs security and stability they need a distribution that provides that kind of guarantee. It is not a matter of incentive or lack of incentive.

#6

It is probably not worth arguing about. I said it is a bit different. The users of libs, those creating a high-level NodeJS project where their 10 dependencies drag in 200 gazillion other dependencies. They are not going to review those gazillions. Other people should, and there’d be numerous releases every day to review. Working on Linux distributions has incentives. Pride, reputation, showing it on your CV are among them, probably a lot more reasons. This all needs to be built in a different context, where a loose collection of verified libs is the output.

#7

And if they get those 10 dependencies from a source where those dependencies are not reviewed either, they are taking a risk. If they want to mitigate this risk they need take those dependencies elsewhere or change their dependencies if they are not packaged by anyone. Again this is a very simple proposition.

The notion that a software package can be stable and secure when nobody explicitly commits to delivering these qualities is like believing in magic :slight_smile:

#8

Sure, the proposition is simple, the practical solution isn’t. Unfortunately in NodeJS world for instance people believe in magic :wink:
Most NodeJS apps are houses of cards.

1 Like
#9

The practical solution is to spend money and work to ensure stability and security, instead of not. How simpler can it be?

#10

Interesting way of gauging the trustworthiness of Free Software projects using contributor reputation and reputation of other projects that the contributors have participated in:

Reddit via libreddit(underlying reddit link)

#11

On this topic:

https://enough.community/blog/2020/08/14/free-software-malwares-viruses/

The reddit article discusses Free Software in general and the Bitwarden server which is not Free Software. I would not trust even the most praised/audited proprietary software when it comes to security.

I would not trust a random Free Software project either :slight_smile:

1 Like