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]
