[guardian-dev] Hi, i' new
arrase
arrase at gmail.com
Thu Nov 17 11:11:29 EST 2016
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20161117/f8961011/attachment-0001.html>
More information about the guardian-dev
mailing list