Let’s learn from other’s mistakes instead of repeating them. Specifically, the debacle that is node.js / npm. See the following two recent train-wrecks: [image] npm Blog Archive: kik, left-pad, and npm npm Blog (Archive); updates from the npm team are now published on the GitHub Blog an…

I think it would be better if the scanner uses heuristics based on the type of code being added in comparison to what’s already in the package, and then provide one or more “scores” that the user can set thresholds on (probably globally as well as per-package). Triggering any threshold will prevent …

I also would like to say that closed-sourcing any of this is a bad idea. Aside from being security-through-obscurity, which the security community typically frowns upon, this doesn’t prevent the closed-source scanners from being gamed. You could just submit a bunch of new packages with malware in th…

[image] jpsamaroo: as long as there are plenty of heuristics being used I don’t think there is a free lunch here; I can’t imagine this not triggering a lot of false positives, which would require (costly) human intervention.

Sure, I agree. But if you’re the kind of (corporate/government/paranoid) user that cares about this sort of thing, you’ll be willing to do a review of your triggering packages anyway (might as well). If you don’t really care, just raise the global threshold until it rarely or doesn’t trigger. The po…

[image] jpsamaroo: But if you’re the kind of (corporate/government/paranoid) user that cares about this sort of thing, you’ll be willing to do a review of your triggering packages anyway (might as well). Perhaps I missed something, but my impression of the current situation is that there isn’…

If no one is auditing the packages in a trusted registry, then there’s no good reason to trust the trusted registry. I’m only addressing the proposal to have a package scanner, which could be a useful tool for directing the efforts of those who wish to maintain a trusted registry (of which their cou…

[image] jpsamaroo: If no one is auditing the packages in a trusted registry, then there’s no good reason to trust the trusted registry. One of the ideas in this thread was that you’d trust some developers, and any commits they do (including merging PRs), you’d trust too. Recursively applying…

[image] jpsamaroo: You could just submit a bunch of new packages with malware in them to the scanner, each with slight variations on the exploitation mechanism, until one or more of them pass the scanner unnoticed. Submitting a package means making your exploitation mechanism public, and whil…

[image] jpsamaroo: If no one is auditing the packages in a trusted registry, then there’s no good reason to trust the trusted registry. Trust is not an necessarily absolute concept. A procedure that significantly reduces the probability of adverse events can be useful even if it does not comp…

[image] jpsamaroo: the number of uses of TCPSocket I’m not sure if it is possible to write an open source scanner that can measure this reliably. For example, I might initialize my package with if some_condition f = Sockets.connect else f = innocent_function end where some_condition …

Pkg ecosystem: Learning from other's mistakes

Community

StefanKarpinski December 5, 2018, 6:00pm 51

I have started Pkg: attack vectors to discuss package ecosystem attack vectors. Please only post attack vectors, however, not general discussion or spitballing of ideas.

3 Likes

Topic		Replies	Views
Pkg: attack vectors Internals & Design security , package-manager	25	3930	September 17, 2020
Trusted libraries/packages - "package managers are evil" Internals & Design security , secrets	12	1061	September 18, 2025
The State of the Julia Ecosystem Community	109	8974	January 31, 2019
How can we create a leaner ecosystem for Julia? Statistics package , proposal , time-series , machine-learning	101	10833	October 15, 2020
Reduce package registration waiting period Meta Discussion	83	4278	June 10, 2020

Pkg ecosystem: Learning from other's mistakes

Related topics