4 ms·

> the build-to-host.m4 macro package that ships as part of GNU gettext was replaced by a modified version that was copied into the release tarball Am I correct

> the build-to-host.m4 macro package that ships as part of GNU gettext was replaced by a modified version that was copied into the release tarball Am I correct in concluding that this backdoor might have been picked up sooner if the practice of shipping tarballs of source releases was dropped in favour of running builds straight off a repo tag? 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?

cryptonector 3y ago
> Am I correct in concluding that this backdoor might have been picked up sooner if the practice of shipping tarballs of source releases was dropped in favour of running builds straight off a repo tag? 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.
- edflsafoiewq 3y ago
  > I don't think so. The git repo did have everything needed. 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.
- ryanjshaw 3y ago
  > The release tarball thing was just an added benefit to the attackers, but not critical. IMO. 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...
- neonsunset 3y ago
  In .NET specifically it's not an issue because taking on a dependency means you always get the source code in the form of IL assemblies with (usually) symbols (either way these trivially decompile back to readable-ish C#). 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).

cryptonector 3y ago

> Am I correct in concluding that this backdoor might have been picked up sooner if the practice of shipping tarballs of source releases was dropped in favour of running builds straight off a repo tag? 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.

edflsafoiewq 3y ago
> I don't think so. The git repo did have everything needed. 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.
ryanjshaw 3y ago
> The release tarball thing was just an added benefit to the attackers, but not critical. IMO. 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...
neonsunset 3y ago
In .NET specifically it's not an issue because taking on a dependency means you always get the source code in the form of IL assemblies with (usually) symbols (either way these trivially decompile back to readable-ish C#). 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).