[guardian-dev] Hi, i' new
arrase
arrase at gmail.com
Thu Nov 17 15:28:59 EST 2016
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 <arrase at gmail.com>:
> 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" <
> nathan at guardianproject.info> 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" <
>> > hans at guardianproject.info> 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 <
>> > hans at guardianproject.info
>> > > >> :
>> > > >
>> > > >>
>> > > >> 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 <
>> > > >> nathan at guardianproject.info>:
>> > > >>>
>> > > >>>> 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 <
>> > > >>>> nathan at guardianproject.info>:
>> > > >>>>>>
>> > > >>>>>>> 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 <arrase at gmail.com>:
>> > > >>>>>>>>
>> > > >>>>>>>>> Great , is all i need to start, many thanks.
>> > > >>>>>>>>>
>> > > >>>>>>>>> 2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner <
>> > > >>>>>>>>> hans at guardianproject.info>:
>> > > >>>>>>>>>
>> > > >>>>>>>>>>
>> > > >>>>>>>>>> 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 <
>> > > >>>>>>>>>> hans at guardianproject.info
>> > > >>>>>>>>>>>> :
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> arrase:
>> > > >>>>>>>>>>>>> 2016-11-15 13:23 GMT+01:00 Michael Rogers <
>> > > >>>>>>> michael at briarproject.org>:
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> 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:
>> > guardian-dev-unsubscribe at lists.mayfirst.org
>> > > >>>>>>>
>> > > >>>>>>>
>> > > >>>>>>> --
>> > > >>>>>>> Nathan of Guardian
>> > > >>>>>>> nathan at guardianproject.info
>> > > >>>>>>> _______________________________________________
>> > > >>>>>>> List info:
>> > https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>> > > >>>>>>> To unsubscribe, email:
>> > guardian-dev-unsubscribe at lists.mayfirst.org
>> > > >>>>>>>
>> > > >>>>>>
>> > > >>>>>>
>> > > >>>>>>
>> > > >>>>>> _______________________________________________
>> > > >>>>>> List info: https://lists.mayfirst.org/mai
>> lman/listinfo/guardian-dev
>> > > >>>>>> To unsubscribe, email: guardian-dev-unsubscribe at 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 at lists
>> .mayfirst.org
>> > > >>>>
>> > > >>>>
>> > > >>>> --
>> > > >>>> Nathan of Guardian
>> > > >>>> nathan at guardianproject.info
>> > > >>>> _______________________________________________
>> > > >>>> List info: https://lists.mayfirst.org/mai
>> lman/listinfo/guardian-dev
>> > > >>>> To unsubscribe, email: guardian-dev-unsubscribe at lists
>> .mayfirst.org
>> > > >>>>
>> > > >>>
>> > > >>>
>> > > >>>
>> > > >>> _______________________________________________
>> > > >>> List info: https://lists.mayfirst.org/mai
>> lman/listinfo/guardian-dev
>> > > >>> To unsubscribe, email: guardian-dev-unsubscribe at 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 at 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 at lists.mayfirst.org
>>
>>
>> --
>> Nathan of Guardian
>> nathan at guardianproject.info
>> _______________________________________________
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>> To unsubscribe, email: guardian-dev-unsubscribe at lists.mayfirst.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20161117/6fc32910/attachment-0001.html>
More information about the guardian-dev
mailing list