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/mailman/listinfo/guardian-dev >> >>>>> To unsubscribe, email: [email protected] >> >>>>> >> >>>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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]
