Ok, permissions are working, and the backup creation feature works nice. There is only one thing to do, a way for a restore the backup.
But there is a problem, i'm very bad building layotus, i mean, my layouts are always ugly as hell. So, if someone can build Orbot from the new brach and take a look to the job for suggest a better look for the layouts the help will be appreciated. Here is the branch at github: https://github.com/arrase/orbot/tree/hidden_services The list item is ugly as hell, the icon and color of the fab is ugly and i don't know where to put the button for load a backup zip, maybe longclicking the fab....bad idea i think. 2016-11-20 16:17 GMT+01:00 arrase <[email protected]>: > 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 <[email protected]>: > >> 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" < >> [email protected]> 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 < >>> [email protected] >>> >> : >>> > >>> >> >>> >> 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 <[email protected]>: >>> >>> >>> >>>> 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" < >>> >>>> [email protected]> 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" < >>> >>>>>> [email protected]> 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 < >>> >>>>>> [email protected] >>> >>>>>>>>> : >>> >>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> 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 < >>> >>>>>>>>> [email protected]>: >>> >>>>>>>>>> >>> >>>>>>>>>>> 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 < >>> >>>>>>>>>>> [email protected]>: >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>>> 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 <[email protected]>: >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> Great , is all i need to start, many thanks. >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> 2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner < >>> >>>>>>>>>>>>>>>> [email protected]>: >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> 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 < >>> >>>>>>>>>>>>>>>>> [email protected] >>> >>>>>>>>>>>>>>>>>>> : >>> >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> arrase: >>> >>>>>>>>>>>>>>>>>>>> 2016-11-15 13:23 GMT+01:00 Michael Rogers < >>> >>>>>>>>>>>>>> [email protected]>: >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>> 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: >>> >>>>>> [email protected] >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> -- >>> >>>>>>>>>>>>>> Nathan of Guardian >>> >>>>>>>>>>>>>> [email protected] >>> >>>>>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>>>>> List info: >>> >>>>>> https://lists.mayfirst.org/mailman/listinfo/guardian-dev >>> >>>>>>>>>>>>>> To unsubscribe, email: >>> >>>>>> [email protected] >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>>>> List info: https://lists.mayfirst.org/mai >>> >>>>> lman/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=0xE9E28DEA00 >>> >>>>> AA5556 >>> >>>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>>> List info: https://lists.mayfirst.org/mai >>> >>>>> lman/listinfo/guardian-dev >>> >>>>>>>>>>>> To unsubscribe, email: guardian-dev-unsubscribe@lists >>> >>>>> .mayfirst.org >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> -- >>> >>>>>>>>>>> Nathan of Guardian >>> >>>>>>>>>>> [email protected] >>> >>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>> List info: https://lists.mayfirst.org/mai >>> >>>>> lman/listinfo/guardian-dev >>> >>>>>>>>>>> To unsubscribe, email: guardian-dev-unsubscribe@lists >>> >>>>> .mayfirst.org >>> >>>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> _______________________________________________ >>> >>>>>>>>>> List info: https://lists.mayfirst.org/mai >>> >>>>> lman/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=0xE9E28DEA00 >>> AA5556 >>> >>>>>>>>> _______________________________________________ >>> >>>>>>>>> List info: https://lists.mayfirst.org/mai >>> >>>>> lman/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=0xE9E28DEA00 >>> AA5556 >>> >>>>>> _______________________________________________ >>> >>>>>> List info: https://lists.mayfirst.org/mai >>> lman/listinfo/guardian-dev >>> >>>>>> To unsubscribe, email: guardian-dev-unsubscribe@lists >>> .mayfirst.org >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> Nathan of Guardian >>> >>>>> [email protected] >>> >>>>> _______________________________________________ >>> >>>>> List info: https://lists.mayfirst.org/mai >>> lman/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: [email protected] >>> >>> >>> >> >>> >> -- >>> >> 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: [email protected] >>> >> >>> > >>> >>> -- >>> 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: [email protected]
