The documentation is mostly in the form of javadoc strings in the NetCipher library, since that's the usual developer interface to this stuff. Otherwise, there is a little bit here:
https://guardianproject.info/code There isn't yet any official way to request a Hidden Service as of now. .hc arrase: > 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] > -- 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]
