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/ > 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: guardian-dev-unsubscribe@ > lists.mayfirst.org > > > >>>> > > > >>>> > > > >>>> -- > > > >>>> Nathan of Guardian > > > >>>> [email protected] > > > >>>> _______________________________________________ > > > >>>> List info: https://lists.mayfirst.org/ > mailman/listinfo/guardian-dev > > > >>>> To unsubscribe, email: guardian-dev-unsubscribe@ > lists.mayfirst.org > > > >>>> > > > >>> > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> 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] > > > >> > > > > > > > > > > -- > > > 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]
