3 ms·
I think the lesson here for packagers is that binary testdata should not be present while doing the build. It is too easy to hide things in testdata.
by londons_explore 3y ago
I think the lesson here for packagers is that binary testdata should not be present while doing the build.
It is too easy to hide things in testdata.
- yencabulator 3y agoNice idea, but then you just hide the attack in logo.png that gets embedded in the binary. Less useful for libraries, works plenty good for web/desktop/mobile.
- consumer451 3y agoThis entire thread is above my pay grade, but isn’t minimizing the attack surface always a good thing?
- ReflectedImage 3y agoIt's all irrelevant. The attacker social engineered their way to being the lead maintainer for the project.
- StressedDev 3y agoThe problem with the parent's suggestion is you end up banning lots of useful techniques while not actually stopping hackers from installing back doors or adding security exploits. The basic problem is once an attacker can submit changes to a project, the attacker can do a lot of damage. The only real solution is to do very careful code reviews. Basically, having a malicious person get code into a project is always going to be a disaster. If they can get control of a project, it is going to be even worse.
- consumer451 3y ago> The only real solution is to do very careful code reviews. Are there any projects that are well resourced enough to do this consistently, including all dependencies?