What I mean is that Debian and Fedora presumably download the tarball and build from there, rather than cloning a repo and building from the repo.
If they did the latter, it would have been much more difficult to manipulate the build process to inject the backdoor that lived inside the testcase binaries, because that change to the build scripts would be out in the open.
But I could be mistaken...
build-to-host.m4 is not checked into the repo. Without the modified build-to-host.m4, there is nothing to kick off the exploit.
The actual final product you get is when publishing (building) the application itself, similar to Rust the way crates participate in the build process.
Nuget packages still can and do ship pre-compiled native dependencies but ideally you want to either provide your own (think sourcing libsodium separately and just getting the bindings from nuget) or instrument the corresponding .NET project to build a native dependency alongside it (very easy with <Exec Command="..." /> properties in csproj).
I don't think so. The git repo did have everything needed. The release tarball thing was just an added benefit to the attackers, but not critical. IMO.
> I've setup and worked with many build pipelines in the .NET world over nearly 20 years and we manage fine without the concept of a source release tarball, but I realise C dev is more complex so I'm probably missing something?
.Net, but, portable .Net?
The issue isn't the language but what things you need to detect presence of in the target host when building, and if you're doing systems programming you're likely to need to detect many such things, and if you're doing more high level programming (e.g., an HTTP app that uses a DB) then you're not likely to need to detect many such things.
The real issue is the variance from standards (e.g., POSIX) and the fact that the standards (e.g., POSIX) are so far behind because they really just standardize the lowest common denominator.