- tor-dev - lists.torproject.org

Summer of Privacy applicant, Multi-threading
by Kim Reece 15 Apr '15

15 Apr '15

Hello, I see several folks doing brief intros here so I'll do so as well. Most of my application is in already, just finishing up the patch. I'm a Mathematics undergrad, 3rd year come Fall. I've used multi-threading in coursework and in an internship I did at JPL/NASA. I want to expand the multi-threading in Tor this summer. For my patch I'm working on #3569 (Refactor socks parsing). It won't be a complete implementation of that bug this week, but I aim to complete the first part of it, ie. the refactoring internal to the function to expose the state model clearly in code structure. To that end I have one quick code style question: Is clarity preferred over the (very short) body of a conditional only occurring in one place? I'm encountering at least once instance where the choice is between repeating a (very short) code block, thereby introducing the potential that one section of it may in the future be edited without the other receiving the same edit (even though they're right next to each other), or retaining a gnarly conditional that took a truth table for me to be sure I had the right end of. If code occurring exactly once is a priority, the gnarliness can be repaired with an explanatory comment, but I'd like to know which is preferred. Thanks, -- Kim

1 0

Using consensus package versions for third party software
by John Brooks 15 Apr '15

15 Apr '15

Proposal 227 added a method for putting non-little-t-tor package versions and digests in the consensus, intended to authenticate Tor Browser updates. This is done in tor 0.2.6, although it’s not yet in use by Tor Browser or the consensus. I propose using this feature to notify Ricochet[1] users of software updates. My reasoning is: - It’s vital to the security of Ricochet’s users that they’re quickly notified of version updates - Tor is the only infrastructure Ricochet uses; adding an “update server” would harm its model - The consensus-based method is better than anything we can independently do - I think Ricochet is an ideal case of where this work can be useful The benefits from my side are obvious, but it’s less clear if this is appropriate for Tor. Ricochet users[2] are an extremely small portion of Tor’s users, but this would be in every consensus. Some directory authorities would have to volunteer to keep those votes up to date. I’m interested in feedback from the community in general, and especially from directory authorities on whether this is something they’d be interested in supporting. Of course, even if people think this is a good idea, the burden is on me to convince DAs to lend their time. Thanks, - John [1] https://ricochet.im/ [2] It’s part of the design that I can’t accurately count users. My best guess is “low hundreds, and growing”.

1 0

Fwd: Orbot v15 RC3... now with x86/ATOM-power!
by Nathan Freitas 14 Apr '15

14 Apr '15

----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: Orbot v15 RC3... now with x86/ATOM-power! Date: Mon, 13 Apr 2015 09:55:44 -0400 Making some tiny changes to external/Makefile and jni/Application.mk means we can now build the tor, polipo and xtables binaries, along with the tun2socks.so for any necessary chip architecture. I've added support for x86 in this release, which only added a few MB to the overall APK. Somehow, devices with Intel ATOM chips were able to run Orbot v14 releases, even though we didn't target x86. I think ATOM has some sort of light ARM compatibility mode, but we broke that in the update for v15... anyhow, this is better, as it is officially supported and tested. One interesting issue is that GoLang 1.4.1, which we are using to cross-compile the Meek and Obfs4 pluggable transports to Android, only supports targeting Android ARM for right now... I assume that will change soon, but if not, we may have to add Obfsclient back into Orbot for supporting x86 devices. The most popular x86/ATOM devices we have heard people complaining about seem to be Galaxy Tab 3 and the Asus Zenphone and Padphone devices. Anyhow... details below... **** APK: https://guardianproject.info/releases/Orbot-v15.0.0-RC-3.apk Sig: https://guardianproject.info/releases/Orbot-v15.0.0-RC-3.apk.asc Tag: https://gitweb.torproject.org/orbot.git/tag/?id=15.0.0-RC-3 /** 15.0.0 RC 3 / 13-Apr-2015 / b941a1c7d5588db7efd9fab672ec518a69f76f84 **/ b941a1c show warning about bridge limits on Intel x86/ATOM devices 325ca1f only ARM chips can support the new Obfs4, Meek bridges so hide the UI options that promote them, and just request standard br i 3c6f173 make buttons not resize weirdly with long strings 421764b make socksbypass local port random 4ab1854 update resource installer to handle different architecture e7a7d8c support variable arch builds to support x86 move asset builds to /assets folder 74deb39 support building tun2socks for x86 933b2e9 Small VPN and socket monitoring related fixes -- Nathan of Guardian nathan(a)guardianproject.info

3 2

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"
by teor 13 Apr '15

13 Apr '15

