* 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.
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
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. 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