[guardian-dev] Hi, i' new
Nathan of Guardian
nathan at guardianproject.info
Thu Nov 17 09:47:06 EST 2016
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
More information about the guardian-dev
mailing list