faker.js

[adityasaky]

https://www.reddit.com/r/javascript/comments/rwdu3h/fakerjs_gets_erased/

https://twitter.com/marak/status/1479200803948830724

[adityasaky]

Also, same developer, colors.js has some interesting activity: https://github.com/Marak/colors.js/commit/074a0f8ed0c31c35d13d28632bd8a049ff136fb6

[adityasaky]

Possibly related: https://web.archive.org/web/20201226190222/https://github.com/Marak/faker.js/issues/1046

[kpcyrd]

I think in this case it might be interesting to clarify "what's a dependency" and "what's unavailable" in "[Incidents where things] were impacted due to dependencies being unavailable". Other than the other incidents tracked so far, the previous 1.4.0 version was still available, so this wasn't about unavailability of code but about unavailability of a human to fix a regression introduced in 1.4.44-liberty-2.

Maintainer unavailability is fairly common considering that a large part of open source is built on the goodwill of altruistic volunteers, the question here should be "Why did an SBOM not guarantee continued availability?" and if the answers is "We relied on being able to generate/resolve an SBOM on the fly" the next question should be "Can we reasonably expect unsupervised SBOM generation/resolution in this case [without curation by a downstream maintainer]?".

A downstream maintainer could be either a Linux distribution like Debian (who's copy of colors.js was unaffected), or the developers who have added the dependency to their project and who're then responsible to maintain each of their package-lock.json SBOMs. This doesn't solve the dependence on "human availability" though, it just shifts it.

[adityasaky]

@kpcyrd sorry for the delay, I was quite sick!

I think those are some good points. I was wondering if faker.js was a candidate here more than colors.js because its repo was zeroed out, with just https://github.com/Marak/faker.js/commit/2c4f82f0af819e2bdb2623f0e429754f38c2c2f2 remaining. colors.js was included because it was related to the situation with the maintainer.

I see your points in terms of availability to consumers. NPM's policies seem to have worked, ensuring prior "good" versions are accessible Some people downloaded version 6.6.6, and have hopefully now switched over to more rigorous version rules, I'm guessing they were just pulling in latest. It'll be interesting to see it's 7-day download numbers every week, for some time, and see if it goes down. Might also give us an indication of inactive consumers.

However, I do think it's worth recording because while we may well expect an open source project to halt because of lack of maintainer bandwidth, it's quite rare to have the primary source be entirely zeroed out. That actively harms any continuation possibilities, though as it happens with this project and ecosystem (source is used directly), the community could rally and keep it going. Do you think there's scope creep here with respect to this repo?

Maintainer unavailability is fairly common considering that a large part of open source is built on the goodwill of altruistic volunteers, the question here should be "Why did an SBOM not guarantee continued availability?" and if the answers is "We relied on being able to generate/resolve an SBOM on the fly" the next question should be "Can we reasonably expect unsupervised SBOM generation/resolution in this case [without curation by a downstream maintainer]?".

I think I understand what you're getting at here. My personal stance on the matter is that either curation is absolutely needed, or the party you're pulling from has some trust (in the social sense--I feel comfortable that NPM's servers are going to be mostly available) and the right policies (immutability, non removal of a version). I'm reminded of the libisl issue, which is continuing to cause package build failures on the NYU rebuilder.