Use IPtProxy

changed milestone to %Sponsor 101 - Tor VPN Client for Android

added Next Q2 labels

marked this issue as related to #2 (closed)

cc @meskio @shelikhoo @itchyonion @cohosh We should have a conversation about this.

I haven't review IPtProxy, but it might make sense to work with orbot on adapting IPtProxy to our needs. Actually have few things to solve in our side to make their life easier.

Kind of related to this, arti is starting to implement PTs and we did talk a bit about binding PTs into arti as a library (tpo/core/arti#69 (comment 2780215)). Is not going to come in the first arti-PT implementation, but can be included in future.

I'm happy to join a meeting about it and discuss it.

Yes. Using a dynamic library is unavoidable on iOS, but we have so far been able to avoid this on the Android platform. Mobile platforms have been particularly problematic for the lack of a stable programming interface compared to the Linux kernel's no regression policy.

I would be happy to join the meeting and discuss about it.

Hi, I'm the author and maintainer of IPtProxy and a member of Guardian Project.

I wonder what adaptions you might need?

added Q3 label and removed Q2 label

From what I understand, and please someone correct me if I'm wrong, but there is nothing that needs to be done here specifically for the TorVPN.

The original issue was oriented around Tor Browser's use of IPtProxy as a stand-alone executable and how this might be a problem for Android and a library should be used instead. However, IPtProxy can already be used as a library, in fact it is already used as a library in Bitmask/RiseupVPN, and the Guardian Project uses it as a library for Orbot, so there is no work that has to be done to turn it into a library as it already functions as one.

From the original issue description, it says "Who should maintain and be responsible for it" -- I think that is already clear and answered by @tla in the previous response here

Possibly Tor Browser might be interested in using this as a library, instead of a stand-alone application, but that would be outside the scope of tor-vpn.

Additionally, the anti-censorship team is not using IPtProxy (yet?), and did have some conversations a long time ago with Guardian Project and fixed some issues that were happening in snowflake (I believe). There may be some additional painpoints there, and it would be good for AC to address them at some point. I believe the issue there is that IPtProxy has some patches to snowflake to be able to use it in IPtProxy, and it would be good to figure out how to remove those patches and use the snowflake library instead. However, this also would be outside the scope of tor-vpn itself.

With all of that said, I would argue that this issue should be closed, or at the least, removed from the %Sponsor 101 - Tor VPN Client for Android milestone. @richard can you make a determination here?

I believe the issue there is that IPtProxy has some patches to snowflake to be able to use it in IPtProxy, and it would be good to figure out how to remove those patches and use the snowflake library instead.

There's still too much code in the snowflake.go file (which contains main()), which I need and don't want to double. It's easier to maintain the patch instead of watching out to keep copied code in sync.

Once that is refactored, I can let go of the patch.

added Guardian Project Needs Information labels

I think until arti supports PTs as first-class citizens (eg. a rust PT library, the necessary primitives, and crates to turn things into first-class citizens around arti), then current PTs will need to work with arti. That would mean making modifications to IPTProxy so that it will interface with what arti will provide for the intermediate interface for PTs so things (like TorVPN) can use PTs until the arti situation evolves PTs into first-class support.

This is the same trajectory as netcipher will probably take, as indicated in #15 (closed)

changed milestone to %Sponsor 101 - Tor VPN Client for Android

removed Q3 label

removed Next label

added Roadmap::Future label

closed

Can I ask why this was closed?

Of course you can! In fact, I should have included a message when I did that. I closed this for two reasons:

This issue seemed to be around TBB's use of IPTProxy, and not related to TorVPN.
The original issue was oriented around Tor Browser's use of IPtProxy as a stand-alone executable and how this might be a problem for Android and a library should be used instead. However, IPtProxy can already be used as a library

The combination of those two made me think that this issue was mis-filed and not actually an issue.

However, I understand that is did spawn some additional discussion because the anti-censorship (@meskio) team and @tla have some outstanding diffs that need reconciling, but that also seemed quite out of scope for this issue, and if that is still an issue, that maybe should be tracked in a different issue/project.

However, I've been known to be wrong, misunderstand, or miss completely obvious things, so if I didn't get something here let me know.

I created an issue on snowflake side to move forward the missing pieces needed by IPtPRoxy: tpo/anti-censorship/pluggable-transports/snowflake#40218 (closed)

I'm not sure I'll be able to push it much right now, but let's not forget it.

Thanks for the updates. The basic expectation/hope/request still stands - for Tor-VPN to "Use IPtProxy" as stated in the title. Is there another ticket tracking that?

@n8fr8 I made this ticket to track its integration into onionmasq: tpo/core/onionmasq#21 (closed)

marked this issue as related to tpo/core/onionmasq#21 (closed)

mentioned in issue tor-browser-build#41010

Use IPtProxy

Designs

Child items ...

Activity