[guardian-dev] Hi, i' new
arrase
arrase at gmail.com
Sun Nov 20 10:17:23 EST 2016
I'm confused about Orbot permission management.
Orbot needs several permission like WRITE_EXTERNAL_STORAGE but there is no
code related to the new runtime permissions api.
When i try to do a backup to the external storage it fails because i need
to request permissions but...
How have permissions worked until today? i have to implement the request to
the new api in OrbotMainActivity if
Build.VERSION.SDK_INT>Build.VERSION_CODES.LOLLIPOP_MR1???
2016-11-17 23:36 GMT+01:00 arrase <arrase at gmail.com>:
> Then you can implement TOFU in a simpler way and with backwards
> compatibility, nice, I will implement it
>
> El 17 nov. 2016 11:31 p. m., "Hans-Christoph Steiner" <
> hans at guardianproject.info> escribió:
>
>>
>> The idea is to do Trust-On-First-Use (TOFU) with TrustedIntents, not to
>> use the pin. Basically, use the same technique to verify the
>> packagename and signing key are trusted, but store the values on the
>> first use, rather than have it built into the app. I forget off the top
>> of my head whether that is fully implemented in TrustedIntents, but if
>> not, it shouldn't be hard to do.
>>
>> .hc
>>
>> arrase:
>> > I have read about TrustedIntents, as a concept is good but if as
>> > Hans-Christoph said to make the user have to do too many interactions is
>> > not good, and implementing TrustedIntents in its current state requires
>> the
>> > user to use an application (Checkey) To get the pin.
>> >
>> > Too much work for the user.
>> >
>> > I will do something that is simpler, provide sufficient security and
>> > backwards compatible.
>> >
>> > ....thinking in progress.....
>> >
>> > 2016-11-17 22:06 GMT+01:00 Hans-Christoph Steiner <
>> hans at guardianproject.info
>> >> :
>> >
>> >>
>> >> Updating to the new style makes sense. I don't know the current hidden
>> >> API though.
>> >>
>> >> .hc
>> >>
>> >> arrase:
>> >>> 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=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/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/20161120/b8ea607d/attachment-0001.html>
More information about the guardian-dev
mailing list