Debian Bug report logs - #977684
mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@reproducible-builds.org>

To: submit@bugs.debian.org

Subject: mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

Date: Fri, 18 Dec 2020 12:42:20 -0800

[Message part 1 (text/plain, inline)]

Source: mahimahi
Severity: normal
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-bugs@lists.alioth.debian.org

The paths to "iptables" and "ip" may vary when built on a usrmerge and
non-usrmerge system, and get embedded in /usr/bin/mm-link and possibly
other binaries:

  https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/mahimahi.html

It's a little hard to notice, but I caught these differences in mm-link:

  /sbin/ipH
  vs.
  /usr/sbiH


The attached patch fixes this by passing IPTABLES and IP to configure in
debian/rules. With this patch applied, it should build reproducibly in
our test infrastructure.


Thanks for maintaining mahimahi!


live well,
  vagrant

[0001-debian-rules-Pass-IPTABLES-and-IP-to-configure.patch (text/x-diff, inline)]

From 805c875889c81f89991d46f74f1b9a6e5ffb57a6 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian <vagrant@reproducible-builds.org>
Date: Fri, 18 Dec 2020 20:00:13 +0000
Subject: [PATCH] debian/rules: Pass IPTABLES and IP to configure.

The paths to "iptables" and "ip" may be loated in /sbin and /bin or
/usr/sbin and /usr/bin if the system is configured as a usrmerge
system. Specify the the most compatible locations in /sbin and /bin.

https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 15593d9..d165f59 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,9 @@ DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 %:
 	dh $@ --with autoreconf
 
+override_dh_auto_configure:
+	dh_auto_configure -- IPTABLES=/sbin/iptables IP=/bin/ip
+
 override_dh_fixperms-arch:
 	dh_fixperms
 	chmod 4755 debian/mahimahi/usr/bin/mm-delay
-- 
2.20.1

[signature.asc (application/pgp-signature, inline)]

Message #10 received at submit@bugs.debian.org (full text, mbox, reply):

From: Keith Winstein <keithw@mit.edu>

To: Vagrant Cascadian <vagrant@reproducible-builds.org>, 977684@bugs.debian.org

Cc: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Re: Bug#977684: mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

Date: Fri, 18 Dec 2020 13:45:41 -0800

[Message part 1 (text/plain, inline)]

Thank you for tracking this down! Happy to take the patch -- would you mind
filing this as an upstream pull request at
https://github.com/ravinet/mahimahi ? That way we will have this in one
place when we next have cycles to upload a new mahimahi package.

Sincerely,
Keith

On Fri, Dec 18, 2020 at 12:45 PM Vagrant Cascadian <
vagrant@reproducible-builds.org> wrote:

> Source: mahimahi
> Severity: normal
> Tags: patch
> User: reproducible-builds@lists.alioth.debian.org
> Usertags: usrmerge
> X-Debbugs-Cc: reproducible-bugs@lists.alioth.debian.org
>
> The paths to "iptables" and "ip" may vary when built on a usrmerge and
> non-usrmerge system, and get embedded in /usr/bin/mm-link and possibly
> other binaries:
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/mahimahi.html
>
> It's a little hard to notice, but I caught these differences in mm-link:
>
>   /sbin/ipH
>   vs.
>   /usr/sbiH
>
>
> The attached patch fixes this by passing IPTABLES and IP to configure in
> debian/rules. With this patch applied, it should build reproducibly in
> our test infrastructure.
>
>
> Thanks for maintaining mahimahi!
>
>
> live well,
>   vagrant
>

[Message part 2 (text/html, inline)]

Message #20 received at 977684@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@reproducible-builds.org>

To: keithw@mit.edu, 977684@bugs.debian.org

Subject: Re: Bug#977684: mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

Date: Fri, 18 Dec 2020 15:24:02 -0800

[Message part 1 (text/plain, inline)]

On 2020-12-18, Keith Winstein wrote:
> Thank you for tracking this down! Happy to take the patch -- would you mind
> filing this as an upstream pull request at
> https://github.com/ravinet/mahimahi ? That way we will have this in one
> place when we next have cycles to upload a new mahimahi package.

