[guardian-dev] Hi, i' new

Hans-Christoph Steiner hans at guardianproject.info
Thu Nov 17 12:31:41 EST 2016 

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/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
>>>>> _______________________________________________
>>>>> 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
>> _______________________________________________
>> 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