> Date: Fri, 10 Apr 2015 15:47:23 +0300 > From: George Kadianakis <desnacked(a)riseup.net> > > David Goulet <dgoulet(a)ev0ke.net> writes: > >>> On 09 Apr (21:58:49), George Kadianakis wrote: >>> Hello, >>> >>> I inline a proposal for Direct Onion Services. It's heavily based on >>> the "encrypted services" proposal of Roger, but I refined it, made it >>> more proposaley and enabled a few more optimizations. You can find the >>> original piece here: >>> https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypte… >>> >>> Feedback would be greatly appreciated. >>> [snip] > >>> >>> - We really really need a better name for this feature. I decided to >>> go with "Direct Onion Services" which is the one that the NRL people >>> suggested here: >>> https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html >>> I'm not super happy with it, but I can't think of better ones myself. >>> Here are some candidates: >>> 1 Way Anonymous Hidden Services >>> Fast Onion Service >>> Short-circuited Onion Services >>> Fast-but-not-hidden Services >> >> "Fast Onion-Space Service" was proposed by pfmbot on #tor-dev. I like it >> because it describes pretty much what it is and the acronym is FOSS. :) > > It's not clear to me why acronym collisions are a plus :) > >>> >>> - We also need a better torrc option. If the name of this feature does >>> not portray its dangers, then the torrc option should be a bit >>> terrifying. That's why I went 'DangerousDirectOnionService' which I >>> actually don't like at all. BTW, it's unclear whether this mailing >>> list is the best place to brainstorm for names. >> >> This one depends on the name quite heavily but I don't think we should >> have a scary name. Scary name seems to me they will simply bring more >> questions without context of the actual feature. What is "Dangerous" >> about this, why is it in Tor at all?... This could simply be resolved by >> clear and thorough documentation of the risks/benefits of the options. >> >> For instance, we could *not* put it in the default torrc file and thus >> will only be in the man page with *good* documentation. Like you said >> also in the proposal, a big warning is very important at boot. >> >> If it's off by default and not present in the torrc file, there are no >> reasons why someone would enable this just because it's says >> "DirectOnionServiceEnable". (Ok I might be an optimist but still, we are >> not that responsible for reckless HS operator ;) > > Yes, I agree that the 'Dangerous' prefix is stupid. I think I'm OK > with changing the proposal to use 'DirectOnionServiceEnable' but I would > prefer if it's a bit more alarming. >> >> [snip] I've been hesitant to weigh in on the naming conversation for hidden services. But I am concerned about the issues raised in the previous few emails on the topic. Matt @ Speak Freely has a strong point about acronym collisions - they only serve to confuse users and dilute the search space. And usability becomes a security issue as soon as names are confusing to users. Others have also made important points about how we name things in general. So I'd like to propose some general naming principles, mostly distilled from recent conversations about names: 1. Avoid acronyms that collide with popular acronyms, particularly those in the security / software / technology spaces. 2. Names should be kept consistent across the entire Tor code base and ecosystem. 3. When selecting option, feature, and concept names: A) Names should describe the most important user-visible impact of an option, feature, or concept. B) If the feature has a serious impact on anonymity (or other typical user assumptions), the name should indicate that. C) Names should avoid specific implementation details, as these may change. D) Names should avoid giving relative opinions on performance, security, or privacy impacts, as these are often dependent on context. E) Project names are an exception to principle 3, and should have abstract names, or descriptive acronyms. My evaluation of the suggestions around hidden services / onion services based on these principles is: > Onion Service Collides with OS, or Operating System, violating principle 1: no collisions. If we decide to disregard this acronym collision, and accept the usability impact, every option and the entire manual page should be changed in the same release, to satisfy principle 2. This would involve a transition period in which both HS and OS options would work. (We should also consider the usability of options with OS in the name before making the switch.) > Direct Onion Service > Dangerous Direct Onion Service As it's already been noted, these collide with DOS and DDOS (1), and don't describe which end is direct (3A & 3B). > Fast Onion Service > Short-circuited Onion Services I'm concerned about the collisions with OS implied by these acronyms (1). Also, the first provides a performance goal (3D), and the second, an implementation detail (3C). Neither describes the most important user-visible behaviour - lack of server anonymity (3B). > Fast-but-not-hidden Services This seems to combine a performance goal (3D), with a description of the impact of the service. Aren't we better to address the speed / anonymity trade off in the manual and other documentation? > 1 Way Anonymous Hidden Services This is descriptive (3A & 3B), but which end is anonymous? Why not state that it's the client: Client Anonymous Hidden Services Or, even better, state that the server is non-anonymous: Exposed Server Hidden Services Public Server Hidden Services Yielding option names like the following: ExposedServerHiddenServiceEnable PublicServerHiddenServiceEnable But I'd be happy with any feature and option names that make it obvious that the hidden service server has reduced anonymity compared to standard hidden services. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED

2 1

Re: [tor-dev] Fwd: Orbot v15 RC3... now with x86/ATOM-power!
by Nathan Freitas 13 Apr '15

13 Apr '15

On Mon, Apr 13, 2015, at 02:05 PM, Daniel Martí wrote: > Possibly stupid question, but wouldn't a static linux/x86 binary work > just fine as long as you're executing it directly? As far as I know the > Android port is just for all the bindings involved in e.g. writing a > game in Go that does OpenGL calls back to Android. There a few more changes in there, as well, such as how DNS works on Android, and few other small underlying differences. > > For example, I found this bit in a blog post online: > > > Copy myexectuable under your Android project’s ./libs/armeabi/ folder. > > If you’re targeting one of the rare x86 Android devices, build to > > x86/Linux and copy the resulting binary to ./libs/x86 (and yes, you > > can include both in a single APK, and it will deploy whichever one is > > appropriate). > > But then this would mean that we wouldn't need android/arm either, since > we could just use linux/arm instead :) We were previously using linux/arm for the PT compiling, and it mostly worked, but it turns out there are enough small differences in the Android API from Linux, that it does matter to target Android specifically. This is similar to why we need the Android NDK for tor cross-compile, and not just a generix linux ARM build. +n

2 1

Re: [tor-dev] Fwd: Orbot v15 RC3... now with x86/ATOM-power!
by Nathan Freitas 13 Apr '15

13 Apr '15

On Mon, Apr 13, 2015, at 12:57 PM, Yawning Angel wrote: > On Mon, 13 Apr 2015 10:14:43 -0400 > Nathan Freitas <nathan(a)freitas.net> wrote: > > One interesting issue is that GoLang 1.4.1, which we are using to > > cross-compile the Meek and Obfs4 pluggable transports to Android, only > > supports targeting Android ARM for right now... I assume that will > > change soon, but if not, we may have to add Obfsclient back into Orbot > > for supporting x86 devices. > > Hmm, maybe I should add obfs4 support to obfsclient. I have code for > all of the crypto I would need to add. Let me reach out to the GoLang Android community and see what the blocker is... I was thinking the same thing though, it wouldn't be hard to still support Obfsclient, along with the Go-based PT's. Thanks!

2 1

project related
by raj kumar 13 Apr '15

13 Apr '15

hi , i am a second year BSc.cs undergraduate student and i am very much interested in doing a project on tor's ''profile UDP transport protocol''. But since i am new to this project thing, i am really in need of ideas and suggestions to accomplish this. It would be great if u can help me with this project. Thank you.

1 0

TSOP proposal
by Rémi py 12 Apr '15

12 Apr '15

