Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 26 Apr 2024 22:17:36 +0100
From: Sam James <>
To: Simon McVittie <>
Subject: Re: Update on the distro-backdoor-scanner effort

Simon McVittie <> 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

"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.