Most likely this is not the first backdoor, just the first one to be discovered, so it wasn't two years of work until there were results.
But I still agree that he's probably a state actor.
Most likely this is not the first backdoor, just the first one to be discovered, so it wasn't two years of work until there were results.
But I still agree that he's probably a state actor.
In fact, that'd be the best form of deep cover. It'll be interested to watch as people more knowledgable than I pour over every single commit and change.
There could be other backdoors for other targets.
(1) A backdoor like this one, which isn't really about its core functions, but about the fact that it's a library linked into critical code, so that you can use it to backdoor _other things_. Those are complex and tricky because you have to manipulate the linking/GOT specifically for a target.
(2) Insert an exploitable flaw such as a buffer overflow so that you can craft malicious .xz files that result in a target executing code if they process your file. This is a slightly more generic attack vector but that requires a click/download/action.
Not every machine or person you want to compromise has an exposed service like ssh, and not every target will download/decompress a file you send to them. These are decently orthogonal attack vectors even though they both involve a library.
(Note that there's as yet no evidence for #2 - I'm just noting how I'd try to leverage this to maximum effect if I wanted to.)
these files are also useful to check that the library we just built works correctly. but they aren't necessary for installation.
we may have more sophisticated procedures that will allow us to use some parts of distribution only for tests. This may significantly reduce an attack vector - many projects have huge, sophisticated testing infrastructure where you can hide the entire Wikipedia.