81–90 of 334 posts
I hope the age of a thousand dependencies automatically pulled and upgraded on a basis of trust is coming to a close. It was obvious from the start this would eventually become a problem. Trust-based systems like this only work for as long as scoundrels remain out of the loop.
can there be a "blue checkmark" system for pypi authors? I'm sure that's been brought up and rejected for reasons .
Earlier quoted context omitted.
Python is just far more popular. RubyGem: https://www.bleepingcomputer.com/news/security/malicious-rub... Perl CPAN https://news.perlfoundation.org/post/malicious-code-found-in...
I think this has more to due with the contexts/industries we typically see Python used in over pure popularity. If popularity was the only factor I'd expect to seeing a lot more news about these problems in Java/PHP ecosystems which are absolutely massive.
Many languages since then decided that causes too much overhead.
Earlier quoted context omitted.
I've never understood this position. How often do you add a dependency to your project, compile your project, and then never run your project ever? I can't think of a single case where this would have protected me.
CI/CD servers, dev laptops etc could have more privileges than the production machines. For instance.
I'm not experienced but I thought it was normal to have some way to try out what you've written on your dev machine. Is everyone else stepping through code in their head only, and their code is run for the first time when it's deployed to production?
Earlier quoted context omitted.
I've never understood this position. How often do you add a dependency to your project, compile your project, and then never run your project ever? I can't think of a single case where this would have protected me.
It means you don't need to run the compiler in a sandbox. People do not expect the compiler to be susceptible to malware attacks, and I do what I can to live up to that trust. I haven't heard of anyone creating a malicious source file that would take advantage of a compiler bug to insert malware, but there have been a lot of such attacks on other unsuspecting programs, like those zip bomb files.
I'm not familiar with D, so I'll use the example of Rust. My usual workflow looks something like this
1. Make some changes
2. Either use `cargo test` to run my tests or `cargo run` to run my binary.
In both those cases the code is first compiled and subsequently run. I care if running that command gives me malware. I don't care at what step it happens.
It's using base64 encoded strings to deliver the initial stage. Can this be avoided/flagged more easily if by adding a scan of statements featuring base64 or import?
The attack surface area is too big when random python code is executed, which is the case for `setup.py`, but even if there wasn't code executed there, as soon as you import the package and use it, you'd have the same issue.
Earlier quoted context omitted.
This is a good approach, though presumably the VM still has access to your Github credentials (via the browser) and your SSH keys? It'll limit the fallout of getting owned to anything reachable from Github (is it against Github's TOS to have multiple accounts?), less if you have 2FA (does there exist 2FA for SSH keys (I don't mean passphrases)?), but I think it would be better for just my build/run/test cycles to be…
It might be too cumbersome for most, and I might be more paranoid than average, but each project for me means a fresh VM, a new Keepass database and dedicated accounts. Then again I work mostly in ops, and I've seen first hand how badly things can go wrong so isolation and limiting blast radius takes precedence over daily convenience for me.
(If it makes any difference, I would probably be using VMWare Workstation Pro)
I 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.
Earlier quoted context omitted.
It means you don't need to run the compiler in a sandbox. People do not expect the compiler to be susceptible to malware attacks, and I do what I can to live up to that trust. I haven't heard of anyone creating a malicious source file that would take advantage of a compiler bug to insert malware, but there have been a lot of such attacks on other unsuspecting programs, like those zip bomb files.
> People do not expect the compiler to be susceptible to malware attacks I'm not familiar with D, so I'll use the example of Rust. My usual workflow looks something like this 1. Make some changes 2. Either use `cargo test` to run my tests or `cargo run` to run my binary. In both those cases the code is first compiled and subsequently run. I care if running that command gives me malware. I don't care at what step it h…