Given that a lot of Python software I see already by convention runs in a venv, which is at least somewhat-isolated from the rest of the system…I wonder how much harder it would be to make it the norm for most Python software to run in an isolated sandbox, without broader filesystem access. Like, kinda follow an Android-like model, where there’s an application-private directory and permissions that mostly make the app keep to itself.
I do run some Python software in firejail. But it’d need to be a norm for how the software is distributed. Can’t require a bunch of technical work on the part of end users.
kiagam@lemmy.world 1 day ago
What part of it is malicious? From what I understood, it is a illegal music downloading platform, and they say it opens its users to “plegal action”.
Are we calling pirating-enabling software malicious now? Because pirating is ilegal?
n0xew@lemmy.world 1 day ago
I agree the article isn’t super clear. Reading it twice, it seems that the user credentials are exfiltrated to the C2 server (only the screenshot implies it), which definitely would be malicious.
Also a possible interpretation could be that the package advertised “just” some automations (e.g. export playlists to m3u?) and getting music metadata, whereas it was actually downloading musics locally unbeknownst to the user. Then exfiltrating the music back to the C2 server, effectively using the package’s users to mass pirate musics without exposing the pirates directly. That would indeed be malicious, especially if the package did not advertise any content downloading.
But for the last paragraph I’m extrapolating on the few info this article gives without making much sense…
kiagam@lemmy.world 21 hours ago
I see, makes sense, so the problem is that the user tokens are collected without knowledge and could be used for pirating
unautrenom@jlai.lu 1 day ago
I assume the malicious part is that it phones home without permission, likely tracking users without their consent or informing them.