[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 26 Apr 2024 22:17:36 +0100
From: Sam James <sam@...too.org>
To: Simon McVittie <smcv@...ian.org>
Cc: oss-security@...ts.openwall.com
Subject: Re: Update on the distro-backdoor-scanner effort
Simon McVittie <smcv@...ian.org> writes:
> On Fri, 26 Apr 2024 at 14:06:16 -0600, Hank Leininger wrote:
>> - Turns out serial numbers are made up and the points don't matter.
>> But still, this author appears to have _thought_ they were
>> important.
>
> The serial number of a m4 file matters if the attacker wants their back
> door to remain in place when a distro runs autoreconf -fi or similar
> (as many Autoconf-built Debian packages do, for example); or, less
> maliciously, if the author of a legitimate set of Autoconf macros wants
> their bug fixes to remain in place when an older distro does the same.
>
> The purpose of the serial number is so that autoreconf can upgrade bundled
> macros in the `make dist` tarball to the distro version if it happens
> to be newer (for example if I prepared a Flatpak release on Debian 12
> but you are building it on Arch), without downgrading to an older distro
> version that might be lacking newer features or bug fixes (for example
> when someone else builds that same Flatpak release on Debian 11).
But it doesn't work that way! See the bottom of
https://www.gnu.org/software/automake/manual/html_node/Serials.html.
"Finally, note that the --force option of aclocal has absolutely no
effect on the files installed by --install. For instance, if you
have modified your local macros, do not expect --install --force to
replace the local macros by their system-wide versions."
(I was very surprised to learn this when doing this work, it was
pointed out to me by Guillem Jover.)
>
> If a developer of Autoconf macros is following its documentation, the
> serial number should go up whenever the code changes. The observant
> will of course notice that this doesn't account for the possibility of
> non-linear development (macros being modified in a non-canonical location,
> forked, edited collaboratively, or otherwise not having a monotonically
> increasing version number) which I think is a reflection of what was
> and wasn't considered to be normal when it was designed - it's very much
> from the "cathedral" era.
>
> (Many projects don't follow the documentation and do make changes without
> incrementing the serial number, which is a bug.)
>
> Beyond that single purpose, yes, the serial number is made up and doesn't
> matter.
>
> smcv
Download attachment "signature.asc" of type "application/pgp-signature" (378 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