Hello tor-dev, I'm a master student researching computational stylometry (analyzing writing style of typed texts) in adversarial settings. Computational stylometry is a danger to the anonymity of authors who do not take appropriate precautions. A draft TSOP proposal is attached, it builds upon my academic research. I mailed tor-assistants about my TSOP proposal and Damian informed me that it might be difficult to find a mentor for this project. I am mailing tor-dev in the hope of finding someone who is willing and able to be my mentor for this TSOP project. The application that I would like to write will be my first non-web application that targets non-technical users (as opposed to academic users). A lot of machine learning and NLP will be used, but I don't need a mentor for that. Although I have mostly worked in groups (academic and professional) I have carried this research project myself and I am confident in my ability to continue to do so. If you have any questions please contact me. Hoping to find a mentor for this project, Kind regards, Rémi.

1 0

Are DAC_OVERRIDE & CHOWN capabilities required for ControlSocket?
by Nusenu 12 Apr '15

12 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, tor will fail to startup with the current systemd service file [1] if your torrc makes use of the ControlSocket feature. To work around the issue one has to additionally allow the following capabilities: CAP_DAC_OVERRIDE CAP_CHOWN since the socket file is create as root and then changed to the tor user (chown). Is it possible to change this to not require CAP_DAC_OVERRIDE and CAP_CHOWN capabilities anymore? thanks, Nusenu [1] https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in#n 26 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVKmkiAAoJEFv7XvVCELh0Qk8QAITqZiFwp+nBIywWgLLQ5m6K CNkRa+HcNk3sCJKFWOzXqLP4Q1mIUrPWT6Mm+LbwLvo8uRnJqBNL5H0F+kDgYfyO wAsnRicwmoNfHa8hb292nj4p4eV/gQf9J94/creDl99jrtlgYBeLWY8toUZy452x QvAny7EC9Gt06/zMyNJxvVhb1SgthLsIfN6LXizH0Xe1y6m1Kh4XW/py5nvuMwmR sZg1QyUxQ8uJIs73J0KnuGZrzloJGN6IZmJ4EZ250gTUty3VtgvOTAu7W6KsGC2F dyHFqbJqHnEPLUn2ITxcmxBGduG7TWueh1+2KElVMQI9+j8IsD+9xGHUPtiywVEJ VpxaUlDqOu0tNovRPzkM01pg9KTqvydJ7BgAV0GgpoAH1rnYuEIh+kqieHvOLN96 uSuOjzTD87sHClWfIhuf645GCK+iy2Ln6f8yzxZn2DT870/yraX7eCaAK6gQt803 FMdBY2qtw3rFuGMW9ca/LTGlu04BrQb/boIEMhUMLdfAdBbJxYPuTbKbtBCbfcew NtB+5sxAuy2o8XcHsX/6gjDBi4rb7xp5QKy5xgsavE+uqyXAwCKNFF5yT7HNYX33 UMnSG1069frMXAGTYAPzQp+7dVLGs6h+xPx8aut/SoZqHjQOxQ6Qv5PtgltRvfv3 ZsOrqE5a0aly6OsspTUN =/5TL -----END PGP SIGNATURE-----

2 2

Big performance improvement for meek-azure
by David Fifield 12 Apr '15

12 Apr '15

I found and fixed a big performance limitation in the meek-azure transport. If you tried meek-azure before, but it was too slow, give it another try! meek-azure has always seemed slower than the other two backends, and I recently spent the time to figure out why. It was a lack of persistent HTTP connections between the Azure host and the Tor bridge. Every single HTTP request was doing a complete TCP and TLS handshake. This of course increased latency, but the bottleneck was actually CPU on the bridge, as it tried to cope with all those TLS handshakes. Here is the commit that causes connections to be shared and reused: https://gitweb.torproject.org/pluggable-transports/meek.git/commit/?id=e06b… This issue did not affect meek-google because the App Engine URL fetch API reuses HTTP connections transparently. It did not affect meek-amazon because the CloudFront CDN does its own connection reuse. Usage on meek-azure has already increased in the past few days since I started testing the change. I attached a graph that shows the all-time bandwidth history of the bridge. https://globe.torproject.org/#/bridge/AA033EEB61601B2B7312D89B62AAA23DC3ED8… David Fifield

1 0

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"
by str4d 11 Apr '15

