[guardian-dev] Hi, i' new

arrase arrase at gmail.com
Thu Nov 17 15:23:50 EST 2016


No, old ones do not run....must be requested again from the app, i complete
rewrite the settings , i can't find a way to maintain the old one
preference setup and the new one screen, has no sense if is put all
together.

A cursor content provider has more sense for store a big amount of domains
and with a view adapter is more easy to manage for the user.

El 17 nov. 2016 7:16 p. m., "Nathan of Guardian" <
nathan at guardianproject.info> escribió:

> 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@
> 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@
> 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@
> lists.mayfirst.org
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> 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
> > > >>
> > > >
> > >
> > > --
> > > 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/6ef805fa/attachment-0001.html>


More information about the guardian-dev mailing list