  Every package install is checked against the threat feed and it raises an exception if we find something malicious being installed

Ok big problem is lots of stuff installed for campaigns wasn't flagged in any feed. If maintainer access is taken over you still don't have any feed info, maybe it will be a bit faster to publish so if maintainer finds out.

Everyone is looking at NPM how bad it is or AUR lately. Those are "free for all anything can happen, any kid can publish" repositories and that's what you get.

No one looks at Debian and is saying "well maybe we should do what they do"...

▲ asdfaoeu an hour ago | parent | next [-]

> No one looks at Debian and is saying "well maybe we should do what they do"...

Arch does exactly what Debian for the official repos. It was only the AUR that was compromised. Possibly the issue is that Arch is a bit to strict for the official repos which has forced too many people on to the AUR ones.

▲ maxbond an hour ago | parent | prev | next [-]

NPM has at least had the good sense to use namespaces so that it isn't entirely a free for all and is less of a high stakes game of Mavis Beacon. (You could typosquat a namespace too, of course.) Unlike AUR but also pip, cargo, etc.

▲ captn3m0 4 hours ago | parent | prev | next [-]

Author here - people are definitely looking at other places. This just happens to be where the attacks are, and gets disproportionate attention as a result.

Do you have examples of campaigns that weren’t flagged? Everything except xz had a 1 day window and Dependency Cooldowns are super effective against most campaigns for that reason.

See papers at https://kokkonisd.github.io/ for eg.

	▲	ozim an hour ago \| parent \| next [-]
		People are disregarding model where registry is responsible for what they publish. Your solution does exactly that. Giving hooks to end users just pushes the responsibility to the users. Yes all issues were publicized and marked in hours. Sorry but hours is not good enough when there is countless CI pipelines running in a single hour. Only solution is not allowing to publish malicious stuff. Cooldowns are also not the solution because possibilities to publish malicious code is still there if no one reviews it.
	▲	amiga386 an hour ago \| parent \| prev [-]
		I haven't ever seen "a campaign" get through Debian's release process, besides xz-utils. The only major blemish in Debian's record was in 2006 when one of its developers patched OpenSSL to avoid using uninitialised memory as a source of randomness, in order to placate a static analyser. Nobody in Debian noticed that this effectively made OpenSSL key generation entirely predictable (it only generated one of 32768 unique keys), for 2 years.

▲ PunchyHamster 3 hours ago | parent | prev [-]

> No one looks at Debian and is saying "well maybe we should do what they do"...

You mean that having mature community with maintainers checking subscriptions and a "testing" channel where stuff only lands after few weeks of no problems is useful ? Who could possibly imagine!?

Industry's gonna NIH

> Ok big problem is lots of stuff installed for campaigns wasn't flagged in any feed. If maintainer access is taken over you still don't have any feed info, maybe it will be a bit faster to publish so if maintainer finds out.

Technically at the very least company could throw their feed to AI and at least get some automated screening on the changes between versions

	▲	amiga386 2 hours ago \| parent [-]
		Let's not forget, in the majority of cases in Debian, the packager is not the software author. It's an independent volunteer, vetted by a community of such volunteers. This is an incredibly useful, I'd say essential, firewall. I really don't like the Windows/macOS approach of "just do everything yourself, we'll do nothing", and likewise the npm et al approach of there being a fully automated package registry which merely distributes packages to millions of people, and leaves the onus on the software author for when to publish and what to publish. A drive-by script could trigger some CI via a developer's credentials to publish a new version. If the outcome of that is it merely sends an email to a second person, who might get around to looking at it, and will likely look at the diffs, have to write up what the changes are, and might email back... that's a hell of a lot better than push straight to prod We still have the problem of Debian developers being free to push their own changes, and a suitably knowledgeable one could hide stuff from the various automated testing and analyses they face, but even then they face pushback from real testers, and if caught pushing malware they'd lose their prestigious volunteer position of trust instantly.