Eric Gallager wrote:
> One thing I noticed in the writeup is that part of the way it worked
> involved a modified copy of gnulib's build-to-host.m4 macro file; ...
> is if there's anything gnulib can add on
> its end to ensure that the macro actually does what it's supposed to
> do?
Having source files that anyone can copy and modify is the core of
Free Software; therefore any approach relying on checksums is out of
question.
Unit tests can check that it does _at_least_ what it's supposed to do.
Here the malware had the effect of _additionally_ doing other things.
That's something you cannot catch through a unit test (except possibly
by counting the execution cycles on a virtual CPU that does not have
any caches).
The best ways to avoid malware are:
- code reviews (which was lacking in the case of 'xz' [1]),
- behaviour-based observations in a system that has good tools
for introspection and analysis (that we do have in Linux,
more than Windows and macOS).
Bruno
[1] Lasse Collin wrote today: "
The last things I didn't review were the final ifunc changes.
It's surprisingly little that has gone into the Git repo without any kind of
review by me. But these changes were such.
...
The ifunc stuff had had some trouble (real bugs) and I was fifty-fifty if all
ifunc should be ripped out just because it didn't feel worth it in this project.
"