I'm not sure an "upstream" patch would make sense in this specific case;
in Debian, the most compatible path should be in /bin and /sbin, but
this would not necessarily be the case with all distros, and relying on
the path detection might actually be appropriate in some cases.

So the patch I submitted only modifies debian/rules, not any of the
upstream code.


An upstream fix *might* be to not embed the full paths at all, and rely
a working system PATH, though there may be cases where this does not
work... but I am not familiar enough with mahimahi to know if that would
be workable. The upstream code that triggers this is the use of
AC_PATH_PROG in configure.ac.

For what it's worth, it also embeds the path to other binaries through
AC_PATH_PROG, but many of those don't change on a Debian usrmerge
system.


Happy to dialog a little further to sort this out, and thanks for the
quick response!


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 977684@bugs.debian.org (full text, mbox, reply):

From: Keith Winstein <keithw@mit.edu>

To: Vagrant Cascadian <vagrant@reproducible-builds.org>

Cc: 977684@bugs.debian.org

Subject: Re: Bug#977684: mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

Date: Fri, 18 Dec 2020 15:33:07 -0800

[Message part 1 (text/plain, inline)]

Hi, sorry, I should have clarified that I am also the upstream maintainer,
and I keep the "debian" directory in the same source repository as
everything else. That's what I meant about submitting a pull request on
GitHub. It would still be a modification to debian/rules.

The backstory here is that because those mahimahi programs (mm-link,
mm-delay, mm-onoff, mm-loss, mm-webrecord, mm-webreplay) run setuid root,
we are paranoid about using PATH at runtime. So we try to resolve these
absolute pathnames at build-time. If Debian wants to hardcode the
locations, fine with me.

I am curious -- why is it important that builds be identical between
usrmerge systems and non-usrmerge systems? It's not like we try to have
builds be identical between systems with different versions of the
compiler, etc. Still, though, if this is the notion of reproducibility that
Debian wants its packages to have, I'm happy to comply and have no quibbles
with your patch.

Cheers,
Keith



On Fri, Dec 18, 2020 at 3:24 PM Vagrant Cascadian <
vagrant@reproducible-builds.org> wrote:

> On 2020-12-18, Keith Winstein wrote:
> > Thank you for tracking this down! Happy to take the patch -- would you
> mind
> > filing this as an upstream pull request at
> > https://github.com/ravinet/mahimahi ? That way we will have this in one
> > place when we next have cycles to upload a new mahimahi package.
>
> I'm not sure an "upstream" patch would make sense in this specific case;
> in Debian, the most compatible path should be in /bin and /sbin, but
> this would not necessarily be the case with all distros, and relying on
> the path detection might actually be appropriate in some cases.
>
> So the patch I submitted only modifies debian/rules, not any of the
> upstream code.
>
>
> An upstream fix *might* be to not embed the full paths at all, and rely
> a working system PATH, though there may be cases where this does not
> work... but I am not familiar enough with mahimahi to know if that would
> be workable. The upstream code that triggers this is the use of
> AC_PATH_PROG in configure.ac.
>
> For what it's worth, it also embeds the path to other binaries through
> AC_PATH_PROG, but many of those don't change on a Debian usrmerge
> system.
>
>
> Happy to dialog a little further to sort this out, and thanks for the
> quick response!
>
>
> live well,
>   vagrant
>

[Message part 2 (text/html, inline)]

Message #30 received at 977684@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@reproducible-builds.org>

To: keithw@mit.edu

Cc: 977684@bugs.debian.org

Subject: Re: Bug#977684: mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

Date: Fri, 18 Dec 2020 16:23:25 -0800

[Message part 1 (text/plain, inline)]

On 2020-12-18, Keith Winstein wrote:
> Hi, sorry, I should have clarified that I am also the upstream maintainer,
> and I keep the "debian" directory in the same source repository as
> everything else. That's what I meant about submitting a pull request on
> GitHub. It would still be a modification to debian/rules.

Ah, got it!


