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
signature.asc
Description: PGP signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