11 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 George Kadianakis wrote: > David Goulet <dgoulet(a)ev0ke.net> writes: > >> On 09 Apr (21:58:49), George Kadianakis wrote: >>> Hello, >>> >>> I inline a proposal for Direct Onion Services. It's heavily >>> based on the "encrypted services" proposal of Roger, but I >>> refined it, made it more proposaley and enabled a few more >>> optimizations. You can find the original piece here: >>> https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/ >>> >>> xxx-encrypted-services.txt >>> >>> >>> >>> Feedback would be greatly appreciated. >> >> First thanks for that! Really useful stuff. >> >>> >>> Here are some specific points that I would like help with: >>> >>> - Should we require a specially compiled version of Tor to >>> enable this feature? Like we do for tor2web mode? In this >>> proposal, I didn't require any special compilation flags. I >>> don't have strong opinions here. >> >> IMO, I'm not sure this is useful. This feature requires prior >> knowledge of the HS operator to know what's a "Direct Onion >> Service" and decide that she wants that for her service. Thus, a >> torrc option seems enough. I don't see any reasons for this >> option that will limit deployment. >> > > Yes, I also feel the same. > > My main fear is sample torrc's that are being posted around the > net and people just copy-paste them into their box: someone might > not notice the DirectOnionServiceEnable option. Perhaps this could be mitigated by alerting the user the first time Tor is started with this option enabled. This is obviously harder to do if Tor is started as a service, but it should be possible for manually-started Tor or TBB. >> >> [snip] >> >>> >>> 3.2. One-hop circuits [ONEHOP] >>> >>> When in this mode, the onion service establishes 1-hop circuits >>> to introduction and rendezvous points. The onion service SHOULD >>> also ignore cannibalizable 3-hop circuits when creating such >>> circuits. >>> >>> This looks like this for the rendezvous point case: >>> >>> |direct onion service| -> RP <- client middle <- client guard >>> <- |client| >>> >>> This change allows greater speeds when establishing a hidden >>> service circuit and reduces round-trip times. As a side-effect, >>> busy onion services with this feature cause less damage to the >>> rest of the network, since their traffic gets passed around >>> less. >> >> Would it be possible to drop the rendezvous part where the client >> could simply connect to the IP and then the circuit back to the >> HS would be used? (Though that would require that the client >> knows the HS it's trying to reach is a Direct Onion Service, >> could be mention in the descriptor?...) >> > > I think that's indeed possible, but would require multiplexing > multiple client connections on a single IP circuit, which Tor > cannot do at the moment AFAIK. It is my understanding that it's not > an easy change, but I'm pretty sure that I2P and other projects are > doing it, so we could in theory take a look at how those guys do > it. I2P does have the ability to run "zero-hop" tunnels, yes - the router simply provides its own details for the tunnel entry point. But this probably isn't directly helpful for Tor because I2P is a packet-switched network, and it doesn't use separate rendezvous points for individual connections between Destinations. For high-traffic services that don't require anonymity, we generally recommend using one-hop tunnels instead of zero-hop. This is primarily to avoid connection limits being exceeded on the hosting router. The speed hit of having an additional hop in the path is generally outweighed by the benefit of only having e.g. 8 incoming connections for a particular service, instead of several thousand. It therefore also helps to mitigate DDoS attacks (although the biggest of services e.g. Facebook would likely have their own systems that would better handle this). str4d > _______________________________________________ tor-dev mailing > list tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVKGTIAAoJEBO17ljAn7PgYg8P/1gn8BleY9GyuceCXCvVicwk ROWeEahM/ujSzpJXqjTJMBjuBcXocan/RHbeTyrfjCGZhj4p/eUMKnXpMBpJcuKp oKEDXP3n14tnUxTnUT7vRl4ZYGmCZAiIKUqeqwAz2/1LxKYK+IDsxaurnbOA5uXV vuL2Q8WxbnhExEr+lvRX4zV2/5hGK7jj5R1Hz35qxZsJTjPUu3mRXxS5aiExUfzS kjxUA5uevKdE6/K0nQ4hJ7rY3ZkfcD8YIsW7CQsC0FfK8DXMaPew+tvUsUuegeDt nbIFRx8oGItFwDDwZIUWZED2g60YhrSc7Ig192amXYe42GtoPQC3n6ul0GqNM2cb m5AJAw5GGlxluprAwu3AcVl3/kYCLqN50bK/Lz3f2bBcYuUvcbNJ5GK6F4W/ye45 Pl2QmiiaGuZM5CKWNY4/kHc3sJaPfnFvbxdocqcIok3/AlnhVotQVDTl7bFklYOP qJ58oNJAU2UHY+uOX6c+8+d2G062AbWxo4iFlXOGguNSKnR+3w0fE+P+lMQjtAGj cE/7zj/DcFrj9TpVoZBAiDrEJfkWxywASoHhe1Y/eayzDg1D/jqfNNJ9/0YnPWPd tC/pnHPQ1/gc9mqIJzmW1c9tKdwzys1UI9UGNjdggVn80dnXYyE5xAwx5Ymh11NT VzHWkgab7+Shrp4dQL3a =B87T -----END PGP SIGNATURE-----

1 0

Next PT/Bridges Meeting: Wednesday 15 April 0200 UTC
by isis 10 Apr '15

10 Apr '15

Hello everyone, As per the votes for the new PT/Bridges meeting time, [0] we've settled on biweekly meetings in ircs://irc.oftc.net#tor-dev, on Wednesdays, at 0200 UTC. Please let me know if this is a severe inconvenience to anyone. The next meeting will be on Wed., 15 April, at 0200 UTC, which currently translates to the following (ridiculous, antediluvian, and nationalistic) timezones: - Tue., 14 April, 1900 PDT - Tue., 14 April, 2200 EDT - Wed., 15 April, 0400 CEST - Wed., 15 April, 0500 MSK - Wed., 15 April, 1100 JT See you there! [0]: https://lists.torproject.org/pipermail/tor-dev/2015-April/008601.html -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

Fwd: [guardian-dev] Orbot v15 RC 2
by Nathan Freitas 09 Apr '15

09 Apr '15

----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: [guardian-dev] Orbot v15 RC 2 Date: Thu, 09 Apr 2015 13:24:46 -0400 Orbot v15 RC2 is out addressing some critical and *odd* issues with copy and paste of bridges, VPN refresh on network switching, dumb bug fixes related to root and transproxy settings, and one or two other odds and ends. WARNING: If you are using the "email for bridges" feature on Android, and you copy and paste the bridge lines into the Bridges setting box, you might not notice that Android somehow removes some spaces in the string. Make sure to put a space back in between the server:port and the key portion of the string. If you scan the QR codes from bridges.torproject.org this shouldn't happen. APK: https://guardianproject.info/releases/Orbot-v15.0.0-RC-2.apk SIG: https://guardianproject.info/releases/Orbot-v15.0.0-RC-2.apk.asc Source tag: https://gitweb.torproject.org/orbot.git/tag/?id=15.0.0-RC-2 /** 15.0.0 RC 2 / 9-Apr-2015 / 60f19ca **/ d6c51bc Fixes for bridge setup, and root/shell interaction - If you paste bridge addresses from Gmail, you get some strange characters c39cdcb improve root access check for transproxy 7d8eea2 switch back to DNS on 10.0.0.1, update after VPN refresh 690a8c3 Improved handling of VPN and Tun2Socks on Network Switch 9974654 fix for setting root and transproxy preferences /** 15.0.0 RC 1 / 8-Apr-2015 / 280f69dfa10c38d880e98e71954526c68f1b3df5 **/ 776b7af use loopback address e6fe252 auto-restart Tor when config changes 384fe1c fix handling of network connectivity state management 02a42e4 update translated strings 628c9d8 update tor to 0.2.6.7 906ec7f v15-beta-2 small fixes for VPN d6eb1dc fixes for network switching with VPN enabled f37b935 modifications to bridge setup strings -- Nathan of Guardian nathan(a)guardianproject.info _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscribe(a)lists.mayfirst.org

1 0

Re: [tor-dev] Tor Summer of Privacy [ Incorporating ruleset testing into https-everywhere release process ]
by yan 09 Apr '15

09 Apr '15

