[guardian-dev] Hi, i' new

Hans-Christoph Steiner hans at guardianproject.info
Thu Nov 17 16:06:19 EST 2016


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 <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
>>>
>>
> 
> 
> 
> _______________________________________________
> List info: https://lists.mayfirst.org/mailman/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


More information about the guardian-dev mailing list