[guardian-dev] Hi, i' new

Thu Nov 17 17:31:07 EST 2016

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