As administrators we have a responsibility to vet. Even if it's to "deligate" the vetting, we have to vet the deligate.

Npm is a hot mess, and most people get that now.

Galaxy / puppetforge / helm stuff ? Take a number.

It sprouts faster than you can get on it sometimes.

Pays the mortgage :)

David

On Sat, Jan 25, 2020 at 4:05 PM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
| From: Dhaval Giani via talk <talk@gtalug.org>

| On Thu, Jan 23, 2020 at 11:08 AM D. Hugh Redelmeier via talk <
| talk@gtalug.org> wrote:
|
| > <
| > https://www.zdnet.com/article/microsoft-spots-malicious-npm-package-stealing-data-from-unix-systems/
| > >
| >
| > This article list six cases of malware contributed to npm (the repo for
| > sharing node.js and JavaScript source).
| >
| > How many undetected cases exist?
| >
| > I've alway pretended that Linux distros vet their code.
|
|
| They do, but npm is different. npm is indepdent of the distro itself. And
| people want to use npm because it gives them the latest and the greatest.

I'm sorry that I wasn't clearer.

I was changing the subject a bit.  Just like npm has problems because
vetting contributions is a hard problem, so too Linux distros have
problems because vetting contributions is a hard problem.

I know npm (JavaScript), CPAN (perl), CTAN (TeX), CPAN (Python),
github, probably crates.io (Rust), etc. each bypass the disto.

Any security flaws identified by a distro get fixed by updates but
anything users sourced from these other repos will not be fixed by
distro updates.  A serious logistic problem for users, even if they
are unaware of it.

I try to avoid these repos for just that reason but it is kind of
hard.

| >   I'm not sure how
| > true that is.  Probably the greatest protection is the time delay between
| > contribution and distribution.
| >
| >
| I would be wary of this approach. There are a bunch of security fixes,
| where you probably don't want too long a delay. Part of responsibility also
| lies on the user to validate the update. With it being open source, and a
| "volunteer" model, some of that has to be accepted b the user.

Sorry, I meant: the time delay between creating a piece of software
and it being adopted by Linux distros.  Not a delay because the user
avoids distro updates.

I imagine the barrier to contributing to npm is zero.  But I don't
actually know.  See below.

The barrier to contribution to any distro I know of is a bit higher.
That involves time, effort, and creativity.  But not enough to prevent
a determined and skilled contributor of malware.  The easiest way is
probably to infiltrate a group that produces a piece of software
already accepted by many distros.  Then it depends on the vetting by
that project.

More on npm:

<https://en.wikipedia.org/wiki/Npm_(software)>

npm is the "Node Package Manager".  It accompanies node.js.  It hooks
up to a "registry", by default nodejs.com (a commercial entity).
Here's a bit from Wikipedia (all caps added by me):

        Over 477,000 packages are available on the main npm
        registry.[16] The registry has NO VETTING process for
        submission, which means that packages found there can be low
        quality, insecure, or malicious.[15] Instead, npm relies on
        user reports to take down packages if they violate policies by
        being low quality, insecure or malicious.[17] npm exposes
        statistics including number of downloads and number of
        depending packages to assist developers in judging the quality
        of packages.[18]
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk


--
David Thornton