[guardian-dev] Hi, i' new

Nathan of Guardian nathan at guardianproject.info
Thu Nov 17 13:16:36 EST 2016


Hmm, I may be okay with breaking backward compatibility. I don't think
there are that many apps using the existing intent, and it would only be
a problem from them to request a new intent (i.e. existing configured
onion services would still work, right?)

On Thu, Nov 17, 2016, at 09:55 AM, arrase wrote:
> 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
> _______________________________________________
> 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