I wasn't aware that the rogue maintainer was able to commit himself without any PR review (or he snuck it through PR review) rogue steps in the build process as well that went unnoticed so that he could bundle decompressed `xz` streams from test data, that also patched output .so files well enough to add hooking code to them.
How many "process failures" are described in that process that exist in every OSS repo with volunteer unknown untrusted maintainers?
> volunteer
That's the majority of OSS. Only a handful of the projects we use today as a part of the core set of systems in the OSS world actually have corporate sponsorship by virtue of maintainers/contributors on the payroll.
> unknown
The actor built up a positive reputation by assisting with maintaining the repo at a time when the lead dev was unable to take an active role. In this sense, although we did not have some kind of full chain of authentication that "Jia Tan" was a real human that existed, that's about as good as it gets, and there's plenty of real world examples of espionage in both the open and closed source software world that can tell us that identity verification may not have prevented anything.
> untrusted
The actor gained trust. The barrier to gaining trust may have been low due to the mental health of the lead maintainer, but trust was earned and received. The lead maintainer communicated to distros that they should be added.
That's the rub here. It's _really easy_ to say this is a process problem. It's not. This was a social engineering attack first and foremost before anything else. It unlocked the way forward for the threat actor to take many actions unilaterally.
How would this have made it into Debian? Part of the Debian build is to pull down a release tarball (and then build from source) and not `git clone` a repo at a specific tag and build from source?
This guy was pretty trusted after a couple of years of working on the project so I think it’s a category error to say process improvements could have fixed it. The use of autoconf detritus was a canny move since I’d bet long odds that even if your process said three other people had to review every commit they would have skimmed right over that to the ”important” changes.
