[Pkg-privacy-maintainers] Bug#902792: torsocks: does not support and fails catastrophically with muliarch

[Hefee]

Hey,

> > Your patch will not work, as $LIB cannot tell what binary arch will be
> > called and do not know anything from multiarch. At least I read the
> > documentation like this.
> 
> The patch gets the core concept right and that's turning the package
> continaing libtorsocks.so M-A:same.

I still don't understand, how this can work. BUt maybe torsocks shell was changed in meanwhile... I now more or less understand the fakeroot approch and will go that path.

> > That one is quite easy:
> > * the lib is already installed at the correct place *check*
> > * all other files are arch independent *check*
> > * the only file we need to care about is /usr/bin/torsocks.
> > I use here the easy solution to move the binary to /usr/bin/$
> > {MULTI_ARCH_TRIPPLET}-torsocks
> 
> That solution is fairly annoying to users as running torsocks no longer
> works. You now have to know what architecture your wrapped executable
> has. That may even be impossible if you wrap an amd64 shell that wants
> to execute an i386 executable.

ACK this is annoying - it was simply the only known solution I knew.


> > Or are you aware of any other solution to make use the correct torsocks
> > script /LD_PRELOAD?
> 
> I'm not sure I fully understand the fakeroot implementation, but the
> general approach also used by eatmydata seems to be installing the
> library directly into /usr/lib/<triplet> without a subdirectory and then
> listing the library name in LD_PRELOAD without the
> architecture-dependent leading directory components. fakeroot does not
> follow this path and instead adds a ld.so.conf.d snippet, but I don't
> think that's any better.

Well as libtorsocks is a internal library, that does not even ship a abi numer ( only .so) I think this should been kept in a own directory. 

The way I see now to get torsocks script ready is:
* change LD_PRELOAD="libtorsocks.so" within torsocks script
* ship a ld.so.conf.d snippet (named torsocks-<tripplet>.conf) within libtorsocks:any
* mark torsocks as Arch:all and M-A:foreign
* get rid of /usr/bin/<tripplet>-torsocks, as they are not needed anymore

=> I tested this on my own laptop and it works ;)

fakeroot does not make it easy to spot onto relevant parts, as it is obvious not 100% multi-arch ready. fakeroot ships a amd64 path within the shell script. In the concequence $ABSLIB at least not work for multi-arch. but this ABSPATH is not used  by default..., because USEABSLIBPATH == 0.

/usr/bin/fakeroot:amd64

#l37
FAKEROOT_LIB=libfakeroot-sysv.so
PATHS=/usr/lib/x86_64-linux-gnu/libfakeroot:${FAKEROOT_PREFIX}/lib64/libfakeroot:${FAKEROOT_PREFIX}/lib32/libfakeroot

#l1113
for dir in `echo $PATHS | sed 's/:/ /g'`
do 
       if test -r "$dir/$FAKEROOT_LIB"
       then 
           libfound=yes
           ABSLIB="$dir/$FAKEROOT_LIB"
       fi
done

regards,

hefee

--

On Mittwoch, 5. März 2025 09:08:48 Mitteleuropäische Normalzeit Helmut Grohne wrote:
> On Wed, Mar 05, 2025 at 12:01:16AM +0100, Hefee wrote:
> > Your patch will not work, as $LIB cannot tell what binary arch will be
> > called and do not know anything from multiarch. At least I read the
> > documentation like this.
> 
> The patch gets the core concept right and that's turning the package
> continaing libtorsocks.so M-A:same.
> 
> > But let's focus on the first step is to get torsocks multi-arch ready, so
> > it can be installed as multi-arch: same.
> 
> Yes, this aspect is part of any solution.
> 
> > That one is quite easy:
> > * the lib is already installed at the correct place *check*
> > * all other files are arch independent *check*
> > * the only file we need to care about is /usr/bin/torsocks.
> > I use here the easy solution to move the binary to /usr/bin/$
> > {MULTI_ARCH_TRIPPLET}-torsocks
> 
> That solution is fairly annoying to users as running torsocks no longer
> works. You now have to know what architecture your wrapped executable
> has. That may even be impossible if you wrap an amd64 shell that wants
> to execute an i386 executable.
> 
> The approach of triplet-prefixing is great for cross building as most of
> the tooling knows the triplet and it merely is a matter of propagating.
> It is not great at all for this use case.
> 
> > @helmut:
> Consider mailing d-cross at l.d.o instead of me. Yeah, the question is not
> the core topic of the list, but it is close enough.
> 
> > But as a enduser I just want to use /usr/bin/torsocks, so I need a wrapper
> > script. I would use the "easy" solution ans just use the main architecture
> > (dpkg --print-architecture), but how to get the multi-arch-name for the
> > main architecture?
> 
> The problem kinda is that there is no "right architecture". In my
> example of calling an amd64 shell that invokes a 32bit binary, neither
> is right.
> 
> > Or are you aware of any other solution to make use the correct torsocks
> > script /LD_PRELOAD?
> 
> I'm not sure I fully understand the fakeroot implementation, but the
> general approach also used by eatmydata seems to be installing the
> library directly into /usr/lib/<triplet> without a subdirectory and then
> listing the library name in LD_PRELOAD without the
> architecture-dependent leading directory components. fakeroot does not
> follow this path and instead adds a ld.so.conf.d snippet, but I don't
> think that's any better.
> 
> Helmut

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-privacy-maintainers/attachments/20250307/e2188d60/attachment.sig>