Embedded buildpath via rpath using cmake

[Vagrant Cascadian]

On 2022-02-04, Seth Arnold wrote:
> On Thu, Feb 03, 2022 at 04:41:21PM -0800, Vagrant Cascadian wrote:
>> Over the last several months, I and others have found quite a few
>> packages that embed build paths via rpath when building with cmake.  I
>> found myself slowly edging into a mass bug filing, one bug report at a
>> time...
>
> Hello Vagrant, does this represent a security problem?

Other than reproducible builds in general providing some security
properties, I would say not really.


> I tried to give this a look myself but didn't know what to look for; I
> grabbed a few recent versions of packages:
>
> http://ftp.debian.org/debian/pool/main/n/nfs-ganesha/nfs-ganesha_3.4-1_amd64.deb

One thing is checking the reproducible builds results:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/nfs-ganesha.html

Which appear to have reproducibility issues in the unstable tests, where
build paths are varied, but not in bookworm, where build paths are not
varied.

Unfortunately, the diffoscope output linked above does not obviously
show the build path embedded in the binaries (other than some .py files,
which may be a separate issue).

There are a few lines which are non-obvious, but are in my experience a
sign of different build paths:

  0x000000000000000a·(STRSZ)··············2327·(bytes)
vs.
  0x000000000000000a·(STRSZ)··············2329·(bytes)

My going theory is that the length of the build path is embedded in a
padded value, even though the build path itself is actually stripped,
perhaps via -ffile-prefix-map=BUILDPATH=. or similar.


> http://ftp.debian.org/debian/pool/main/v/vmemcache/libvmemcache0_0.8.1-4_amd64.deb
> http://ftp.debian.org/debian/pool/main/f/fontforge/fontforge_20201107~dfsg-4_amd64.deb
>
> $ find . -type f -exec eu-readelf -d {} \; 2>/dev/null | grep RUNPATH
>   RUNPATH           Library runpath: [/usr/lib/ganesha]
>   RUNPATH           Library runpath: [/usr/lib/ganesha]
>   RUNPATH           Library runpath: [/usr/lib/ganesha]
>   RUNPATH           Library runpath: [/usr/lib/ganesha]
>
> Am I on the wrong track?

Because it doesn't often leave obvious traces of the build path in the
binaries, it is a bit tricky to test simply by examining the binaries
directly... Instead, experimentation seems to be the best way.

I use reprotest for this, first running a build with reprotest without
the patch, confirming that it builds at all, and does not build
reproducibly. Then running reprotest with the patch applied to add
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON in debian/rules, and seeing if it
builds reproducibly.

From the source directory, with the build dependencies installed:

  reprotest --verbose --store-dir=$(mktemp -d $HOME/buildresults-XXXXXX) --vary=-all,+build_path -- null


This should normalize the build as much as possible so that the only
thing different between the two builds is the build path.

Then compare the resulting buildresults-*/*.out to see if the second
build produces significantly less diffoscope output...


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20220204/74e40eee/attachment.sig>