[guardian-dev] Hi, i' new

arrase arrase at gmail.com
Thu Nov 17 17:36:42 EST 2016


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=
> 0xE9E28DEA00AA5556
> >>>>>>>>> _______________________________________________
> >>>>>>>>> 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
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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/7b9fce10/attachment-0001.html>


More information about the guardian-dev mailing list