I have only done a quick read but ... this breaks backward compatibility, is it correct? I have no problem with that, but if we break the compatibility I'm going to change the Intent to accept a list of ports instead of just one
El 17 nov. 2016 6:31 p. m., "Hans-Christoph Steiner" < [email protected]> escribió: > > > Yes. Check out our TrustedIntents library for some methods. Also, this > project has some other methods for validating Intents received by a Service: > > https://gitlab.com/fdroid/privileged-extension/ > > .hc > > arrase: > > Is it possible to know which app has sent an Intent service? I'll > > investigate > > > > It seems to me a good method if it is possible to implement it without > > having to ask the app to identify itself. > > > > 2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner < [email protected] > >> : > > > >> > >> I think adding any kind of user interaction is too much complexity. > >> This needs to be entirely transparent to the user, at least to start > >> with. Orbot has no saved state beyond the basic config stuff (e.g. > >> using VPN mode, allowing background starts, etc). So its entirely up to > >> the app to save the Hidden Service key. > >> > >> If an app sends Orbot a private key, it will remember which app sent it, > >> and only allow that exact app to do anything with it. An app can pass > >> around that private key as it wants to. > >> > >> If Orbot generates the private key, then Orbot will send that back to > >> the requesting app, and allow only that app to access it. > >> > >> .hc > >> > >> arrase: > >>> 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] > >>> > >> > >> -- > >> 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] > >> > > > > -- > 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]
