Let's try to go in detail on how this was done on the build system
side (I'm doing this right now, as previously only had skimmed over
the process).
The build system hook was planted in the tarball by adding a modified m4/build-to-host.m4 file. This file is originally from gnulib (but
gettext would usually embed it if it required it). The macros contained within are used by m4/gettext.m4 coming from gettext.
So to start with, this dependency (the AM_GNU_GETTEXT macro uses gl_BUILD_TO_HOST) is only present with newer gettext versions. The
tarball was autoreconf'ed with gettext 0.22.4, Debian has gettext 0.21,
which does not pull that dependency in. In that case if gettext.m4
would get modified in this build now, then the hook would be inert,
but once we update to a newer gettext then it would get activated
again.
The m4/build-to-host.m4 file in addition to hooking the payload into
the build system, also got its serial number bumped from 3 to 30.
And the bigger issue is that «autoreconf -f -i» does not even refresh
the files (as you'd expect from the --force), if the .m4 serial is higher.
So in Debian currently, the gettext.m4 in the tarball does not get
refreshed (still pulling in the malicious build-to-host.m4, which
would not happen with the gettext version from Debian), and if we
updated to a newer gettext then it would not update build-to-host.m4
anyway due to its bumped serial.
This seems like a serious bug in autoreconf, but I've not checked if
this has been brought up upstream, and whether they consider it's
working as intended. I expect the serial to be used only when not
in --force mode though. :/
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 360 |
Nodes: | 16 (2 / 14) |
Uptime: | 128:36:58 |
Calls: | 7,686 |
Files: | 12,828 |
Messages: | 5,711,092 |