[guardian-dev] Hi, i' new
arrase
arrase at gmail.com
Thu Nov 17 16:06:34 EST 2016
this should fix the issue
private void migratePreferences(){
String hsPortString = mPrefs.getString("pref_hs_ports", "");
if(hsPortString.length() > 0)
{
StringTokenizer st = new StringTokenizer (hsPortString,",");
ContentResolver cr = getContentResolver();
while (st.hasMoreTokens())
{
int hsPort = Integer.parseInt(st.nextToken().split(" ")[0]);
ContentValues fields = new ContentValues();
fields.put("name", hsPort);
fields.put("port", hsPort);
fields.put("onion_port", hsPort);
cr.insert(HSContentProvider.CONTENT_URI, fields);
}
Editor pEdit = mPrefs.edit();
pEdit.remove("pref_hs_ports");
pEdit.commit();
}
}
2016-11-17 21:28 GMT+01:00 arrase <arrase at gmail.com>:
> Ummm .... when you update an application from the store, you delete a
> preference .... although the value is not going to be accessed has not been
> erased, right?
>
> Can we do a routine that after updating look for the configuration of the
> old preferences and convert them to the new ones?
>
> makes sense?
>
> 2016-11-17 21:23 GMT+01:00 arrase <arrase at gmail.com>:
>
>> 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/mai
>>> lman/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=0xE9E28DEA00
>>> AA5556
>>> > > >>>>> _______________________________________________
>>> > > >>>>> List info: https://lists.mayfirst.org/mai
>>> lman/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/mai
>>> lman/listinfo/guardian-dev
>>> > > >>>> To unsubscribe, email: guardian-dev-unsubscribe at lists
>>> .mayfirst.org
>>> > > >>>>
>>> > > >>>
>>> > > >>>
>>> > > >>>
>>> > > >>> _______________________________________________
>>> > > >>> List info: https://lists.mayfirst.org/mai
>>> lman/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=0xE9E28DEA00
>>> AA5556
>>> > > >> _______________________________________________
>>> > > >> List info: https://lists.mayfirst.org/mai
>>> lman/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/f5ab089b/attachment-0001.html>
More information about the guardian-dev
mailing list