XPost: linux.debian.devel

Package: wnpp
Severity: wishlist
Owner: Yifei Zhan <debian@zhan.science>
X-Debbugs-Cc: debian-devel@lists.debian.org, debian@zhan.science

* Package name : oniux
Version : 0.4.0
* URL : https://gitlab.torproject.org/tpo/core/oniux
* License : MIT OR Apache-2.0
Programming Lang: Rust
Description : Kernel-level Tor isolation for any Linux app

oniux is a small command-line utility providing Tor network isolation for third-party applications using Linux namespaces. It isolates any Linux program into its own network namespace to route it through Tor and strips away the potential for data leaks.

See this post for more info: https://blog.torproject.org/introducing-oniux-tor-isolation-using-linux- namespaces/

This can be considered as an upcoming, more robust replacement for torsocks. Interestingly, it uses the relatively new Arti as its Tor engine, which would benefit from more testing. At the moment this is still experimental software in a sense that it's new, but it's already functional and I'd like to get more users to test it. I'd like to maintain it within the Debian Rust team.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Yifei,

Since oniux depends on arti crates [1] via onion-tunnel [2], I think
before packaging it we should have a clear way forward for packaging
arti -- or at least, if not the application itself, most of its
libraries. I discussed this with upstream last summer and we agreed it
was better, for the time being, to package arti outside of Debian [3].
We should resume that conversation before starting to package oniux.

For the record, I still have a branch locally with all the dependencies required to package arti. It's a huge amount of work (~70-80 crates last
year, will be less now, and not all of them may be needed for oniux),
I'm happy to help and share it :-)

Cheers!


[1] https://gitlab.torproject.org/tpo/core/arti/-/blob/main/Cargo.toml
[2] https://gitlab.torproject.org/tpo/core/onionmasq/-/blob/main/crates/onion-tunnel/Cargo.toml
[3] https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2323

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, May 18, 2025 4:57:15 PM Coordinated Universal Time you wrote:

Hi Yifei,

Since oniux depends on arti crates [1] via onion-tunnel [2], I think
before packaging it we should have a clear way forward for packaging
arti -- or at least, if not the application itself, most of its
libraries. I discussed this with upstream last summer and we agreed it
was better, for the time being, to package arti outside of Debian [3].
We should resume that conversation before starting to package oniux.

Agree, upon a closer look arti is indeed a complex beast and I have doubt in its long-term maintainability with our current workflow considering that it's more security-critical than most other crates we maintain. It's probably better to get the upstream involved early.

For the record, I still have a branch locally with all the dependencies required to package arti. It's a huge amount of work (~70-80 crates last year, will be less now, and not all of them may be needed for oniux),
I'm happy to help and share it :-)

Could you please put that branch somewhere? Maybe on Salsa, I'd like to see what scale we are dealing with. Honestly I'm not sure if we have enough bandwidth within Debian to keep them secure and up-to-date in the long run....

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/05/25 06:36, Yifei Zhan wrote:

Could you please put that branch somewhere? Maybe on Salsa, I'd like to see what scale we are dealing with. Honestly I'm not sure if we have enough bandwidth within Debian to keep them secure and up-to-date in the long run....

See [1]. They're 50 deps. The remaining 20-30 I remember were probably
inside arti's workspace (I first went with a per-crate packaging, then
switched to using the arti workspace as a whole). An arti workspace
draft only packaging the application (i.e. no libs) is at [2]. This is
from about one year ago, so keep in mind I'm giving you very outdated information. Even the upstream package I worked on is more polished than
[2].

I don't think the biggest issue is one of bandwidth. I think there's an
issue of tooling and an issue of stability. For the tooling, I would say
we need support for suite branches in debcargo-conf so we're able to
push security updates more easily. Still, there's a limit beyond which
it's very difficult to go with stable updates. For instance, what
happens when upstream updates to clap 5 eventually and we have to
introduce tens of packages in stable to provide a security update, if
these are only pushed to the last release? To properly deal with
security, I believe upstream should probably provide LTS releases (when
they feel they're ready to do so). Unfortunately, this is easier said
than done as it's very hard to guarantee that their dependencies would
have the same level of support.


[1] https://salsa.debian.org/NoisyCoil/debcargo-conf/-/commits/package-arti-deps [2] https://salsa.debian.org/NoisyCoil/arti

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)