<div dir="ltr">this should fix the issue<br><br><pre style="background-color:rgb(255,255,255);color:rgb(0,0,0);font-family:"dejavu sans mono""><span style="color:rgb(0,0,128);font-weight:bold">private void </span>migratePreferences(){<br>   String hsPortString = <span style="color:rgb(102,14,122);font-weight:bold">mPrefs</span>.getString(<span style="color:rgb(0,128,0);font-weight:bold">"pref_hs_ports"</span>, <span style="color:rgb(0,128,0);font-weight:bold">""</span>);<br>   <span style="color:rgb(0,0,128);font-weight:bold">if</span>(hsPortString.length() > <span style="color:rgb(0,0,255)">0</span>)<br>   {<br>      StringTokenizer st = <span style="color:rgb(0,0,128);font-weight:bold">new </span>StringTokenizer (hsPortString,<span style="color:rgb(0,128,0);font-weight:bold">","</span>);<br>      ContentResolver cr = getContentResolver();<br>      <span style="color:rgb(0,0,128);font-weight:bold">while </span>(st.hasMoreTokens())<br>      {<br>         <span style="color:rgb(0,0,128);font-weight:bold">int </span>hsPort = Integer.<span style="font-style:italic">parseInt</span>(st.nextToken().split(<span style="color:rgb(0,128,0);font-weight:bold">" "</span>)[<span style="color:rgb(0,0,255)">0</span>]);<br>         ContentValues fields = <span style="color:rgb(0,0,128);font-weight:bold">new </span>ContentValues();<br>         fields.put(<span style="color:rgb(0,128,0);font-weight:bold">"name"</span>, hsPort);<br>         fields.put(<span style="color:rgb(0,128,0);font-weight:bold">"port"</span>, hsPort);<br>         fields.put(<span style="color:rgb(0,128,0);font-weight:bold">"onion_port"</span>, hsPort);<br>         cr.insert(HSContentProvider.<span style="color:rgb(102,14,122);font-weight:bold;font-style:italic">CONTENT_URI</span>, fields);<br>      }<br><br>      Editor pEdit = <span style="color:rgb(102,14,122);font-weight:bold">mPrefs</span>.edit();<br>      pEdit.remove(<span style="color:rgb(0,128,0);font-weight:bold">"pref_hs_ports"</span>);<br>      pEdit.commit();<br>   }<br>}</pre><br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-11-17 21:28 GMT+01:00 arrase <span dir="ltr"><<a href="mailto:arrase@gmail.com" target="_blank">arrase@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span id="m_-2862976727961501677gmail-result_box" class="m_-2862976727961501677gmail-" lang="en"><span>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?</span><br><br><span>Can we do a routine that after updating look for the configuration of the old preferences and convert them to the new ones?</span><br><br><span class="m_-2862976727961501677gmail-">makes sense?</span></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-11-17 21:23 GMT+01:00 arrase <span dir="ltr"><<a href="mailto:arrase@gmail.com" target="_blank">arrase@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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.</p>
<p dir="ltr">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.</p><div class="m_-2862976727961501677HOEnZb"><div class="m_-2862976727961501677h5">
<div class="gmail_extra"><br><div class="gmail_quote">El 17 nov. 2016 7:16 p. m., "Nathan of Guardian" <<a href="mailto:nathan@guardianproject.info" target="_blank">nathan@guardianproject.info</a>> escribió:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hmm, I may be okay with breaking backward compatibility. I don't think<br>
there are that many apps using the existing intent, and it would only be<br>
a problem from them to request a new intent (i.e. existing configured<br>
onion services would still work, right?)<br>
<br>
On Thu, Nov 17, 2016, at 09:55 AM, arrase wrote:<br>
> I have only done a quick read but ... this breaks backward compatibility,<br>
> is it correct? I have no problem with that, but if we break the<br>
> compatibility I'm going to change the Intent to accept a list of ports<br>
> instead of just one<br>
><br>
> El 17 nov. 2016 6:31 p. m., "Hans-Christoph Steiner" <<br>
> <a href="mailto:hans@guardianproject.info" target="_blank">hans@guardianproject.info</a>> escribió:<br>
> ><br>
> ><br>
> > Yes.  Check out our TrustedIntents library for some methods.  Also, this<br>
> > project has some other methods for validating Intents received by a<br>
> Service:<br>
> ><br>
> > <a href="https://gitlab.com/fdroid/privileged-extension/" rel="noreferrer" target="_blank">https://gitlab.com/fdroid/priv<wbr>ileged-extension/</a><br>
> ><br>
> > .hc<br>
> ><br>
> > arrase:<br>
> > > Is it possible to know which app has sent an Intent service? I'll<br>
> > > investigate<br>
> > ><br>
> > > It seems to me a good method if it is possible to implement it without<br>
> > > having to ask the app to identify itself.<br>
> > ><br>
> > > 2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner <<br>
> <a href="mailto:hans@guardianproject.info" target="_blank">hans@guardianproject.info</a><br>
> > >> :<br>
> > ><br>
> > >><br>
> > >> I think adding any kind of user interaction is too much complexity.<br>
> > >> This needs to be entirely transparent to the user, at least to start<br>
> > >> with.  Orbot has no saved state beyond the basic config stuff (e.g.<br>
> > >> using VPN mode, allowing background starts, etc).  So its entirely up<br>
> to<br>
> > >> the app to save the Hidden Service key.<br>
> > >><br>
> > >> If an app sends Orbot a private key, it will remember which app sent<br>
> it,<br>
> > >> and only allow that exact app to do anything with it.  An app can pass<br>
> > >> around that private key as it wants to.<br>
> > >><br>
> > >> If Orbot generates the private key, then Orbot will send that back to<br>
> > >> the requesting app, and allow only that app to access it.<br>
> > >><br>
> > >> .hc<br>
> > >><br>
> > >> arrase:<br>
> > >>> Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_<wbr>SERVICE),<br>
> I've<br>
> > >>> extended it to maintain backward compatibility.<br>
> > >>><br>
> > >>> I'm going to add another Intent to manage the small security layer<br>
> that<br>
> > >> I'm<br>
> > >>> adding when exporting the key of a service for its backup.<br>
> > >>> Once the permission for export the key is denied, only the user can<br>
> > >>> re-grant it from the main application.<br>
> > >>><br>
> > >>> The major picture is done, now i'm adding:<br>
> > >>><br>
> > >>> - A way for import/export the configuration of a hidden service in zip<br>
> > >>> fromat (UI and Intent service versions)<br>
> > >>> - A way for delete a hidden service (UI and Intent service versions)<br>
> > >>> - Intent for disallowing backup of the service.<br>
> > >>><br>
> > >>> 2016-11-17 15:47 GMT+01:00 Nathan of Guardian <<br>
> > >> <a href="mailto:nathan@guardianproject.info" target="_blank">nathan@guardianproject.info</a>>:<br>
> > >>><br>
> > >>>> As Arrase point out though, there is an undocumented intent. This is<br>
> > >>>> what we use for CameraV currently. I think making it official,<br>
> expanding<br>
> > >>>> it, and adding it into NetCipher makes a great deal of sense.<br>
> > >>>><br>
> > >>>> On Thu, Nov 17, 2016, at 12:37 AM, Hans-Christoph Steiner wrote:<br>
> > >>>>><br>
> > >>>>> The documentation is mostly in the form of javadoc strings in the<br>
> > >>>>> NetCipher library, since that's the usual developer interface to<br>
> this<br>
> > >>>>> stuff.  Otherwise, there is a little bit here:<br>
> > >>>>><br>
> > >>>>> <a href="https://guardianproject.info/code" rel="noreferrer" target="_blank">https://guardianproject.info/c<wbr>ode</a><br>
> > >>>>><br>
> > >>>>> There isn't yet any official way to request a Hidden Service as of<br>
> now.<br>
> > >>>>><br>
> > >>>>> .hc<br>
> > >>>>><br>
> > >>>>> arrase:<br>
> > >>>>>> After reviewing the code and learned how to make the changes I<br>
> think<br>
> > >>>> I'll<br>
> > >>>>>> take this a little further.<br>
> > >>>>>><br>
> > >>>>>> Keeping the backwards compatibility I will rewrite the<br>
> configuration<br>
> > >>>>>> preferences of the hidden services and an extension of the existing<br>
> > >>>> Intent<br>
> > >>>>>> services.<br>
> > >>>>>><br>
> > >>>>>> It's a big change that will take me a few days but I think it's the<br>
> > >>>> right<br>
> > >>>>>> thing to do.<br>
> > >>>>>><br>
> > >>>>>> Additionally I have not found a site where are documented the<br>
> > >>>> integration<br>
> > >>>>>> options offered by Orbot, for example there is already the option<br>
> that<br>
> > >>>> an<br>
> > >>>>>> application can register a new port hidden by an Intent but I have<br>
> not<br>
> > >>>>>> known until reading the code despite having searched Information on<br>
> > >>>> google.<br>
> > >>>>>><br>
> > >>>>>> 2016-11-15 23:26 GMT+01:00 Nathan of Guardian <<br>
> > >>>> <a href="mailto:nathan@guardianproject.info" target="_blank">nathan@guardianproject.info</a>>:<br>
> > >>>>>><br>
> > >>>>>>> As I mentioned in the ticket, you need to run > ndk-build in the<br>
> > >>>>>>> /orbotservice directory to create those native assets first.<br>
> > >>>>>>><br>
> > >>>>>>> We are working on extracting the native binary build components<br>
> into<br>
> > >> a<br>
> > >>>>>>> separate gradle dependency, to make working on the app itself,<br>
> > >> easier.<br>
> > >>>>>>> For now though, yes, you must build!<br>
> > >>>>>>><br>
> > >>>>>>> On Tue, Nov 15, 2016, at 01:19 PM, arrase wrote:<br>
> > >>>>>>>> It's hard to build Orbot, I solved several problems with the<br>
> > >>>> toolchain<br>
> > >>>>>>>> but<br>
> > >>>>>>>> now I'm stuck here building Tor binary:<br>
> > >>>>>>>><br>
> > >>>>>>>> zip ../orbotservice/src/main/asset<wbr>s/armeabi/pdnsd.mp3<br>
> > >>>>>>>> ../orbotservice/src/main/libs/<wbr>armeabi/pdnsd<br>
> > >>>>>>>>     zip warning: name not matched:<br>
> > >>>>>>>> ../orbotservice/src/main/libs/<wbr>armeabi/pdnsd<br>
> > >>>>>>>><br>
> > >>>>>>>> zip error: Nothing to do!<br>
> > >>>>>>>> (../orbotservice/src/main/asse<wbr>ts/armeabi/pdnsd.mp3)<br>
> > >>>>>>>><br>
> > >>>>>>>> Is it a known error?<br>
> > >>>>>>>><br>
> > >>>>>>>> For this case I have not found references in google<br>
> > >>>>>>>><br>
> > >>>>>>>><br>
> > >>>>>>>> 2016-11-15 20:14 GMT+01:00 arrase <<a href="mailto:arrase@gmail.com" target="_blank">arrase@gmail.com</a>>:<br>
> > >>>>>>>><br>
> > >>>>>>>>> Great , is all i need to start, many thanks.<br>
> > >>>>>>>>><br>
> > >>>>>>>>> 2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner <<br>
> > >>>>>>>>> <a href="mailto:hans@guardianproject.info" target="_blank">hans@guardianproject.info</a>>:<br>
> > >>>>>>>>><br>
> > >>>>>>>>>><br>
> > >>>>>>>>>> I think it would work like the start/status intents that are<br>
> > >>>> currently<br>
> > >>>>>>>>>> in Orbot. The app sends an Intent to Orbot to request a Hidden<br>
> > >>>> Service<br>
> > >>>>>>>>>> to be created, then Orbot sends reply status Intents to the app<br>
> > >>>> that<br>
> > >>>>>>>>>> made the request with all relevant info, including a<br>
> FileProvider<br>
> > >>>> URI<br>
> > >>>>>>>>>> with GRANT URI permissions so that the requesting app can get<br>
> the<br>
> > >>>>>>>>>> private key.  That'd be the whole API, unless you also want to<br>
> > >>>> make a<br>
> > >>>>>>>>>> "stop hidden service" Intent.<br>
> > >>>>>>>>>><br>
> > >>>>>>>>>> No need to change anything about the control, the whole API<br>
> would<br>
> > >>>> be<br>
> > >>>>>>>>>> based on those Intents, and we can use the TrustedIntents<br>
> library<br>
> > >>>> to<br>
> > >>>>>>>>>> enforce that the reply only goes to the exact app that<br>
> requested<br>
> > >>>> it.<br>
> > >>>>>>> As<br>
> > >>>>>>>>>> a start, it would be fine to send the reply based on<br>
> packageName.<br>
> > >>>>>>>>>><br>
> > >>>>>>>>>> .hc<br>
> > >>>>>>>>>><br>
> > >>>>>>>>>> arrase:<br>
> > >>>>>>>>>>> Are you suggesting something? XD<br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>> I can take a look at the problem and propose a solution, it<br>
> will<br>
> > >>>>>>> not be<br>
> > >>>>>>>>>>> fast but I can do it.<br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>> Tonight I will try to compile Orbot from sources and try to<br>
> > >>>>>>> familiarize<br>
> > >>>>>>>>>>> myself with the code. (Is there a wiki with info??)<br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>> How do you want to focus the change? What should be possible<br>
> by a<br>
> > >>>>>>> third<br>
> > >>>>>>>>>>> party?<br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>> In my opinion:<br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>> - Be able to register a hidden service for your ports without<br>
> > >>>>>>> sharing it<br>
> > >>>>>>>>>>> with other applications.<br>
> > >>>>>>>>>>> - Be able to backup the configuration files in order to<br>
> migrate<br>
> > >>>> the<br>
> > >>>>>>>>>> service.<br>
> > >>>>>>>>>>> - Everything should be possible without root<br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>> It would be nice if all this was possible without giving<br>
> access<br>
> > >> to<br>
> > >>>>>>> the<br>
> > >>>>>>>>>> Tor<br>
> > >>>>>>>>>>> configuration port, but right now I can not think of how to do<br>
> > >> it.<br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>> I keep thinking ..... after working, I'll dedicate some time<br>
> to<br>
> > >>>> the<br>
> > >>>>>>>>>> problem<br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>> 2016-11-15 14:19 GMT+01:00 Hans-Christoph Steiner <<br>
> > >>>>>>>>>> <a href="mailto:hans@guardianproject.info" target="_blank">hans@guardianproject.info</a><br>
> > >>>>>>>>>>>> :<br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>> arrase:<br>
> > >>>>>>>>>>>>> 2016-11-15 13:23 GMT+01:00 Michael Rogers <<br>
> > >>>>>>> <a href="mailto:michael@briarproject.org" target="_blank">michael@briarproject.org</a>>:<br>
> > >>>>>>>>>>>>><br>
> > >>>>>>>>>>>>>> Hi arrase,<br>
> > >>>>>>>>>>>>>><br>
> > >>>>>>>>>>>>>> Thanks for discovering this bug. Can you describe how<br>
> Briar's<br>
> > >>>> Tor<br>
> > >>>>>>>>>> daemon<br>
> > >>>>>>>>>>>>>> conflicts with Orbot? What problems does it cause? Our<br>
> goal is<br>
> > >>>>>>> for<br>
> > >>>>>>>>>> Briar<br>
> > >>>>>>>>>>>>>> to be able to operate on the same device as Orbot without<br>
> > >>>>>>> problems.<br>
> > >>>>>>>>>>>>>><br>
> > >>>>>>>>>>>>>><br>
> > >>>>>>>>>>>>> I do not think it could be called a bug, and definitely not<br>
> a<br>
> > >>>>>>> Briar<br>
> > >>>>>>>>>> bug<br>
> > >>>>>>>>>>>> at<br>
> > >>>>>>>>>>>>> all. I find it hard to argue in English, I'm sorry.<br>
> > >>>>>>>>>>>>><br>
> > >>>>>>>>>>>>> But if it is true that is a problem if more applications<br>
> follow<br>
> > >>>>>>> the<br>
> > >>>>>>>>>> same<br>
> > >>>>>>>>>>>>> path as Briar implementing a Tor daemon within the<br>
> application.<br>
> > >>>>>>>>>>>>><br>
> > >>>>>>>>>>>>> Briar opens those ports for Tor:<br>
> > >>>>>>>>>>>>><br>
> > >>>>>>>>>>>>> Tcp 0 0 <a href="http://127.0.0.1:59050" rel="noreferrer" target="_blank">127.0.0.1:59050</a> 0.0.0.0:* LISTEN 10019 214952 18753<br>
> > >>>>>>>>>>>>> Tcp 0 0 <a href="http://127.0.0.1:59051" rel="noreferrer" target="_blank">127.0.0.1:59051</a> 0.0.0.0:* LISTEN 10019 213387 18753<br>
> > >>>>>>>>>>>>><br>
> > >>>>>>>>>>>>> If Orbot starts first, nothing prevents it from taking ports<br>
> > >>>>>>> 59050 and<br>
> > >>>>>>>>>>>>> 59051 as control ports. It is a remote but real possibility<br>
> and<br>
> > >>>>>>> would<br>
> > >>>>>>>>>> be<br>
> > >>>>>>>>>>>>> more real when more applications opt for the same solution.<br>
> > >>>>>>>>>>>>><br>
> > >>>>>>>>>>>>> It's just an argument about changing the hidden service API<br>
> for<br>
> > >>>>>>> Orbot.<br>
> > >>>>>>>>>>>>><br>
> > >>>>>>>>>>>>> I think there are more strong arguments like that each<br>
> > >>>>>>> application can<br>
> > >>>>>>>>>>>>> manage the configuration files of the hidden service to be<br>
> able<br>
> > >>>> to<br>
> > >>>>>>>>>>>> migrate<br>
> > >>>>>>>>>>>>> between devices.<br>
> > >>>>>>>>>>>>><br>
> > >>>>>>>>>>>>> It does not look very good to make an application that uses<br>
> the<br>
> > >>>>>>> hidden<br>
> > >>>>>>>>>>>>> service as a user identifier and if we lose the device we<br>
> lose<br>
> > >>>> our<br>
> > >>>>>>>>>> entire<br>
> > >>>>>>>>>>>>> network of contacts.<br>
> > >>>>>>>>>>>>><br>
> > >>>>>>>>>>>>> I think they are good arguments for bringing about an<br>
> > >>>> improvement<br>
> > >>>>>>> in<br>
> > >>>>>>>>>>>> Orbot<br>
> > >>>>>>>>>>>>> APi as proposed by Nathan.<br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>> I think we all want to have a nice Intent-based API in Orbot<br>
> for<br>
> > >>>>>>> apps<br>
> > >>>>>>>>>> to<br>
> > >>>>>>>>>>>> work with Hidden Services, the real question is: who is<br>
> going to<br>
> > >>>>>>> do the<br>
> > >>>>>>>>>>>> work.  That would be a great place for you to start to get<br>
> > >>>>>>> involved.<br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>> .hc<br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>>> --<br>
> > >>>>>>>>>>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA<br>
> 00AA<br>
> > >>>> 5556<br>
> > >>>>>>>>>>>> <a href="https://pgp.mit.edu/pks/lookup?op=vindex&search=" rel="noreferrer" target="_blank">https://pgp.mit.edu/pks/lookup<wbr>?op=vindex&search=</a><br>
> > >>>> 0xE9E28DEA00AA5556<br>
> > >>>>>>>>>>>> ______________________________<wbr>_________________<br>
> > >>>>>>>>>>>> List info: <a href="https://lists.mayfirst.org/" rel="noreferrer" target="_blank">https://lists.mayfirst.org/</a><br>
> > >>>>>>> mailman/listinfo/guardian-dev<br>
> > >>>>>>>>>>>> To unsubscribe, email:  guardian-dev-unsubscribe@<br>
> > >>>>>>> <a href="http://lists.mayfirst.org" rel="noreferrer" target="_blank">lists.mayfirst.org</a><br>
> > >>>>>>>>>>>><br>
> > >>>>>>>>>>><br>
> > >>>>>>>>>><br>
> > >>>>>>>>>> --<br>
> > >>>>>>>>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA<br>
> > >> 5556<br>
> > >>>>>>>>>> <a href="https://pgp.mit.edu/pks/lookup?op=vindex&search=" rel="noreferrer" target="_blank">https://pgp.mit.edu/pks/lookup<wbr>?op=vindex&search=</a><br>
> > >> 0xE9E28DEA00AA5556<br>
> > >>>>>>>>>><br>
> > >>>>>>>>><br>
> > >>>>>>>>><br>
> > >>>>>>>> ______________________________<wbr>_________________<br>
> > >>>>>>>> List info:<br>
> <a href="https://lists.mayfirst.org/mailman/listinfo/guardian-dev" rel="noreferrer" target="_blank">https://lists.mayfirst.org/mai<wbr>lman/listinfo/guardian-dev</a><br>
> > >>>>>>>> To unsubscribe, email:<br>
> <a href="mailto:guardian-dev-unsubscribe@lists.mayfirst.org" target="_blank">guardian-dev-unsubscribe@lists<wbr>.mayfirst.org</a><br>
> > >>>>>>><br>
> > >>>>>>><br>
> > >>>>>>> --<br>
> > >>>>>>>   Nathan of Guardian<br>
> > >>>>>>>   <a href="mailto:nathan@guardianproject.info" target="_blank">nathan@guardianproject.info</a><br>
> > >>>>>>> ______________________________<wbr>_________________<br>
> > >>>>>>> List info:<br>
> <a href="https://lists.mayfirst.org/mailman/listinfo/guardian-dev" rel="noreferrer" target="_blank">https://lists.mayfirst.org/mai<wbr>lman/listinfo/guardian-dev</a><br>
> > >>>>>>> To unsubscribe, email:<br>
> <a href="mailto:guardian-dev-unsubscribe@lists.mayfirst.org" target="_blank">guardian-dev-unsubscribe@lists<wbr>.mayfirst.org</a><br>
> > >>>>>>><br>
> > >>>>>><br>
> > >>>>>><br>
> > >>>>>><br>
> > >>>>>> ______________________________<wbr>_________________<br>
> > >>>>>> List info: <a href="https://lists.mayfirst.org/mailman/listinfo/guardian-dev" rel="noreferrer" target="_blank">https://lists.mayfirst.org/mai<wbr>lman/listinfo/guardian-dev</a><br>
> > >>>>>> To unsubscribe, email:  <a href="mailto:guardian-dev-unsubscribe@lists.mayfirst.org" target="_blank">guardian-dev-unsubscribe@lists<wbr>.mayfirst.org</a><br>
> > >>>>>><br>
> > >>>>><br>
> > >>>>> --<br>
> > >>>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556<br>
> > >>>>> <a href="https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556" rel="noreferrer" target="_blank">https://pgp.mit.edu/pks/lookup<wbr>?op=vindex&search=0xE9E28DEA00<wbr>AA5556</a><br>
> > >>>>> ______________________________<wbr>_________________<br>
> > >>>>> List info: <a href="https://lists.mayfirst.org/mailman/listinfo/guardian-dev" rel="noreferrer" target="_blank">https://lists.mayfirst.org/mai<wbr>lman/listinfo/guardian-dev</a><br>
> > >>>>> To unsubscribe, email:  <a href="mailto:guardian-dev-unsubscribe@lists.mayfirst.org" target="_blank">guardian-dev-unsubscribe@lists<wbr>.mayfirst.org</a><br>
> > >>>><br>
> > >>>><br>
> > >>>> --<br>
> > >>>>   Nathan of Guardian<br>
> > >>>>   <a href="mailto:nathan@guardianproject.info" target="_blank">nathan@guardianproject.info</a><br>
> > >>>> ______________________________<wbr>_________________<br>
> > >>>> List info: <a href="https://lists.mayfirst.org/mailman/listinfo/guardian-dev" rel="noreferrer" target="_blank">https://lists.mayfirst.org/mai<wbr>lman/listinfo/guardian-dev</a><br>
> > >>>> To unsubscribe, email:  <a href="mailto:guardian-dev-unsubscribe@lists.mayfirst.org" target="_blank">guardian-dev-unsubscribe@lists<wbr>.mayfirst.org</a><br>
> > >>>><br>
> > >>><br>
> > >>><br>
> > >>><br>
> > >>> ______________________________<wbr>_________________<br>
> > >>> List info: <a href="https://lists.mayfirst.org/mailman/listinfo/guardian-dev" rel="noreferrer" target="_blank">https://lists.mayfirst.org/mai<wbr>lman/listinfo/guardian-dev</a><br>
> > >>> To unsubscribe, email:  <a href="mailto:guardian-dev-unsubscribe@lists.mayfirst.org" target="_blank">guardian-dev-unsubscribe@lists<wbr>.mayfirst.org</a><br>
> > >>><br>
> > >><br>
> > >> --<br>
> > >> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556<br>
> > >> <a href="https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556" rel="noreferrer" target="_blank">https://pgp.mit.edu/pks/lookup<wbr>?op=vindex&search=0xE9E28DEA00<wbr>AA5556</a><br>
> > >> ______________________________<wbr>_________________<br>
> > >> List info: <a href="https://lists.mayfirst.org/mailman/listinfo/guardian-dev" rel="noreferrer" target="_blank">https://lists.mayfirst.org/mai<wbr>lman/listinfo/guardian-dev</a><br>
> > >> To unsubscribe, email:  <a href="mailto:guardian-dev-unsubscribe@lists.mayfirst.org" target="_blank">guardian-dev-unsubscribe@lists<wbr>.mayfirst.org</a><br>
> > >><br>
> > ><br>
> ><br>
> > --<br>
> > PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556<br>
> > <a href="https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556" rel="noreferrer" target="_blank">https://pgp.mit.edu/pks/lookup<wbr>?op=vindex&search=0xE9E28DEA00<wbr>AA5556</a><br>
> ______________________________<wbr>_________________<br>
> List info: <a href="https://lists.mayfirst.org/mailman/listinfo/guardian-dev" rel="noreferrer" target="_blank">https://lists.mayfirst.org/mai<wbr>lman/listinfo/guardian-dev</a><br>
> To unsubscribe, email:  <a href="mailto:guardian-dev-unsubscribe@lists.mayfirst.org" target="_blank">guardian-dev-unsubscribe@lists<wbr>.mayfirst.org</a><br>
<br>
<br>
--<br>
  Nathan of Guardian<br>
  <a href="mailto:nathan@guardianproject.info" target="_blank">nathan@guardianproject.info</a><br>
______________________________<wbr>_________________<br>
List info: <a href="https://lists.mayfirst.org/mailman/listinfo/guardian-dev" rel="noreferrer" target="_blank">https://lists.mayfirst.org/mai<wbr>lman/listinfo/guardian-dev</a><br>
To unsubscribe, email:  <a href="mailto:guardian-dev-unsubscribe@lists.mayfirst.org" target="_blank">guardian-dev-unsubscribe@lists<wbr>.mayfirst.org</a><br>
</blockquote></div></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>