[raesene9]

Yeah this problem has been a known issue for a long time, but there really is no easy fix, and incentives are stacked against it getting resolved in any meaningful way.

I did a talk for AppsecEU back in 2015 on this topic and found good material talking about it as a risk going back years before that...

[19ylram49]

I think I might start using fully isolated environments (i.e., via Vagrant/Docker/etc.) for all of my projects from now on (I already do for some).

[jcoby]

That approach will mitigate your machine getting compromised (which is good) but it won't fix your production machines getting compromised if the gem or package gets deployed. That is usually a much worse outcome.

And even in isolated environments I find myself running code outside of the container for testing. Usually a quick script to test some package's functionality or opening a REPL to run something or running a code-generator (manage.py, artisan, etc). That's all it takes for the malware to break out of the isolation and attack your machine.

[jcoby]

> there really is no easy fix

Is there any fix at all? Aside from something like multiple-account code signing/release verification I cannot think of something that couldn't be compromised in some way.

At the end of the day you have to trust someone and trust that they trust someone else. The problem is you have no way of vetting the entire dependency chain. You may have reviewed gem/package A but you aren't going to (realistically) review all of its dependencies and those dependencies' dependencies.

At this point it's all a "many eyes" approach. And it seems to be working relatively effectively.

[raesene9]

I'd debate the relatively effective piece in light of webmin being backdoored for a year, and of course remember we're only hearing about the ones that have been found, not the ones that haven't.

There's a number of possible technical mitigations, maintaining internal package repositories, code review of key libraries, enforcing package signing and checking signatures etc but all of them increase costs and decrease development speed, so they're not adopted that heavily.

There are also possible mitigations at a legislative/policy level, but they would be so deeply unpopular that I'm sure they'd never pass muster in most countries.

[deckard1]

Linus's Law (given enough eyeballs, all bugs are shallow) has never rang true to me. I've been using free software since '95.

Taken at face value, then yes, obviously more people looking at a specific piece of code will make it better. But this does not extend to the entire landscape of open source. Most developers, especially ones doing so as a hobby, would much rather work on their own new code. Not look at someone else's old boring code. We would rather reinvent the wheel a thousand times before touching a line of code written by someone else.

This becomes even more dire when you look at code no one wants to touch. Like TLS. There were the Heartbleed and goto fail bugs which existed for, IIRC, a few years before they were discovered. Not surprising, because TLS code is generally some of the worst code on the planet to stare at all day.