3 ms·
I'm not sure how exactly these infections work, but one method would be to infect the developers' PCs. In which case you essentially can't trust anything. You'd
by contravariant 9y ago
I'm not sure how exactly these infections work, but one method would be to infect the developers' PCs. In which case you essentially can't trust anything. You'd need some kind of byzantine fault tolerance (mandatory multi-person code review?) to be sure nothing like this ever happens
What makes this scary is that, as far as I know, pretty much no software has that kind of security, and there are several pieces of widely used software that always update automatically (sometimes for good reason, sometimes not so much).
- elorant 9y agoYou can enable AppLocker and have explicit control on what executes and what not by creating rules. I know quite a few companies that enforce its use in their employees' PCs.
- cyphar 9y agoAs an aside, AppLocker was trivially bypassable for several years -- there were two different APIs that allowed you to set an "ignore AppLocker" flag. We used to use it in high-school to play games (or in my case, run gvim and some other development tools). I think that there needs to be a more complete solution than just "secure the developers machines". You need to have peer-review, where the developers sign commits to approve them.
- elsjaako 9y agoThe solution would be code review + reproducable builds. This is how Debian tries to prevent these kinds of attacks.
- isntthatsox 9y ago> mandatory multi-person code review? Isn't this pretty much mandatory with SOX compliance anyway?