[guardian-dev] Hi, i' new

arrase arrase at gmail.com
Wed Nov 16 18:38:35 EST 2016


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20161117/d2ed89ee/attachment.html>


More information about the guardian-dev mailing list