Oops, sending again from my torproject account. On 4/9/15 10:24 AM, yan wrote: > Hi Karan, that is great to hear. I've cc'ed Jacob, one of the current > maintainers of HTTPS Everywhere. > > -Yan > > On 4/8/15 11:40 PM, karan grover wrote: >> Hello there! >> I am Karan Grover. I am a 2nd year computer science student at IIIT >> Delhi. >> >> I am a part of my college's Cybersecurity Education and Research Center, >> which is the first of its kind in the country. I have worked primarily >> in the field of Privacy and Security of Online Social Media (PSOSM). >> >> I am interested in contributing to Tor as a part of Tor Summer of >> Privacy. The project I am interested in working on is *Incorporating >> ruleset testing into https-everywhere release process*. I have been >> understanding the codebase of *https-everywhere-checker, *and am now >> quite familiar with it. I would like to discuss further about what the >> project entails. >> >> I contribute to open source every now and then, but am now looking to be >> an active open source contributor and Tor seems to align with my >> interests. >> >> Looking forward to your reply. >> >> Thank you. >> >> >> >> _______________________________________________ >> tor-dev mailing list >> tor-dev(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >>

1 0

Brainstorming ideas for controller features for improved testing; want feedback
by Nick Mathewson 09 Apr '15

09 Apr '15

Hi! I've got an end-of-month deliverable to flesh out as many good ideas here as I can, and I'd appreciate feedback on what kind of features it would be good to add to the controller protocol in order to better support testing. More ideas would be most welcome. Yes, some of these ideas are probably foolish or pointless or half-baked or useless or even dangerous; this is a brainstorming exercise, not a declaration of intent. The goal right now is to generate a lot of ideas and thoughts now, and to make decisions about what to build later. IDEAS ===== 1. Step-by-step hidden service connections Add the ability to create connections to hidden services step by step, to best What's necessary here is commands to: * Establish a rendezvous point on a given circuit. * Construct and send an introduce2 cell on a given circuit. * Realize that a rendezvous circuit has been constructed. 2. Send a single cell on a circuit (TESTING ONLY) For fuzzing and low-level testing purposes, it would be handy to be able to send a single cell on a tor circuit. This might be better to expose via a low-level modular API than via the control port. 3. Intercept cell by cell on a circuit (TESTING ONLY) For fuzzing, testing, and debugging purposes, it might be handy for a controller to be able to observe data cell by cell on a circuit of interest. This might be better to expose via a low-level modular API than via the control port. 4. Send a single cell on a connection. (TESTING ONLY) As 2, but for connections. Note that we might even, for testing, expose this at a sub-cell level. 5. Intercept all cells on a connection (TESTING ONLY) As 2, but for connections. 6. Plug-in to handle a relay or other command. Right now, all Tor's features need to be baked into Tor; it's not easy to write extensions. We could change that by having the controller able to intersect particular relay or extension commands and act accordingly. This could be used for prototyping new features, etc. 7. Force a given protocol on a given connection We could add a feature to restrict what protocols can be negotiated on a given connection we create. This could help us better test our protocols for interoperatbility. 8. Examine fine-grained connection detail. There are many data available for a given connection (such as fine-grained TLS information) that are not currently exposed on the GETINFO interface. We could make most of this available for testing, pending security analysis. 9. Examine cache in detail In the past we've seen crazy issues with our descriptor caching code. It might be good to expose for testing information about where exactly descriptors are stored, what attributes are set on them, and so on. We could also expose events for cache compaction and discarded expired descriptors. 10. Fetch literal documents Currently there's no way for a controller to ask Tor to download a given descriptor or microdescriptor or networkstatus. That could change. 11. OOM stats To resist out-of-memory attacks, we track our memory usage and kill off circuits as needed when memory gets low. We could expose the memory thresholds and current sizes via one or more controller commands. 12. Timeout values Tor has a truly huge variety of internal timers to ensure that given periodic events happen enough; we could expose those, and (TESTING ONLY) allow controllers to adjust them or trigger their corresponding events. 13. Detailed connection debugging info Current connection events expose only large-scale state changes in connections; we could instead expose every state transition at the cell-by-cell handshake level. 14. Detailed circuit debugging info As 13 but for circuits. 15. Halt main loop except for control layer. (TESTING ONLY) For inspection/debugging purposes, it might be clever to have Tor be able to freeze itself, except for the control layer, and let the controller inquire about information. This presents implementation challenges, and is probably not a great idea to do before a _big_ refactoring. 16. Service a single connection (TESTING ONLY) Currently controllers can disable circuit construction or stream attachment, and do them manually. We might also do this for connections, allowing a testing controller to trace what Tor does cell by cell on a single connection. 17. All rephist data There are many data about history and usage in rephist.c (which stands for 'reputation and history!'). We could expose them, to let us better test them. Some of this might be useful for Seth (previously arm) users. Spec: This would use GETINFO extensions, and probably some new events. 18. All ratelim data Sometimes our rate-limiting code can get wonky. It would be great to expose it to Tor controllers in order to help ensure it's behaving correctly. This would include send/receive windows and bw stuff. Spec: This would use GETINFO extensions, and probably some new events. 19. All accounting data As 17, but for hibernate.c, which performs bandwidth accounting. 20. All guard transitions Our guard node state logic is very complicated, and much in need of testing and refactoring. Exposing more state transitions and guard selection transitions to the controller might help. (We have a "GUARD" event now, but it is a bit out of sync with the main implementation) 21. All key transitions We could generate events every time we change keys, and (TESTING ONLY) allow a controller to time-out a key early. 22. Examine mux settings (TESTING ONLY) The circuitmux code that we use to decide which cell to send next is very complex; it would be good to expose its thinking and decisionmaking to a testing controller for better observation. 23. Examine pathbias settings Our pathbias code is also complex, and a bit flakier than the circuitmux code. We could do for it as with 22 above. 24. Examine cpuworker queues As of 0.2.6, we have a new cpuworker infrastructure that better sends data to worker threads, but not much visibility into how well it's working. Exposing some information about this to the controller could help us tune better. 25. All geoip data As 17, but for any geoip information we aren't currently exporting. 26. Replay detection For hidden service security (and maybe eventually for secure ntor Y reuse) we have to keep replay caches to prevent us from being tricked into handling the same value twice. We don't expose the load on these caches to the controller, however. And we could, to help us better tune them into using a good memory/error-rate trade-off. 27. Hidden service intropoint changes, desc changes, uploads Many hidden service transitions currently generate no events. We could at minimum generate events for changed inroduction points, changed hidden service descriptors, uploading our own HS descriptor. 28. Descriptor uploads. We have an event for when our descriptor has changed, but not for a successful upload for it. We could fix that. 29. Path generation logic -- expose, allow. Currently a controller's only visibility into path selection logic is in its outputs, and in the opportunity to replace path selection logic entirely. We could expose more details about the algorithm's operation in order to help better test our path selection. 30. All PT status information. Pluggable transport feedback is, at present, very coarse-grained. For testing we might expose more. 31. Crypto operation counts. We ought to keep count of our various cryptographic operations, and expose them to the controller. This would help us know where to spend our optimization efforts. 32. Forget cached information To better test our download logic, it would be helpful to have a way to drop items from our caches. IMPLEMENTATION NOTES: ===================== Not lightly does one list 31 controller improvement areas. If we're hoping to do these without too much programmer time and , we need to take a much more principled approach to implementing controller commands. For #8351 I worked on a branch called 'ticket8351' that has some code we could use here. COMPATIBILITY NOTES: ==================== Many of the features here are ones that we might not want to promise to support indefinitely; we should gate them behind a USEFEATURE command, and maybe place them in an annex of the control spec.

