After reviewing the code and learned how to make the changes I think I'll take this a little further.
Keeping the backwards compatibility I will rewrite the configuration preferences of the hidden services and an extension of the existing Intent services. It's a big change that will take me a few days but I think it's the right thing to do. Additionally I have not found a site where are documented the integration options offered by Orbot, for example there is already the option that an application can register a new port hidden by an Intent but I have not known until reading the code despite having searched Information on google. 2016-11-15 23:26 GMT+01:00 Nathan of Guardian <[email protected]>: > As I mentioned in the ticket, you need to run > ndk-build in the > /orbotservice directory to create those native assets first. > > We are working on extracting the native binary build components into a > separate gradle dependency, to make working on the app itself, easier. > For now though, yes, you must build! > > On Tue, Nov 15, 2016, at 01:19 PM, arrase wrote: > > It's hard to build Orbot, I solved several problems with the toolchain > > but > > now I'm stuck here building Tor binary: > > > > zip ../orbotservice/src/main/assets/armeabi/pdnsd.mp3 > > ../orbotservice/src/main/libs/armeabi/pdnsd > > zip warning: name not matched: > > ../orbotservice/src/main/libs/armeabi/pdnsd > > > > zip error: Nothing to do! > > (../orbotservice/src/main/assets/armeabi/pdnsd.mp3) > > > > Is it a known error? > > > > For this case I have not found references in google > > > > > > 2016-11-15 20:14 GMT+01:00 arrase <[email protected]>: > > > > > Great , is all i need to start, many thanks. > > > > > > 2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner < > > > [email protected]>: > > > > > >> > > >> I think it would work like the start/status intents that are currently > > >> in Orbot. The app sends an Intent to Orbot to request a Hidden Service > > >> to be created, then Orbot sends reply status Intents to the app that > > >> made the request with all relevant info, including a FileProvider URI > > >> with GRANT URI permissions so that the requesting app can get the > > >> private key. That'd be the whole API, unless you also want to make a > > >> "stop hidden service" Intent. > > >> > > >> No need to change anything about the control, the whole API would be > > >> based on those Intents, and we can use the TrustedIntents library to > > >> enforce that the reply only goes to the exact app that requested it. > As > > >> a start, it would be fine to send the reply based on packageName. > > >> > > >> .hc > > >> > > >> arrase: > > >> > Are you suggesting something? XD > > >> > > > >> > I can take a look at the problem and propose a solution, it will > not be > > >> > fast but I can do it. > > >> > > > >> > Tonight I will try to compile Orbot from sources and try to > familiarize > > >> > myself with the code. (Is there a wiki with info??) > > >> > > > >> > How do you want to focus the change? What should be possible by a > third > > >> > party? > > >> > > > >> > In my opinion: > > >> > > > >> > - Be able to register a hidden service for your ports without > sharing it > > >> > with other applications. > > >> > - Be able to backup the configuration files in order to migrate the > > >> service. > > >> > - Everything should be possible without root > > >> > > > >> > It would be nice if all this was possible without giving access to > the > > >> Tor > > >> > configuration port, but right now I can not think of how to do it. > > >> > > > >> > I keep thinking ..... after working, I'll dedicate some time to the > > >> problem > > >> > > > >> > > > >> > 2016-11-15 14:19 GMT+01:00 Hans-Christoph Steiner < > > >> [email protected] > > >> >> : > > >> > > > >> >> > > >> >> > > >> >> arrase: > > >> >>> 2016-11-15 13:23 GMT+01:00 Michael Rogers < > [email protected]>: > > >> >>> > > >> >>>> Hi arrase, > > >> >>>> > > >> >>>> Thanks for discovering this bug. Can you describe how Briar's Tor > > >> daemon > > >> >>>> conflicts with Orbot? What problems does it cause? Our goal is > for > > >> Briar > > >> >>>> to be able to operate on the same device as Orbot without > problems. > > >> >>>> > > >> >>>> > > >> >>> I do not think it could be called a bug, and definitely not a > Briar > > >> bug > > >> >> at > > >> >>> all. I find it hard to argue in English, I'm sorry. > > >> >>> > > >> >>> But if it is true that is a problem if more applications follow > the > > >> same > > >> >>> path as Briar implementing a Tor daemon within the application. > > >> >>> > > >> >>> Briar opens those ports for Tor: > > >> >>> > > >> >>> Tcp 0 0 127.0.0.1:59050 0.0.0.0:* LISTEN 10019 214952 18753 > > >> >>> Tcp 0 0 127.0.0.1:59051 0.0.0.0:* LISTEN 10019 213387 18753 > > >> >>> > > >> >>> If Orbot starts first, nothing prevents it from taking ports > 59050 and > > >> >>> 59051 as control ports. It is a remote but real possibility and > would > > >> be > > >> >>> more real when more applications opt for the same solution. > > >> >>> > > >> >>> It's just an argument about changing the hidden service API for > Orbot. > > >> >>> > > >> >>> I think there are more strong arguments like that each > application can > > >> >>> manage the configuration files of the hidden service to be able to > > >> >> migrate > > >> >>> between devices. > > >> >>> > > >> >>> It does not look very good to make an application that uses the > hidden > > >> >>> service as a user identifier and if we lose the device we lose our > > >> entire > > >> >>> network of contacts. > > >> >>> > > >> >>> I think they are good arguments for bringing about an improvement > in > > >> >> Orbot > > >> >>> APi as proposed by Nathan. > > >> >> > > >> >> I think we all want to have a nice Intent-based API in Orbot for > apps > > >> to > > >> >> work with Hidden Services, the real question is: who is going to > do the > > >> >> work. That would be a great place for you to start to get > involved. > > >> >> > > >> >> .hc > > >> >> > > >> >> > > >> >> -- > > >> >> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 > > >> >> https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 > > >> >> _______________________________________________ > > >> >> List info: https://lists.mayfirst.org/ > mailman/listinfo/guardian-dev > > >> >> To unsubscribe, email: guardian-dev-unsubscribe@ > lists.mayfirst.org > > >> >> > > >> > > > >> > > >> -- > > >> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 > > >> https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 > > >> > > > > > > > > _______________________________________________ > > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > > To unsubscribe, email: [email protected] > > > -- > Nathan of Guardian > [email protected] > _______________________________________________ > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > To unsubscribe, email: [email protected] >
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
