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= > 0xE9E28DEA00AA5556 > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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=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/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]
