@mathaetaes So take it to be implicit here that the intent is to mitigate the risk beyond whatever you can do by looking at the code. (Honestly, I think people overestimate their ability to spot malicious code.)

@internic Fair point, though I find vulnerabilities and shenanigans in source code for a living. :)

I do have a VM for "questionable" software... though that's usually used for software that I trust, but that I don't trust will clean up after itself when I try to remove it. Autodesk software is the primary vendor for that VM...

@0x0FFF I think there's some truth to that, with three caveats:
1. There may be communities that I generally trust but may not entirely trust their vigilance in vetting contributions from new devs.
2. There may be some small projects that use techniques I don't entirely understand. (This is especially relevant for anyone still learning a new language.)
3. In my view biggest danger is *thinking* you understand the code when you really don't, so in some sense that's the one I'm most interested in mitigating.

@internic yeah I was really just speaking for myself to be completely honest. I do a lot of code review specifically looking for security vulns in my day job as a pentester, so it’s something I’m pretty confident in. Although like anyone in the world, I’m not free from making a mistake or missing something.

Also, most malicious code isn’t going to pop some magic notification stating it’s malicious. So even if you do run it in a VM or something, I assume it’s then going to be moved to the target system yes? Identifying malicious code as it acts in the system is probably even more difficult than reading the code itself and finding it to be frank. So these users are supposed to be capable of that even though they’re not capable of reading code themselves? I think that’s placing entirely too much theoretical ability on the user, even a technical user or developer. It takes a special set of skills, knowledge, and software, to identify malicious software as it acts on the system.