7 10

Tagged and moved tickets based on triages spreadsheet
by Nick Mathewson 09 Apr '15

09 Apr '15

Hi, all! Since Isabela is ill (get well soon, Isabela!), I've tried to translate the results of 0.2.7 triage onto the bugtracker. To ensure that everything is reversible, I've tagged items with: 027-triaged-1-in 027-triaged-1-out 027-triaged-1-deferrable. I've then moved all of the 027-triaged-1-out items that didn't already have code into 0.2.???. Perhaps the rest should follow them soon. I've likely messed something up at some point; not too much, I hope. Here are the items that have found their way into the 0.2.7 milestone that I did not see on the triage spreadsheet: https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… I suspect this isn't our last triage round, and that once Isa is back in action (get well soon!) she'll have improvements to make. cheers, -- Nick

1 0

Tor Summer of Privacy [ Incorporating ruleset testing into https-everywhere release process ]
by karan grover 09 Apr '15

09 Apr '15

Hello there! I am Karan Grover. I am a 2nd year computer science student at IIIT Delhi. I am a part of my college's Cybersecurity Education and Research Center, which is the first of its kind in the country. I have worked primarily in the field of Privacy and Security of Online Social Media (PSOSM). I am interested in contributing to Tor as a part of Tor Summer of Privacy. The project I am interested in working on is *Incorporating ruleset testing into https-everywhere release process*. I have been understanding the codebase of *https-everywhere-checker, *and am now quite familiar with it. I would like to discuss further about what the project entails. I contribute to open source every now and then, but am now looking to be an active open source contributor and Tor seems to align with my interests. Looking forward to your reply. Thank you.

2 1

Orfox (Firefox for Android) - Recent Updates
by Amogh Pradeep 09 Apr '15

09 Apr '15

Hey guys, At the Valencia meet I got Orfox building again with the latest mozilla code and since then, I've been trying to get the project back on track. The current repo can be found at[0] After going through the source code for firefox for andoroid, these were the network related findings that I've made. The application uses maily 3 layers to work. 1) The core layer, written in C++. 2) A JS layer with some more functional code. 3) A Java layer that makes uses the Android API's and other code used for android. Out of the 3 layers, 2 of them make network calls. 1) The C++ layer. There is an advantage of this layer making the network calls as all the calls made by this layer are proxied. They obey the fennec settings for proxy that has currently been set at mozilla-central/mobile/android/app/mobile.js . Hence, we do not need to bother about setting proxy to these connections and calls. 2) The Java layer. The Java code, the code run by android also has many network calls but the problem is that these calls are not done obeying the tor proxy and hence they are harmful. List of places where these calls are made are: a) any class which imports org.apache.* (commons.net.ftp.*, http.*): build/mobile/sutagent/android/DoCommand.java build/mobile/sutagent/android/SUTAgentAndroid.java mobile/android/base/distribution/Distribution.java mobile/android/base/favicons/LoadFaviconTask.java mobile/android/base/tests/BaseRobocopTest.java b) The browser also seems to be using another library for network communications and that lies at mobile/android/thirdparty/ch/boye/httpclientandroidlib This library seems to have proxy support but the calls made to this library have not been proxied, a list of those are [1] NOTE: Not all these classes listed there make network calls, I will make a shorter list of this in the next few days. [0] https://github.com/amoghbl1/gecko-dev/tree/dev_orfox [1] https://dxr.mozilla.org/mozilla-central/search?q=ch.boye.httpclientandroidl… Feedback on what you think would be very useful and much appreciated. Best, amoghbl1

1 0

Aspirant for Tor Summer of Privacy ( for Improving Tails)
by Saket Sinha 08 Apr '15

08 Apr '15

Hi, I would like to participate to Tor Summer of Privacy by contributing to "Improve Tails by working on Debian". I have worked on Debian packaging and build systems and find this project a match for my technical skills. Kindly let me know how to go ahead with this. Regards, Saket Sinha

2 3

Please vote on times for the Pluggable Transports, Bridges, and BridgeDB Meeting!
by isis 07 Apr '15

07 Apr '15

Hello! Did you have an interest in attending the Pluggable Transports Meeting v1.0? Well then, you will certainly be excited to here about the *BRAND NEW* Pluggable Transports Meeting v2.0!!!! *NOW INCLUDING DEVELOPMENT DISCUSSION OF BRIDGEDB AND BRIDGES IN GENERAL* That's 3 meetings for the price of 1!! Wow!!! Please take a moment away from your undeniable shock and ecstatic joy at this great news to vote for a new time for this combined meeting: http://doodle.com/tn28wgzw8iydpznp Thanks! -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

3 4

Contact Stem example authors.
by Lluís 06 Apr '15

