Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add ClientTransportPlugin Interface #46

Open
cyBerta opened this issue Jul 12, 2021 · 2 comments
Open

add ClientTransportPlugin Interface #46

cyBerta opened this issue Jul 12, 2021 · 2 comments

Comments

@cyBerta
Copy link

cyBerta commented Jul 12, 2021

I'm currently integrating IPtProxy into a fork of tor-android, so that I can easily run tor over snowflake using tor-android.
I wonder if it is of interest for this project to contribute back these little changes.

Instead of adding the IPtProxy to tor-android, I chose to add an interface containing start(), stop() and getTorrc(). Library users can implement this interface to inject a ClientTransportPlugin, to start the ClientTransportPlugin before tor starts, to stop it accordingly and to define the necessary torrc string.

All that is still WIP, but you can have a look at https://0xacab.org/leap/android_libs/tor-android/-/blob/main/tor-android-binary/src/main/java/org/torproject/jni/TorService.java and https://0xacab.org/leap/android_libs/tor-android/-/blob/main/tor-android-binary/src/main/java/org/torproject/jni/ClientTransportPluginInterface.java

Feel free to close this ticket if you think it's not worth a PR.

@n8fr8
Copy link
Member

n8fr8 commented Jul 12, 2021

We are working on our own pluggable mechanism to do this. You would install a separate Snowflake-PT APK, that the TorServices/tor-android library would discover, launch and link into. Our goal ultimately is to allow for truly pluggable PT's, and not compiling in a specific dependency.

That said, I'll take a look at your approach and see how it might integrate with what we have planned.

@cyBerta
Copy link
Author

cyBerta commented Jul 12, 2021

Thanks for your fast response and for taking time to look at the proposed change.

Our goal ultimately is to allow for truly pluggable PT's, and not compiling in a specific dependency

That sounds reasonable and and on the library level this goal is met with the proposal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants