[guardian-dev] Hi, i' new

Thu Nov 17 11:42:14 EST 2016

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