06 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello everybody, After completing the "Stem" tutorial I tried to run one of the examples it points to, the "RTT Prober". I succeeded. However, after patching, recompiling and running the tor version they recommend, I had to change the python sources. I would share my results, but I really don't know how to contact the authors. May someone put me in touch with them ? Thanks, Lluís -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVImFvAAoJEJOS0D3m/rNlr3gP/1OEQI2NBAvEEAdTVgRPpuoc VMDnKt1PdjWDy+HTPyXAqki5eVzh8dyOYAla8yg38bxr5wCL1relUhkQzFyQb61h wXBTqvPzgJQOfcVj/V7h3CBPzkbXgfyaJIuOD0+NvSBLVf9W4keigA7cZ7uUE7d8 UQKnj30pFjC98CZt9Uq5ziyQqxq3xzzNHQfu5YE9YpQdYy6fm5t37I4Qm7ZXxin5 JI3nxvL34CKKXgBkxsqf+zY8f+Yoo7uFl1n+Fm+wyXc0aqi4MTzjHY7tm0cvgg/i qtxcBxJlLQu73srrbMXW9T4+o4dgRtegN8/hvRPnSOw7c520G8/2HODJ+EtEHXGm eFnNnZDHtOCjzCq9R8QcHXlEtSdXRdfxh3uI5AhPzEIM+Mx3Vtl8Y8lSMgsR0anD 0B0mGd25zgS7aLk6tuPzTKJ4B7ae1k2jsWYY3z4mziriGr+s61SiS0uWDdH3cUJb EnKVii5N5w0Tn2pJwStJrlecUkgHe6gTIJ1U5YYY2Raa/+sKKRDABAOUH+j2qV3n TL5utyQ+koszVwEreRf6q6IadHH1PxmqNd6MG6WLtejYWEqeWJy8BhK90HeOShTG ckR9OxeO5ZIZBOO8+XmaPdF8mam+hQxDU079rmoH3X+dvXVt+jPpcW+vEBzzwiG1 yx21KPu21u/TiAR6KbDd =pYKC -----END PGP SIGNATURE-----

2 2

Tor Summer of Privacy
by Damian Johnson 06 Apr '15

06 Apr '15

Do you want to make Tor even better, and get paid in the process? If you are a student, we have good news for you: the Tor Project is pleased to announce our first Summer of Privacy! https://trac.torproject.org/projects/tor/wiki/org/TorSoP Thanks to Google, over the last eight years Tor has mentored 53 students over summers. This year the program was trimmed back to make room for new organizations. So, rather than wait another year we're starting a program of our own! The Tor Summer of Privacy is a pilot program for students that want to collaborate and develop privacy tools. So why apply? * You will work with a world-class team of anonymity experts and developers on an anonymity network that is already protecting millions of people daily. * We only write free (open source) software. The tools you make won't be locked down or rot on a shelf. * Your work could contribute to academic publications. Tor development raises many interesting research questions. * You can work your own hours in your own locations. As long as you get the job done, we don't care about the process. * ... oh, and of course there's also the $5,500 stipend for the summer. :P We are looking for great coders who are self-motivated and able to work independently. The deadline for applications is April 17th, 2015 which is right around the corner, so don't be shy - apply!

1 0

multi-instance tor with a single torrc
by Nusenu 03 Apr '15

03 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Pascal, (OpenBSD tor package maintainer) (splitting this part off to tor-dev, since it is not suited well for tor-relays I guess) For the interested reader this discussion started here [1]. Pascal Stumpf: >> Multi-instance support isn't something that's provided by >> OpenBSD's rc.d(8) subsystem, and I doubt it ever will be. Too >> much complexity for something that's more of a crutch to work >> around few applications' limitations than something universally >> needed and useful. > >> I think the real solution would be to talk to upstream about >> improving MP scalability. Even if it's just something as >> primitive as forking a child for every ORPort directive in >> /etc/tor/torrc, it would be much easier than having to keep track >> of a bazillion individually started tor instances, all with their >> own configuration files. I guess this (forking one tor instance per ORPort line) sounds a lot simpler than it actually would be. How do you handle ControlPort, HS, DataDir, ExitPolicy and basically any other config option, ... but since I need a solution in the near future I'll probably just go with multiple services on OpenBSD. thanks, Nusenu [1] https://lists.torproject.org/pipermail/tor-relays/2015-April/006741.html -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVHuIaAAoJEFv7XvVCELh03H0QAKpg05vfOS/DTJ6Qhl7TfQV/ pKiAHjVfbWOfBD4vfqMHX0H054l7WfRUUiSz6gZ9DRGwXj7uDXh59kjsNa2ipMvK 4YYvDXjUIh3UBZdDnjLrkRPI5Lws1PuCi6wvnFX+e/weWiWQ18N/2HALaluhyldI 3aiDWA3k0ZnZVkuLLpbkxvbol8HS0upMTkwWlba/QXdWflK3it6sydkIi8EMhMx4 cEfTRCvWjxxU5YguIQ7/NpNFpKvRCtUEoCKBLjXuUGKTvawQ+Xu+XJQeSqE/yOqO Z1lTSQqH4i7JjBGEMxXQP/U7B3gELxv2tRcpfImGQZArLim41VPTVXse2+dPhb4d 0Knl19yYxtd4gjtoMbnv3GEPNgj2xnBr8e2MEYDsRY+rGYFnHEtnPvmJmC5p/vtX NAcuReFLd+y3j2PuB0XJHlGYOLtzvtaXJdiqV6oq42Mu0VHpiGfbTfKi2k8ZMUTw PfLQjx9z3dQ6GleC1mGHdMeJ7bJ7Wk2dJ7dicLF0veY5/Gc7gkYtWibsLXggTwrQ K0IqXnGJ8fWM41ZO4hhpmkkywhXodLzlWlXCxgxDUBsuFci/mVvtfu6ylxh+LCqG y5TxIk1T4/i+atx7jvuMLgrZGf02YgFyCf15Swj+VoDxx8GAxJl9nEQx0jD5d+Zl 206/+0QAI5hksaedorvj =qUCf -----END PGP SIGNATURE-----

1 0

Summary of meek's costs, March 2015
by David Fifield 03 Apr '15

03 Apr '15

