Re: [tor-dev] compass: new group by options: by-contact, by-OS, by-version
On 03/19/2015 10:11 PM, Nusenu wrote: >> The MyFamily lookup is also broken > It actually works, I just expected to see more then an empty set when > entering a torservers FP. Our MyFamily statements have been broken for quite a while; it is not clear whether the statement actually provides any benefit. I believe it does, see also https://trac.torproject.org/projects/tor/ticket/6676 . -- Moritz Bartl https://www.torservers.net/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Fwd: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez!
On Thu, Mar 19, 2015, at 06:58 PM, David Fifield wrote: > What would it take to get some screenshots that show how to turn on > pluggable transports? I would like to add a guide to > https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart and > instructions to > https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Howtousepluggabletransports > . > > Or do you have such a guide I can just link to? > We're still finalizing the UI for the new features (QR code scanning, meek bridge type selection, etc) so once that is completed, we'll do a round of screenshots, guide updates, etc. This will most likely happen in early April. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] thanks redditt
Tyrano Sauro wrote: This is funny Oh, I agree :D There was an outtake where Karen (development director) was walking around with a tiny orange tree saying "Orange Routing! Orange Routing!" It was pretty great ^_^ ~Griffin -- “Sometimes the questions are complicated and the answers are simple.” ― Dr. Seuss ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] thanks redditt
This is funny Tor Project Loves and Thanks Reddit | | | | | | | | | | | Tor Project Loves and Thanks Reddit | | | | View on www.youtube.com | Preview by Yahoo | | | | | ty ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Fwd: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez!
On Thu, Mar 19, 2015 at 11:24:57AM -0400, Nathan Freitas wrote: > * Meek and Obfs4 pluggable transports are now included and working quite > well, even with the VPN mode Great, Guardian and everyone! What would it take to get some screenshots that show how to turn on pluggable transports? I would like to add a guide to https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart and instructions to https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Howtousepluggabletransports . Or do you have such a guide I can just link to? David Fifield ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Performance and Security Improvements for Tor: A Survey
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ian, Thanks for the link, and for working on the survey - this was long overdue. I especially enjoy the mind map (Figure 5) which gives a quick view of all of the work over the years. The community has been busy! On the incentives front, I believe the survey is missing a few papers. - -"Proof-of-Work as Anonymous Micropayment: Rewarding a Tor Relay" FC 2015 Short Paper, http://fc15.ifca.ai/preproceedings/paper_71.pdf - -"Paying the Guard: an Entry-Guard-based Payment System for Tor" FC 2015 Short Paper, http://fc15.ifca.ai/preproceedings/paper_112.pdf - -"From Onions to Shallots: Rewarding Tor Relays with TEARS" HotPETs 2014, http://www.robgjansen.com/publications/tears-hotpets2014.pdf - -"Payment for Anonymous Routing" PETS 2008, http://cs.gmu.edu/~astavrou/research/Par_PET_2008.pdf While the TEARS paper only appeared at HotPETs (so far), I feel like it should be included because TorCoin is cited and TEARS is more viable than the TorCoin approach (IMHO) - the reasons for this are explained in the Tor incentives blog post: https://blog.torproject.org/blog/tor-incentives-research-roundup-goldstar-par-braids-lira-tears-and-torcoin Also, all of the above, as well as LIRA, are missing from "Incentives" node of the mind map in Figure 5. I realize that this isn't necessarily an incentives survey, but most incentive schemes affect performance and some schemes were included so it may make sense to include them all. Also, it looks like there is some whitespace below the "Throttling" node, so they may fit fairly easily. Finally, there is no section on Tor simulators/emulators!? I was surprised by this, as that is definitely an area of research that has greatly helped explore performance questions. It would be great to include a section on it so that researchers reading this survey and looking to work on performance know which tools they can use to get started. Shadow, ExperimenTor, SNEAC, and Chutney are the main tools that immediately come to mind that may be useful in exploring performance questions. Hope this is useful! All the best, Rob > On Mar 16, 2015, at 12:38 PM, Ian Goldberg wrote: > > Oh, please *do* comment. We can easily (and definitely plan to) update > the ePrint tech report, incorporating the feedback we get from all of > you, and giving credit in the acknowledgements. (Do let us know how > you'd like to be credited.) Once we're happy with the result, we'll > submit a condensed (due to page limits) version to a journal. > > - Ian -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVC0mjAAoJEO3Z5w0UVGXoFGYP/iX5JBXA6XivMzEPAWouuIgH +9IphOnK6NTyatjmzSbGSmiR0W4zwSq93UsWrK/7b+NpY5RCj3TF2WK5zr2EpoZ7 GJjBmkZyOjK2ELIik/yMsc93l5e39CAllm3/fy9R7y9VJBItlWYNH3aM4ZFlr5DK 08k0FSi8vSwIHL+hpn6QF2pmuCdD6Zej4JjRUP6Uh31XGIPyvNxkDOEvQyuvDP+v 3beNEyOFtfB5kYq1wartdgIiEkCOIaVHUHp5OmnmdwNaa9EeSKsoAOsLsI6QqJ0X 3FddYrERpuvoLuDP+WXFsI9l7xtK4cTcoUkO0vI14/lzYiHC0SMmf0ZjVHoPn2k8 cr7rfyAqC5QE5T25nK4M1Bh0i43RVUkxLf36CqaFKj9hiyn6FSlPUhO/GKRpQ2oQ 2WUGbQ8PnGwCEytTr1IBpE7HLDB6i1MkLP8Djg6Hpu1e4l8LIYNj5fppSO3fBunn aPAc7/AKhG1x8doG6ur5F8G/wVykAmmgOmLBp1vsEDDNwXybrrKZZkYCUOucrqQq Of06fsys7JRT9984y/9mf4skjwoAsPCBEJWssyKnXhAlVQdN4hmlkMFvcZbIdB4B Za3Ev2ZtFp9BHCaHQNH5O8KfGb6lw8SPBp2Dyu+bABf5Js8K+B84EUKl6W4+K/lY IEfJ5GgSNQ4dd/ocyirc =2x71 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Remove "*" from pluggable transports spec?
I was going to write an email advocating for the removal of the wildcard
'*' transport specification in pt-spec.txt. But then I saw that the
current version of the spec doesn't mention the wildcard anymore; it was
replace with a TODO in
https://gitweb.torproject.org/torspec.git/commit/pt-spec.txt?id=4dcd7e94f17c072e771119ec90d7cbce4a4788a4
"TODO: Document '*' transport"
So how about we remove the TODO and just act like it never existed?
Normally tor tells the transport plugin what transports to activate by
giving it a string like "obfs3,obfs4"; but you're supposed to also be
able to pass "*", which means "activate all transports you are capable of."
Apparently this feature, though pyptlib and goptlib support it, has
never been implemented in tor itself:
Implement the wildcard "*" protocol in {Client,Server}TransportPlugin
lines
https://trac.torproject.org/projects/tor/ticket/3725
A wildcard specification doesn't really make sense, anyway. For one
example, flashproxy-client knows two transport names, "flashproxy" and
"websocket", which are synonyms. But if tor asks for "*",
flashproxy-client shouldn't open up two listeners. Another case is fog
(a dynamic transport combiner), which constructs a chain of transports
from a transport name like "obfs3_websocket". The transports can be
combined in infinite ways; it doesn't make sense to say, "activate all
of them."
https://lists.torproject.org/pipermail/tor-dev/2013-December/005966.html
Let's just drop this part of the spec, and delete some underspecified
and unused code?
David Fifield
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] compass: new group by options: by-contact, by-OS, by-version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > The MyFamily lookup is also broken It actually works, I just expected to see more then an empty set when entering a torservers FP. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVCztzAAoJEFv7XvVCELh04bIP/0a8ncpIKzAAJu6sjF+9y9Jo K7fQqyX1LTzCdNFDxR2OOQYx/jFwrFtl++yapM5LpLSoDslwQMOZdwCnyhqSnfKJ DK39R/N4Hze05aNkGXHjlgrRfm2bhfeLwlv8R1DJJIj5L/mtdGClnAzRmUg/LjgG gTuZ/8oR4Rkf8yI09k6s0BlEBQ7dv+WMFa+NxpKdMaWyNs4YecUxBdL7eX1r/F9E fdV3h+O3E/potFNMX//BrKKNYryddKlPy6DIKkTL+lSGbg5Bb5vB25AYcpHBhGeG EvMB/wNZ6jtbD7kGhf6LAVwRR4SimodsIUPgzyk1l7+4GsyVel0UzX+b0lr/bz7p SiEg1/HY0Y/52mdfcqx/wZpFe73ckkYrhd+Fa8Q/rnQtxg7CgVhtjkDtFRWOsBdt Vvn9qeVD36cp0/6TzU/Tug8bjY+z/C0QFpkyXf90T/E2jYnLOQMhuzurAhusQkw9 h+MBbEgE4d2P3v3tU9r8ZCEYYEbuyDyrFpRtkXGs4VFGRxXYEPJrFwd3RBzcvTks c+6XX5IbBGzWlWpXWUGbRnJZ15lHVLVG3uPV0Bjbu8vaNfeee/BIr2z/igRRGcxL KqNjKrcXo+6X9B+X/zL2L0f2s99ctFK02+CIJ3nuTtIvdjtEwwwPFliCQgOEQwS0 DkqTYrw1GxQN7uXLZFRC =+u7X -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Fwd: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez!
- Original message - From: Nathan of Guardian To: guardian-...@lists.mayfirst.org Subject: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez! Date: Thu, 19 Mar 2015 11:12:59 -0400 Orbot v15 alpha work is nearly done... APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-5.apk SIG: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-5.apk.asc Highlights: * Updated to tor-0.2.6.4-RC * VPN / full device "Apps" mode is fully implemented and stable - no root needed to run all apps on your device through Tor * Meek and Obfs4 pluggable transports are now included and working quite well, even with the VPN mode * Easy scanning and sharing of bridge address QR codes from bridges.torproject.org * Removed integrated webview/webkit for now, since Android WebView is generally p0wn3d More at: https://gitweb.torproject.org/n8fr8/orbot.git/tree/CHANGELOG Thanks to nickm, isis, yawning, fifield, sandro, team psiphon and many others for all the various amazing pieces coming together to make Orbot v15 a very important and big release. +n -- Nathan of Guardian nat...@guardianproject.info ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] compass: new group by options: by-contact, by-OS, by-version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Karsten, I added a few new grouping options to compass: - -T --by-contact (#6675) (Maybe we should truncate contacts and remove the undefined) - -O --by-os - -V --by-version (#6855) +expose -N options in html (was implemented but not exposed in gui) https://github.com/nusenu/tor-compass For all output I (mis)used the nick column as a quick solution since it is not used otherwise when grouping. Advertised bw is broken for some time. There is no 'advertised_bandwidth_fraction' (This field was removed from onionoo in November 2014.). Is it ok to change this to observed_bandwidth? (which would be a non fraction item)* ? (The MyFamily lookup is also broken) short commit log: - - add new group by ContactInfo option: by_contact (-T, --by-contact) (quick 'n dirty) - - added new grouping -O, --by-os (all BSDs are merged into one group) - - added new grouping by tor version (-V, --by-version) - - tell app.py about new options (by_version, by_os, by_contact) - - expose -N option in html and fix a missing label tag - - include network data in html output when using -N (uses nick column) - - expose by_version, by_os and by_contact options in HTML - - if it is just one item, display the actual value for AS and CC instead of saying (1) What do you think about it? thanks, Nusenu *) while playing with that I found 3 relays from JP that have a suspiciosly high adv bw: https://atlas.torproject.org/#details/F528DED21EACD2E4E9301EC0AABD370EDCAD2C47 https://atlas.torproject.org/#details/8901B1D2D4C0D3398C3F8363247B5AABF31369E4 https://atlas.torproject.org/#details/4EA0464A1B8D4231F176BA2FA1BCBF0A26F128D5 reminded me of SKKU43: https://lists.torproject.org/pipermail/tor-talk/2014-February/032094.html -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVCtlTAAoJEFv7XvVCELh0bY0P/1aJyZncqdy47WZM9I7Y1E4a Sg1luXTqi9VlFZhbUJeFrhidLVPSqQYbMw79sKufU2uw/Jcqr0Ro2O48q9Gj7sL8 lDcM4AgFzm1yTedoXqyNAA5+bBeQTAjEgQU1ADYUZvDx2ULmGG4aD6qCuaFoP+3/ kjJ6r92jLOSYpOVdt8FyNc8IZYpbEwQNMKc4A0uZhQV/WVv6vFiOaXHliPdR6m2+ SU+KTqldWppfeezWIalGl3t7HEnz87JOaWrdnQ8fjLKSsqkex2T5E1MClguM4u2o 5ABPxg6uF/izjPv2VEy/hl42RQbLM5SDazM4CLMFN3mQu6Xa4iZ5R8A6iLDgZBj6 zK2wExcxScc58r4Briv5EKUpC9LTgE52DkPkX+TM3i9ktniYQbb/k/cy85nn+ENa WrZ2WDmaMyQXy6kXDCS4U/3gbv1+Dwq82hg372N2fga6hOXsZPFrxV1TwWlMTzp9 MvpaF6/GZsivrjNklteHxvxgcxTyywaKW5QUdFJdeCZnOrDy29iGKIql10xQ7TXa gTC7OTsDCAPiJn8P5xKhEAlVeJmz0zZN7QhbY/ybIc5KWkOoKyYwkT9ysmpS8rOK mapKbuMXvuA3Sg1F1sK9PEUy+D8ZAe+sBjOEHzqILARA6VXsly0rSJkcnhNKNpmL yxSwWe4uWOVXDmVEl7hQ =jGQe -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Producing automated screencasts for Tor Browser
Hi, Karsten Loesing wrote (19 Mar 2015 10:04:56 GMT) : > 5. Start a screen recorder and run the Sikuli script for all three > systems and all supported languages. The Tails automated test suite uses cucumber to drive Sikuli and libvirt virtual machines. It is able to record the screen on video. Note that last time we checked, Sikuli's OCR was too fragile for us so we look for images instead. But this was 2 years ago, so maybe things have improved since. Design doc: https://tails.boum.org/contribute/release_process/test/automated_tests/ Example cucumber feature: https://git-tails.immerda.ch/tails/tree/features/torified_browsing.feature?h=stable The script to run it is: https://git-tails.immerda.ch/tails/tree/run_test_suite?h=stable The Sikuli glue code lives there: https://git-tails.immerda.ch/tails/tree/features/support/helpers/sikuli_helper.rb?h=stable Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Producing automated screencasts for Tor Browser
Hi! Karsten Loesing: > 2. Install Sikuli (http://www.sikuli.org/; thanks for Lunar for the > suggestion!) either directly on these machines or on the virtual > machine host or on a separate host in the same network. > > 3. Write a Sikuli script for each operating system and language, > probably re-using large parts, to make all the necessary steps to > download, verify, and run Tor Browser. This script may include steps > for preparing the system by changing its language and for cleaning up > afterwards. Ideally, this script can easily be maintained whenever > Tor Browser changes. I had a quick chat with intrigeri based on their experience with using Sikuli to automate Tails testing. He told me they had issues with the OCR system and that they opted for having captured images everywhere in the end. Having to update images on new Debian releases is a bit of a pain but seems to be a manageable exercice. It saddens me a bit because having working OCR would be super awesome in that the same script could be used for multiple languages by looking at the actual software translation catalogs… So it might be worth experimenting a little bit again. > 4. Record audio snippets in the various language that explain the > steps that will later be performed in the screencast. Either include > these as part of the Sikuli script, or put them together separately > and add them to the recording later. I think it's worth experimenting a little bit with starting the audio tracks as part of the script. It would make it easier to put synchronisation point in the script, and it might smooth out timings in different languages more nicely. Are there scripts (as in a textual description of the scenes and voice over) already written down somewhere? -- Lunar signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Wide block cipher experiment.
Hello, Nickm mentioned to me that he was curious as to how LIONESS performs these days (See #5460) with modern cryptographic primitives. I've conveyed the results to several people, but I'm also sending them here for posterity. Code used: https://github.com/yawning/lioness (May be incorrect, don't use for anything other than benchmarking. Numbers taken with a previous version of the code without the initial memcpy, that was added later so that the code in git could be used by the extremely brave for other things.) All measurements taked on an i5-4250U, so the usual caveats about turboboost and hyperthreading apply. Baseline (from tests/bench, AES-NI enabled): = cell_ops = Inbound cells: 231.33 ns per cell. (0.45 ns per byte of payload) Outbound cells: 224.39 ns per cell. (0.44 ns per byte of payload) (Note: Outbound with AES-NI disabled is ~3.0 ns per byte) LIONESS (BLAKE2b/ChaCha, 509 byte block size): * ChaCha20: * Ted Krovetz's AVX2-ed ChaCha20/Ref AVX BLAKE2b: ~6.6 ns/byte (~143 MiB/s) * AVX2ed-ed ChaCha20, Andrew Moon's AVX2-ed Blake2b: ~5.0 ns/byte (~190 MiB/s) * ChaCha12: * Ted Krovetz's AVX2-ed ChaCha12/Ref AVX BLAKE2b: ~6.1 ns/byte (~156 MiB/s) * AVX2ed-ed ChaCha12, Andrew Moon's AVX2-ed Blake2b: ~4.4 ns/byte (~213 MiB/s) * ChaCha8: (Yolo swag 420 blaze it) * Ted Krovetz's AVX2-ed ChaCha8/Ref AVX BLAKE2b: ~5.8 ns/byte (~164 MiB/s) * AVX2ed-ed ChaCha12, Andrew Moon's AVX2-ed Blake2b: ~4.1 ns/byte (~232 MiB/s) NB: Using Andrew Moon's Blake2b isn't in git, because the way I tested it was kind of kludgey. Profiler output: 64.04% lioness_test_av lioness_test_avx2 [.] blake2b_compress 22.43% lioness_test_av lioness_test_avx2 [.] chacha_stream_xor 6.60% lioness_test_av lioness_test_avx2 [.] blake2b_init_key 2.72% lioness_test_av lioness_test_avx2 [.] blake2b 2.41% lioness_test_av libc-2.21.so [.] __memcpy_avx_unaligned 1.07% lioness_test_av lioness_test_avx2 [.] lioness_encrypt_block Ted Krovetz's ChaCha implementation isn't quite the fastest out there, but it doesn't lag massively behind Andrew Moon's. Benchmarks on the same hardware from Andrew Moon's chacha-opt/blake2b-opt are: BLAKE2b: 576 byte(s): avx2, 1468.00 cycles per call, 2.5486 cycles/byte avx, 1674.00 cycles per call, 2.9062 cycles/byte x86, 2020.00 cycles per call, 3.5069 cycles/byte generic/64, 2638.00 cycles per call, 4.5799 cycles/byte ChaCha20: 576 byte(s): avx2, 694.00 cycles per call, 1.2049 cycles/byte avx, 1104.00 cycles per call, 1.9167 cycles/byte ssse3, 1112.00 cycles per call, 1.9306 cycles/byte sse2, 1376.00 cycles per call, 2.3889 cycles/byte x86, 2528.00 cycles per call, 4.3889 cycles/byte generic, 3200.00 cycles per call, 5.5556 cycles/byte I don't think using CTR-AES (with AES-NI) in a LIONESS construct is going to be that big of a win, at least on my hardware, and the sort of performance I'm seeing feels too much of a performance hit to me. Regards, -- Yawning Angel pgpDNb5K2d0Nd.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Producing automated screencasts for Tor Browser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi devs, we're making some medium-term plans to produce automated screencasts that explain how to download, verify, and run Tor Browser on Windows, Mac OS X, and Linux, localized to at least half a dozen languages. The focus here is really on *automated*. Whenever there's a new Tor Browser version, we'd like to minimize manual steps for creating new screencasts to the absolute minimum. Here's our plan, and we'd appreciate your feedback on this: 1. Set up three systems (Windows, Mac OS X, and Linux) either as virtual machines, using VirtualBox or VMware Fusion, or on a dedicated triple-boot Mac Mini. 2. Install Sikuli (http://www.sikuli.org/; thanks for Lunar for the suggestion!) either directly on these machines or on the virtual machine host or on a separate host in the same network. 3. Write a Sikuli script for each operating system and language, probably re-using large parts, to make all the necessary steps to download, verify, and run Tor Browser. This script may include steps for preparing the system by changing its language and for cleaning up afterwards. Ideally, this script can easily be maintained whenever Tor Browser changes. 4. Record audio snippets in the various language that explain the steps that will later be performed in the screencast. Either include these as part of the Sikuli script, or put them together separately and add them to the recording later. 5. Start a screen recorder and run the Sikuli script for all three systems and all supported languages. 6. Post-process the recording by cutting the video, attaching the audio, and possibly adding text slides at beginning and end; hopefully using scripts. Again, the goal is to keep the overhead for recording a new set of screencasts as low as possible. If it takes days to do this, nobody will do it, and we'll soon have outdated videos. What do you think about this plan? And do you have specific suggestions for the single steps? Thanks! Cheers, Karsten and Sherief -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVCp9HAAoJEJD5dJfVqbCrfTEH/2oTPvEYIZDys42MeKXmQFA9 bmVMky5sCO6/sOAx8BIVdUXF1b1m8mxPev5X2SarYCyNaZOkbtCOLyLzrFjUii0e aH7cjc6QFm31TX5oJ10O7/7Of13q4l0jYY2j0KDmzbFrNndK9t9W+nh4/xSiTdEh a3IzVnOVu4c1nE4xwCSxwqaia2xi5N8fUuZPN4ttGGVctp4ucglUwTCZodfqNUMK Jiq4UO+ZeGvPaRGPLK8sxCfnR5DrZF5i3v4YhYy5d1g0yGDNFHv61zP1PQHx3BCG 47ne5o+FDsxLxDe1w4/l7i4HvdPHP7XovkR4yckYs/6e4462QUfBxVcwIm9p6rk= =E8Kf -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
