[guardian-dev] Hi, i' new

Thu Nov 17 03:37:18 EST 2016

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