Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_SERVICE), I've extended it to maintain backward compatibility.
I'm going to add another Intent to manage the small security layer that I'm adding when exporting the key of a service for its backup. Once the permission for export the key is denied, only the user can re-grant it from the main application. The major picture is done, now i'm adding: - A way for import/export the configuration of a hidden service in zip fromat (UI and Intent service versions) - A way for delete a hidden service (UI and Intent service versions) - Intent for disallowing backup of the service. 2016-11-17 15:47 GMT+01:00 Nathan of Guardian <[email protected]>: > As Arrase point out though, there is an undocumented intent. This is > what we use for CameraV currently. I think making it official, expanding > it, and adding it into NetCipher makes a great deal of sense. > > On Thu, Nov 17, 2016, at 12:37 AM, Hans-Christoph Steiner wrote: > > > > 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] > > > -- > 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]
