Updating to the new style makes sense. I don't know the current hidden API though.
.hc arrase: > Ummm .... when you update an application from the store, you delete a > preference .... although the value is not going to be accessed has not been > erased, right? > > Can we do a routine that after updating look for the configuration of the > old preferences and convert them to the new ones? > > makes sense? > > 2016-11-17 21:23 GMT+01:00 arrase <[email protected]>: > >> No, old ones do not run....must be requested again from the app, i >> complete rewrite the settings , i can't find a way to maintain the old one >> preference setup and the new one screen, has no sense if is put all >> together. >> >> A cursor content provider has more sense for store a big amount of domains >> and with a view adapter is more easy to manage for the user. >> >> El 17 nov. 2016 7:16 p. m., "Nathan of Guardian" < >> [email protected]> escribió: >> >>> Hmm, I may be okay with breaking backward compatibility. I don't think >>> there are that many apps using the existing intent, and it would only be >>> a problem from them to request a new intent (i.e. existing configured >>> onion services would still work, right?) >>> >>> On Thu, Nov 17, 2016, at 09:55 AM, arrase wrote: >>>> 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/mai >>> lman/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=0xE9E28DEA00 >>> AA5556 >>>>>>>>>> _______________________________________________ >>>>>>>>>> List info: https://lists.mayfirst.org/mai >>> lman/listinfo/guardian-dev >>>>>>>>>> To unsubscribe, email: guardian-dev-unsubscribe@lists >>> .mayfirst.org >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Nathan of Guardian >>>>>>>>> [email protected] >>>>>>>>> _______________________________________________ >>>>>>>>> List info: https://lists.mayfirst.org/mai >>> lman/listinfo/guardian-dev >>>>>>>>> To unsubscribe, email: guardian-dev-unsubscribe@lists >>> .mayfirst.org >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> List info: https://lists.mayfirst.org/mai >>> lman/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/mai >>> lman/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]
