[tor-dev] Re: Make torsocks mutli-arch ready

2025-03-26 Thread Hefee via tor-dev
Hey,

> This looks basically ok to me. More below:

thx for this fast reply! Sorry I'm a little bit busy the last days...

Btw. would it be possible to ship a new release the next days? So I can push 
this new version to Debian trixie? As the soft freeze is happening at 15. 
April. 

> > But the torsocks script loads the libtorsocks by full path, so
> > torsocks wget will fail, as it loads the amd64 variant only.
> > ldconfig has this nice feature to find the correct library, if you only
> > add the name and that the library is in default search dir or you add a
> > conf file in / etc/ld.so.conf.d/.
> 
> Maybe we could be a *little* more explicit and use a full path
> incorporating `${LIB}`? From ld.so(8):
> [...]

I see your point, but unfortunately it is not only lib64 vs. lib directory, as 
Debian uses the different arch trippets for their lib paths. As you also want 
different arm archs e.g.
 /usr/lib/x86_64-linux-gnu/ 
and 
 /usr/lib/i386-linux-gnu/

for the complete list see 
https://wiki.debian.org/Multiarch/Tuples

> This might head off some other weird corner cases (like some other
> `libtorsocks` ending up earlier in the library search path) and maybe
> give a stronger hint about what's going wrong in the error message you
> note below where the right library can't be found.

I see your point you are thinking at a warning like:
You  enabled those archs but missing libtorsoks for following archs: X, Y, Z

I don't know if that is easy possible but I'll ask for help on Debian side.

> > #902792 https://bugs.debian.org/cgi-bin/902792
> 
> This is an unfortunate failure mode, but yeah at least not worse than
> the current state.
> 
> I was thinking about whether the torsocks script could try harder to
> detect this case, e.g. by itself checking what arch binary is being run
> and whether the corresponding library exists, but this would add a fair
> bit of complexity and would still miss cases where the target binary
> spawns more processes, possibly of different archs (e.g. `torsocks bash
> -c "wget ..."`)

Yes it would be nice, if torsocks could detect the arch correctly, but I also 
thought at these complications about subprocesses.

Regards,

hefee

signature.asc
Description: This is a digitally signed message part.
___
tor-dev mailing list -- tor-dev@lists.torproject.org
To unsubscribe send an email to tor-dev-le...@lists.torproject.org


[tor-dev] Make torsocks mutli-arch ready

2025-03-10 Thread Hefee via tor-dev
Hey,

in Debian we want to enable mutli-arch support for torsocks. To be able to run 
different binaries of different archs.
We already splitted libtorsocks into own package, so you can now install
e.g.: torsocks:amd64, libtorsocks:amd64, libtorsocks:i386, wget:i386

But the torsocks script loads the libtorsocks by full path, so
torsocks wget will fail, as it loads the amd64 variant only. 
ldconfig has this nice feature to find the correct library, if you only add the 
name and that the library is in default search dir or you add a conf file in /
etc/ld.so.conf.d/.

Using just the libname makes the "safty" check `! -e "$SHLIB"` fail, as 
$SHLIB, is only the libname in our case.

Can you have a look at the patch[1], if you think it is safe to ship this?
[1] https://salsa.debian.org/pkg-privacy-team/torsocks/-/blob/master/debian/
patches/0004-Make-torsocks-multi-arch-foreign-compatible.patch

The issue I see is this:
If arch from executable and the corresponding libtorsocks is not installed, 
only a Error is printed, but still the executable is executed without routing 
trough tor. The disabled check in torsocks could somehow catch this, if we 
would knew the arch of the executable in advanced correctly (which we don't, 
so far). If we can make sure, that LD_PRELOAD would stop executing, if the 
library cannot be found.

e.g. I install libtorsocks:amd64 and wget:i386 I get:
$wget -O- -4 icanhazip.com
XX.230.187.XX
$ torsocks wget -O- -4 icanhazip.com
ERROR: ld.so: object 'libtorsocks.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
[...]
XX.230.187.XX
[...]

(installing libtorsocks:i386 fixes this)

On the other side, this does not got worse; currently torsocks will print 
a different error see #902792 but still execute the binary without tor. So this 
safety check doesn't help here (and btw. installing libtorsocks:i386 does not 
fix this issue by itself you also need to call /usr/bin/i386-linux-gnu-
torsocks). 

#902792 https://bugs.debian.org/cgi-bin/902792

Regards,

hefee


signature.asc
Description: This is a digitally signed message part.
___
tor-dev mailing list -- tor-dev@lists.torproject.org
To unsubscribe send an email to tor-dev-le...@lists.torproject.org


[tor-dev] Re: Make torsocks mutli-arch ready

2025-03-27 Thread Hefee via tor-dev
Hey,

> Ah, I was just looking for who to talk to about this. We actually just
> released 2.5.0 today :)
> 
> https://gitlab.torproject.org/tpo/core/torsocks/-/releases/v2.5.0

Great. On Debian side we have scripts that scan for new releases 
automatically. But I do not check those pages on a daily basis ;) So in case 
if it not a time critical, we get the information about a new release without 
any need from your side to inform me :)

Regards

hefee

signature.asc
Description: This is a digitally signed message part.
___
tor-dev mailing list -- tor-dev@lists.torproject.org
To unsubscribe send an email to tor-dev-le...@lists.torproject.org