> The backstory here is that because those mahimahi programs (mm-link,
> mm-delay, mm-onoff, mm-loss, mm-webrecord, mm-webreplay) run setuid root,
> we are paranoid about using PATH at runtime.

Makes sense.


> So we try to resolve these absolute pathnames at build-time. If Debian
> wants to hardcode the locations, fine with me.

The problem with hard-coding at build time is unfortunately it produces
packages that only work with systems with the same path locations, and
at least on Debian systems, both usrmerge and non-usrmerge systems exist
in the real world.


> I am curious -- why is it important that builds be identical between
> usrmerge systems and non-usrmerge systems?

Because /usr/sbin/iptables is only present on usrmerge systems, if you
hard-code the paths, then it will only work on usrmerge systems. There
are typically compatibility symlinks /sbin -> /usr/sbin, so hard-coding
the other way around is ... less bad... :)


> It's not like we try to have builds be identical between systems with
> different versions of the compiler, etc.

True!

Since the binaries paths might be in either location, we attempt to
detect such situations are part of reproducible builds tests, and it
makes it easier for someone to manually verify a build without having to
know if it is a usrmerge vs. non-usrmerge build environment; e.g. it
ideally builds the same regardless.


> Still, though, if this is the notion of reproducibility that
> Debian wants its packages to have, I'm happy to comply and have no quibbles
> with your patch.


Great! Will submit a merge request soon.


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 977684@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@reproducible-builds.org>

To: keithw@mit.edu

Cc: 977684@bugs.debian.org

Subject: Re: Bug#977684: mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

Date: Sat, 09 Oct 2021 17:50:03 -0700

[Message part 1 (text/plain, inline)]

Control: forwarded 977684 https://github.com/ravinet/mahimahi/pull/147

On 2020-12-18, Vagrant Cascadian wrote:
> On 2020-12-18, Keith Winstein wrote:
>> I am curious -- why is it important that builds be identical between
>> usrmerge systems and non-usrmerge systems?
>
> Because /usr/sbin/iptables is only present on usrmerge systems, if you
> hard-code the paths, then it will only work on usrmerge systems. There
> are typically compatibility symlinks /sbin -> /usr/sbin, so hard-coding
> the other way around is ... less bad... :)
...
>> Still, though, if this is the notion of reproducibility that
>> Debian wants its packages to have, I'm happy to comply and have no quibbles
>> with your patch.
>
>
> Great! Will submit a merge request soon.

Eventually, at least... :)


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #42 received at 977684@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Vagrant Cascadian <vagrant@reproducible-builds.org>, 977684@bugs.debian.org

Cc: keithw@mit.edu

Subject: Re: Bug#977684: mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

Date: Sun, 17 Jul 2022 11:57:25 +0100

Control: severity -1 serious

On Fri, 18 Dec 2020 at 16:23:25 -0800, Vagrant Cascadian wrote:
> The problem with hard-coding at build time is unfortunately it produces
> packages that only work with systems with the same path locations, and
> at least on Debian systems, both usrmerge and non-usrmerge systems exist
> in the real world.

> On 2020-12-18, Keith Winstein wrote:
> > I am curious -- why is it important that builds be identical between
> > usrmerge systems and non-usrmerge systems?
> 
> Because /usr/sbin/iptables is only present on usrmerge systems, if you
> hard-code the paths, then it will only work on usrmerge systems. There
> are typically compatibility symlinks /sbin -> /usr/sbin, so hard-coding
> the other way around is ... less bad... :)

This will be a practical problem as soon as Debian starts using merged-/usr
on official buildds, and the Debian technical committee resolution
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 recommends
treating this class of bug as release-critical for Debian 12, so I'm
raising the severity of this bug.

The problem scenario is:

- build the package on a system where both /sbin/iptables and
  /usr/sbin/iptables exist (merged-/usr)
- install and run the package on a system where only /sbin/iptables exists
  (non-merged-/usr)
- result: the feature that runs iptables will not work

or the equivalent for ip.

Please upload a fixed package before the Debian 12 freeze. Vagrant's patch
looks appropriate.

Thanks,
    smcv

Send a report that this bug log contains spam.