Received-SPF: pass (google.com: domain of oss-security-return-30085-linux.lists.archive=gmail.com@lists.openwall.com designates 193.110.157.125 as permitted sender) client-ip=193.110.157.125;
Mailing-List: contact oss-security-help@lists.openwall.com; run by ezmlm
Precedence: bulk
Reply-To: oss-security@lists.openwall.com
Date: Fri, 26 Apr 2024 21:59:06 +0100
From: Simon McVittie <smcv@debian.org>
To: oss-security@lists.openwall.com
Message-ID: <ZiwVmhV2muRhsAfy@remnant.pseudorandom.co.uk>
References: <20240426135217.a103ce0c-a775-4a49-ae2c-94dfd64f6695@korelogic.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240426135217.a103ce0c-a775-4a49-ae2c-94dfd64f6695@korelogic.com>
Subject: Re: [oss-security] Update on the distro-backdoor-scanner effort

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

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