1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1105868: ITP: oniux -- Kernel-level Tor isolation for any Linux app

    From Yifei Zhan@21:1/5 to All on Fri May 16 14:30:01 2025
    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)
  • From NoisyCoil@21:1/5 to All on Sun May 18 19:10:07 2025
    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)
  • From Yifei Zhan@21:1/5 to All on Mon May 19 06:50:01 2025
    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)
  • From NoisyCoil@21:1/5 to Yifei Zhan on Mon May 19 20:10:01 2025
    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)