2 ms·
> then strange behavior and commits that claim to do one thing but actually do something else, are more likely to be spotted earlier than later. https://en.wik
by chii 3y ago
> then strange behavior and commits that claim to do one thing but actually do something else, are more likely to be spotted earlier than later.
https://en.wikipedia.org/wiki/Underhanded_C_Contest https://en.wikipedia.org/wiki/Underhanded_C_Contest
It's actually an art to writing code like that, but it's not impossible and will dodge cursory inspection. And it's possible to have plausible deniability in the way it is constructed.
- imiric 3y agoI'm not sure why my point is not getting across... I'm not saying that these manual and automated checks make a project impervious to malicious actors. Successful attacks are always a possibility even in the strictest of environments. What they do provide is a _chance reduction_ of these attacks being successful. Just like following all the best security practices doesn't produce 100% secure software, neither does following best development practices prevent malicious code from being merged in. But this doesn't mean that it's OK to ignore these practices altogether, as they do have tangible benefits. I argue that projects that have them are better prepared against this type of attack than those that do not.