Here's the summary of meek's CDN fees for March 2015. Earlier reports: https://lists.torproject.org/pipermail/tor-dev/2014-August/007429.html https://lists.torproject.org/pipermail/tor-dev/2014-October/007576.html https://lists.torproject.org/pipermail/tor-dev/2014-November/007716.html https://lists.torproject.org/pipermail/tor-dev/2014-December/007916.html https://lists.torproject.org/pipermail/tor-dev/2015-January/008082.html https://lists.torproject.org/pipermail/tor-dev/2015-February/008235.html https://lists.torproject.org/pipermail/tor-dev/2015-March/008427.html App Engine + Amazon + Azure = total by month February 2014 $0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014 $0.69 + -- + -- = $0.69 June 2014 $0.65 + -- + -- = $0.65 July 2014 $0.56 + $0.00 + -- = $0.56 August 2014 $1.56 + $3.10 + -- = $4.66 September 2014 $4.02 + $4.59 + $0.00 = $8.61 October 2014 $40.85 + $130.29 + $0.00 = $171.14 November 2014 $224.67 + $362.60 + $0.00 = $587.27 December 2014 $326.81 + $417.31 + $0.00 = $744.12 January 2015 $464.37 + $669.02 + $0.00 = $1133.39 February 2015 $650.53 + $604.83 + $0.00 = $1255.36 March 2015 $690.29 + $815.68 + $0.00 = $1505.97 -- total by CDN $2405.82 + $3007.42 + $0.00 = $5413.24 grand total The number of simultaneous users was up again in March, reaching 2000 simultaneous users some days. The fluctuation between weekdays and weekends was greater than we've seen before. https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… We moved something over 9 TB in March. We're getting close to where CDNs start offering price breaks :/ == App Engine a.k.a. meek-google == At the end of February, I tried tweaking some performance parameters to try and reduce instance hours. It seems like it worked, as instance hours were down 31% as bandwidth was up 29%. Here is how the Google costs broke down: 5316 GB $637.93 2173 instance hours $108.64 Compared to the previous month: 4114 GB $492.71 3226 instance hours $157.82 https://globe.torproject.org/#/bridge/88F745840F47CE0C6A4FE61D827950B06F9E4… == Amazon a.k.a. meek-amazon == meek-amazon was up quite a bit compared to the previous month. Requests were up 6% and bandwidth was up a whopping 42%. The big increases were in the Asia Pacific (Singapore) region and EU (Ireland) region. I think we're going to go ahead with removing meek-amazon from Tor Browser. This will take a little bit of work--I'd like there to be a blog post that explains how to set up your own Amazon instance if meek-amazon is currently working for you. I also would like to try and work out any performance issues with meek-azure in order to use it as a replacement. Weirdly, there were over 24,000 plain HTTP requests from the US East region. That is strange because meek is HTTPS-only. The number of HTTP requests is still small compared to the 44,000,000 HTTPS requests received from the same region, but it's far above other regions, which have at most a few dozen HTTP requests. Asia Pacific (Singapore) 171M requests $205.57 1433 GB $195.60 Asia Pacific (Sydney) 156K requests $0.20 1 GB $0.17 Asia Pacific (Tokyo) 10M requests $12.05 70 GB $9.07 EU (Ireland) 158M requests $190.03 1486 GB $118.34 South America (Sao Paulo) 3M requests $6.70 17 GB $4.03 US East (Northern Virginia) 44M requests $44.00 378 GB $29.92 -- total 386M requests $458.55 3385 GB $357.13 https://globe.torproject.org/#/bridge/3FD131B74D9A96190B1EE5D31E91757FADA1A… == Azure a.k.a. meek-azure == https://onionoo.torproject.org/bandwidth?fingerprint=AA033EEB61601B2B7312D8… Estimated bandwidth use this month: 2015-03 737 GB Compared to last month: 2015-02 614 GB https://globe.torproject.org/#/bridge/AA033EEB61601B2B7312D89B62AAA23DC3ED8… David Fifield

1 0

Tor hangs at startup
by spriver 01 Apr '15

01 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, the Tor software has a odd behaviour on my Debian machine; it hangs when I start it via "service start tor" on my Debian (Wheezy 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2) with Tor (0.2.4.26-1): service tor start [ ok ] Starting tor daemon... And then nothing happens anymore, I have to kill the dialog with ^C. As I figured out Tor starts correctly in the background (the logfile tells me so) and also opens my ORport and Dirport (netstat told me). Is this a bug or a behaviour that is supposed to be that way? Cheers, spriver -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJVHEYUAAoJEMkUf8VoejgP1GYP+wWnfllpVIC942S6PvHW9lx0 wPp6aHYBFL46Fg/r2pO8+rz7L1E1M72V0lYiqkiuzRs7IW2DYgfBVMpTz5+EoPk4 vGf+vPnyDR5hmVEM4sJbtfawb7CsK6dps/4sU6QuxfPCQE8IEII4JxbP8krobrcL 7nQAr8PPwVnuwbZGf9eqHNN4fZUnmZv8bPTtwpPB7ie8lOMzeJVCiEMU8NXKIe3K 9Wui7vatgNvTqldrHLI0DJZRJJ86V/+Q4aSJ6hvH0C7JuB+tO7sOLlplIKLxYkb5 eXFzBUhqESslsGc07k8wVhytaYSEhsG3Y0xh18gcA2rZF3kf6zi4roK2wWECyV+/ 7WsVQhQ0zJm2CUbprYKCAMqBHGm2fKdRLo+OyXQCzfO/Gn75NX2aWZBaAjZ3Ppt5 IMTdQh9UZzEPnrogjLVRwq8JvQBKNgMVe72zstMvnGtqevJuvu8bY/2EjAoK9085 UBiJyaOM8VoCf0CeEgiXijzf3dtzL6FSA78kQFlb1KWNm20PJxWaZ4YqK1vWHP/o vHWz8w0252WaM1WF1raQFqVuMz4z5QFrjMOeGxkDoq2kDVaYDfwifQntzgspqOgG CJzefHrob3cAEDPoFlPiod8k/RxHg9e1nJnLYORCbCuh5pqGL95NCA6f6/zE7xxb eeu7eDN823KTBbwriyrU =RZWR -----END PGP SIGNATURE-----

1 0