[guardian-dev] Hi, i' new
arrase
arrase at gmail.com
Thu Nov 17 12:55:08 EST 2016
I have only done a quick read but ... this breaks backward compatibility,
is it correct? I have no problem with that, but if we break the
compatibility I'm going to change the Intent to accept a list of ports
instead of just one
El 17 nov. 2016 6:31 p. m., "Hans-Christoph Steiner" <
hans at guardianproject.info> escribió:
>
>
> Yes. Check out our TrustedIntents library for some methods. Also, this
> project has some other methods for validating Intents received by a
Service:
>
> https://gitlab.com/fdroid/privileged-extension/
>
> .hc
>
> arrase:
> > Is it possible to know which app has sent an Intent service? I'll
> > investigate
> >
> > It seems to me a good method if it is possible to implement it without
> > having to ask the app to identify itself.
> >
> > 2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner <
hans at guardianproject.info
> >> :
> >
> >>
> >> I think adding any kind of user interaction is too much complexity.
> >> This needs to be entirely transparent to the user, at least to start
> >> with. Orbot has no saved state beyond the basic config stuff (e.g.
> >> using VPN mode, allowing background starts, etc). So its entirely up
to
> >> the app to save the Hidden Service key.
> >>
> >> If an app sends Orbot a private key, it will remember which app sent
it,
> >> and only allow that exact app to do anything with it. An app can pass
> >> around that private key as it wants to.
> >>
> >> If Orbot generates the private key, then Orbot will send that back to
> >> the requesting app, and allow only that app to access it.
> >>
> >> .hc
> >>
> >> arrase:
> >>> 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
> >>>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >
>
> --
> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556
> https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20161117/3fdd678c/attachment-0001.html>
More information about the guardian-dev
mailing list