<div dir="ltr"><span id="gmail-result_box" class="gmail-" lang="en"><span class="gmail-">After reviewing the code and learned how to make the changes I think I'll take this a little further.</span><br><br><span class="gmail-">Keeping
the backwards compatibility I will rewrite the configuration
preferences of the hidden services and an extension of the existing
Intent services.</span><br><br><span class="gmail-">It's a big change that will take me a few days but I think it's the right thing to do.</span><br><br><span class="gmail-">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</span> <span class="gmail-">Information on google.</span></span><span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-"></span></span></div><div class="gmail_extra"><br><div class="gmail_quote">2016-11-15 23:26 GMT+01:00 Nathan of Guardian <span dir="ltr"><<a href="mailto:nathan@guardianproject.info" target="_blank">nathan@guardianproject.info</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As I mentioned in the ticket, you need to run > ndk-build in the<br>
/orbotservice directory to create those native assets first.<br>
<br>
We are working on extracting the native binary build components into a<br>
separate gradle dependency, to make working on the app itself, easier.<br>
For now though, yes, you must build!<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Nov 15, 2016, at 01:19 PM, arrase wrote:<br>
> It's hard to build Orbot, I solved several problems with the toolchain<br>
> but<br>
> now I'm stuck here building Tor binary:<br>
><br>
> zip ../orbotservice/src/main/<wbr>assets/armeabi/pdnsd.mp3<br>
> ../orbotservice/src/main/libs/<wbr>armeabi/pdnsd<br>
> zip warning: name not matched:<br>
> ../orbotservice/src/main/libs/<wbr>armeabi/pdnsd<br>
><br>
> zip error: Nothing to do!<br>
> (../orbotservice/src/main/<wbr>assets/armeabi/pdnsd.mp3)<br>
><br>
> Is it a known error?<br>
><br>
> For this case I have not found references in google<br>
><br>
><br>
> 2016-11-15 20:14 GMT+01:00 arrase <<a href="mailto:arrase@gmail.com">arrase@gmail.com</a>>:<br>
><br>
> > Great , is all i need to start, many thanks.<br>
> ><br>
> > 2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner <<br>
> > <a href="mailto:hans@guardianproject.info">hans@guardianproject.info</a>>:<br>
> ><br>
> >><br>
> >> I think it would work like the start/status intents that are currently<br>
> >> in Orbot. The app sends an Intent to Orbot to request a Hidden Service<br>
> >> to be created, then Orbot sends reply status Intents to the app that<br>
> >> made the request with all relevant info, including a FileProvider URI<br>
> >> with GRANT URI permissions so that the requesting app can get the<br>
> >> private key. That'd be the whole API, unless you also want to make a<br>
> >> "stop hidden service" Intent.<br>
> >><br>
> >> No need to change anything about the control, the whole API would be<br>
> >> based on those Intents, and we can use the TrustedIntents library to<br>
> >> enforce that the reply only goes to the exact app that requested it. As<br>
> >> a start, it would be fine to send the reply based on packageName.<br>
> >><br>
> >> .hc<br>
> >><br>
> >> arrase:<br>
> >> > Are you suggesting something? XD<br>
> >> ><br>
> >> > I can take a look at the problem and propose a solution, it will not be<br>
> >> > fast but I can do it.<br>
> >> ><br>
> >> > Tonight I will try to compile Orbot from sources and try to familiarize<br>
> >> > myself with the code. (Is there a wiki with info??)<br>
> >> ><br>
> >> > How do you want to focus the change? What should be possible by a third<br>
> >> > party?<br>
> >> ><br>
> >> > In my opinion:<br>
> >> ><br>
> >> > - Be able to register a hidden service for your ports without sharing it<br>
> >> > with other applications.<br>
> >> > - Be able to backup the configuration files in order to migrate the<br>
> >> service.<br>
> >> > - Everything should be possible without root<br>
> >> ><br>
> >> > It would be nice if all this was possible without giving access to the<br>
> >> Tor<br>
> >> > configuration port, but right now I can not think of how to do it.<br>
> >> ><br>
> >> > I keep thinking ..... after working, I'll dedicate some time to the<br>
> >> problem<br>
> >> ><br>
> >> ><br>
> >> > 2016-11-15 14:19 GMT+01:00 Hans-Christoph Steiner <<br>
> >> <a href="mailto:hans@guardianproject.info">hans@guardianproject.info</a><br>
> >> >> :<br>
> >> ><br>
> >> >><br>
> >> >><br>
> >> >> arrase:<br>
> >> >>> 2016-11-15 13:23 GMT+01:00 Michael Rogers <<a href="mailto:michael@briarproject.org">michael@briarproject.org</a>>:<br>
> >> >>><br>
> >> >>>> Hi arrase,<br>
> >> >>>><br>
> >> >>>> Thanks for discovering this bug. Can you describe how Briar's Tor<br>
> >> daemon<br>
> >> >>>> conflicts with Orbot? What problems does it cause? Our goal is for<br>
> >> Briar<br>
> >> >>>> to be able to operate on the same device as Orbot without problems.<br>
> >> >>>><br>
> >> >>>><br>
> >> >>> I do not think it could be called a bug, and definitely not a Briar<br>
> >> bug<br>
> >> >> at<br>
> >> >>> all. I find it hard to argue in English, I'm sorry.<br>
> >> >>><br>
> >> >>> But if it is true that is a problem if more applications follow the<br>
> >> same<br>
> >> >>> path as Briar implementing a Tor daemon within the application.<br>
> >> >>><br>
> >> >>> Briar opens those ports for Tor:<br>
> >> >>><br>
> >> >>> Tcp 0 0 <a href="http://127.0.0.1:59050" rel="noreferrer" target="_blank">127.0.0.1:59050</a> 0.0.0.0:* LISTEN 10019 214952 18753<br>
> >> >>> Tcp 0 0 <a href="http://127.0.0.1:59051" rel="noreferrer" target="_blank">127.0.0.1:59051</a> 0.0.0.0:* LISTEN 10019 213387 18753<br>
> >> >>><br>
> >> >>> If Orbot starts first, nothing prevents it from taking ports 59050 and<br>
> >> >>> 59051 as control ports. It is a remote but real possibility and would<br>
> >> be<br>
> >> >>> more real when more applications opt for the same solution.<br>
> >> >>><br>
> >> >>> It's just an argument about changing the hidden service API for Orbot.<br>
> >> >>><br>
> >> >>> I think there are more strong arguments like that each application can<br>
> >> >>> manage the configuration files of the hidden service to be able to<br>
> >> >> migrate<br>
> >> >>> between devices.<br>
> >> >>><br>
> >> >>> It does not look very good to make an application that uses the hidden<br>
> >> >>> service as a user identifier and if we lose the device we lose our<br>
> >> entire<br>
> >> >>> network of contacts.<br>
> >> >>><br>
> >> >>> I think they are good arguments for bringing about an improvement in<br>
> >> >> Orbot<br>
> >> >>> APi as proposed by Nathan.<br>
> >> >><br>
> >> >> I think we all want to have a nice Intent-based API in Orbot for apps<br>
> >> to<br>
> >> >> work with Hidden Services, the real question is: who is going to do the<br>
> >> >> work. That would be a great place for you to start to get involved.<br>
> >> >><br>
> >> >> .hc<br>
> >> >><br>
> >> >><br>
> >> >> --<br>
> >> >> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556<br>
> >> >> <a href="https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556" rel="noreferrer" target="_blank">https://pgp.mit.edu/pks/<wbr>lookup?op=vindex&search=<wbr>0xE9E28DEA00AA5556</a><br>
> >> >> ______________________________<wbr>_________________<br>
> >> >> List info: <a href="https://lists.mayfirst.org/mailman/listinfo/guardian-dev" rel="noreferrer" target="_blank">https://lists.mayfirst.org/<wbr>mailman/listinfo/guardian-dev</a><br>
> >> >> To unsubscribe, email: <a href="mailto:guardian-dev-unsubscribe@lists.mayfirst.org">guardian-dev-unsubscribe@<wbr>lists.mayfirst.org</a><br>
> >> >><br>
> >> ><br>
> >><br>
> >> --<br>
> >> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556<br>
> >> <a href="https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556" rel="noreferrer" target="_blank">https://pgp.mit.edu/pks/<wbr>lookup?op=vindex&search=<wbr>0xE9E28DEA00AA5556</a><br>
> >><br>
> ><br>
> ><br>
> ______________________________<wbr>_________________<br>
> List info: <a href="https://lists.mayfirst.org/mailman/listinfo/guardian-dev" rel="noreferrer" target="_blank">https://lists.mayfirst.org/<wbr>mailman/listinfo/guardian-dev</a><br>
> To unsubscribe, email: <a href="mailto:guardian-dev-unsubscribe@lists.mayfirst.org">guardian-dev-unsubscribe@<wbr>lists.mayfirst.org</a><br>
<br>
<br>
--<br>
</div></div><span class="HOEnZb"><font color="#888888"> Nathan of Guardian<br>
<a href="mailto:nathan@guardianproject.info">nathan@guardianproject.info</a><br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
List info: <a href="https://lists.mayfirst.org/mailman/listinfo/guardian-dev" rel="noreferrer" target="_blank">https://lists.mayfirst.org/<wbr>mailman/listinfo/guardian-dev</a><br>
To unsubscribe, email: <a href="mailto:guardian-dev-unsubscribe@lists.mayfirst.org">guardian-dev-unsubscribe@<wbr>lists.mayfirst.org</a><br>
</div></div></blockquote></div><br></div>