Frankly it's surprising this doesn't happen more often.
Another one is just maintainer/packagers for popular distros like Arch.
I'd be very surprised if something shady isn't there as of now.
Dozens of malicious PyPI packages discovered targeting developers
281–290 of 334 posts
Re: Dozens of malicious PyPI packages discovered targeting developers
#282Would it be possible to make a more trusted package mirror? Somehow validating packages before inclusion? IIRC mirrors for NPM, Packagist and others is not impossible, can be done for PyPY and others too? Maybe it's a stop-gap before all the fancy permissions feature build out (which seems hard)
This is what systems like deb and rpm do - they curate a list of packages that can be installed to the system. But most people (in my experience, including myself) don’t use them because they get out of date really quickly and don’t lend themselves to things like virtual environments very well.
Debian unstable is usually years behind the times.
Re: Dozens of malicious PyPI packages discovered targeting developers
#283Earlier quoted context omitted.
I like this. I'd try to keep the permission sets as small, limited, and simple as possible though.
> I'd try to keep the permission sets as small and simple as possible though. You've described OpenBSD in general. I recommend a deeper dive - it's fantastically refreshing, how simple yet functional an OS can be.
No post body was provided.
Re: Dozens of malicious PyPI packages discovered targeting developers
#284Earlier quoted context omitted.
I suppose you could, but have you seen how popular new opensource projets being run these days? Young devs really loves discord to the point of hosting documentations there. I imagine young malware authors are no different.
Which, I don’t know if I’m getting old, but man that frustrates me. It’s a terrible platform for documentation. It’s barely a good text chat platform.
You are, yes and yes.
Re: Dozens of malicious PyPI packages discovered targeting developers
#285Earlier quoted context omitted.
Another good option is to create a new user and run everything under the new UID. Running under a new UID has less chances of accidentally leaving something exposed that can allow for sandbox escape. If you run everything from the new UID, it will mostly be contained to it's own $HOME directory and be unable to modify your user's files or system files. Some distros do not protect home directories from being read so i…
How do you escape the sandbox through a Wayland or X11 socket? Do you have specific code examples? Is there no way to safely run graphical applications in a bwrap sandbox? I thought Wayland was supposed to be better about this.
I think Wayland is fairly safe, but any X11 client can take screenshots or listen to the keyboard, or emit keyboard event, without limitations.
Re: Dozens of malicious PyPI packages discovered targeting developers
#286Earlier quoted context omitted.
google.com/tensorflow (and you'd have to prove you own google.com) not perfect, but better.
I've always been a fan of how Java packages do it where the TLD is first.
Re: Dozens of malicious PyPI packages discovered targeting developers
#287Is there something about Python or PyPI that makes it more attractive for malicious developers to add malware? Is this also happening for repos for other languages (e.g. CPAN, RubyGems)?
It’s the most popular
It can run code during installation phase
It’s very easy to obfuscate due to its dynamic nature. An import of urllib or os.system isn’t immediately visible at the top of a file as it would be in Java, it can be hidden in eval() or basically anywhere.
Finally, even legitimate packages have very, and I mean it, very bad names. Usually with a trailing number for no good reason. Lacking organizational namespaces. Together with a culture of using a lot of such dependencies and lacking a culture of freezing transitive versions. Blending in among those is too easy. Just take a common name and suffix it with 3.
Re: Dozens of malicious PyPI packages discovered targeting developers
#288Earlier quoted context omitted.
Vendoring also means your builds don’t need an Internet connection. Going on a trip somewhere without an Internet connection? Checkout the repo on your laptop and go. Without vendoring: oh shoot, I forgot to download the deps, I guess I’m going to be forced into a work-life balance. With vendoring: no additional step needed after checking out the repo. The repo has everything you need to work. Another case: repo of y…
You should have the modules downloaded to the module cache for the occasional case when you don't have direct internet access. > Another case: repo of your dependency is removed, or force-pushed to overwriting history. You’ve lost the ability to build your project, and need to either find another source for your dependency, or rewrite it. The GOPROXY ( https://proxy.golang.org/ ) still contains that removed repo, and…
> You should have the modules downloaded to the module cache for the occasional case when you don't have direct internet access.
That’s assuming I’ve built the thing previously on that same computer. I’m talking about the common case of working on a normal desktop day-to-day and then switching to a laptop, when travelling to a place without internet (or internet of such a poor quality you might as well not bother). With vendoring I don’t need to think about any other steps than copy/checkout the repo. The repo is self-contained. Without it, I’m making the quantum leap to a checklist.
Re: Dozens of malicious PyPI packages discovered targeting developers
#289I think a proper way to solve this issue, not specific to python but languages running in a VM in general, would be to have some sort of language support where you specifically define what access rights/ system resources you allow for any given dependency. Example of defining project dependencies: { "apollo-client": { "version": "...", "access": ["fetch"] // only fetch allowed }, "stringutils": { "version": "...", "a…
Newspeak?
Re: Dozens of malicious PyPI packages discovered targeting developers
#290I started to develop only inside VMs, with a full Desktop, IDE, browser etc. inside the virtual machine. There have been to many contaminations of major package repos lately. Only one typo in an import statement up the dependency chain and you’d be compromised.
Similar. I run text editor on the main OS but run language server in the requisite environment with all the requirements in a container.