Re: [tor-talk] stronger anonymous macosx
Apple is known for its proprietary. So you will not know for shure what your os is sending home. You can use a Tor-Proxy for instance on raspi to send principially all your traffic trough tor, but you probably will be deanonyized prinzipially by the information that will be send through. I think best way will be simply booting tails. On Wed, February 18, 2015 20:14, zorx nko...@fdn.fr wrote: Hi Tor community, I would like to know if we can boost anonymous and security on mac os x. Because a simple install of tor browser could be a little light for anonymous web. I look for a stronger tor with a max of security on mac os x. How I can tuning it? Thank you. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Tor Browser Bundle with Chromium
What are the reasons that makes building a Tor Browser using Chromium not such a good idea? I recall reading somewhere that while making a Tor Browser with a Chromium base would have its benefits due to Chromium's superior security model (i.e. sandboxing), there are serious privacy issues that would have to be solved to make that possible. My question is what are those issues? What is preventing someone from digging out all the Google integration and possible privacy-endangering features and making a Tor Browser Bundle out of it? --Luis -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser Bundle with Chromium
Luis writes: What are the reasons that makes building a Tor Browser using Chromium not such a good idea? I recall reading somewhere that while making a Tor Browser with a Chromium base would have its benefits due to Chromium's superior security model (i.e. sandboxing), there are serious privacy issues that would have to be solved to make that possible. My question is what are those issues? What is preventing someone from digging out all the Google integration and possible privacy-endangering features and making a Tor Browser Bundle out of it? https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs I think that list is kept relatively up-to-date. More generally, there are a lot of customizations in Tor Browser to turn off or alter Firefox features that might identify a user (by making one Tor user's browser look recognizably different from others) or might bypass the proxy (causing the browser to send non-Torified traffic over the Internet). The Tor Project hasn't received a lot of help from the Chromium developers on changes that would be important for making these customizations -- but with or without that help, they would be a lot of work in their own right, just as they were a lot of work on the Firefox side. You can read about some of the customizations in the Tor Browser design document at https://www.torproject.org/projects/torbrowser/design/ -- Seth Schoen sch...@eff.org Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Onion Proxy Library
Hopefully the code looks pretty familiar since it all came from Orbot and Briar in the first place. You may also want to look at our backlog. I haven't managed to convince Pivotal Tracker to give me a direct link so to see the backlog: 1. Navigate to https://www.pivotaltracker.com/n/projects/1163162 2. On the left hand side of the screen click on 'Epics' 3. The first epic is Tor Onion Proxy Library with a right facing arrow on the right side. Click on that. Now you can see our backlog. Thanks, Yaron From: tor-talk tor-talk-boun...@lists.torproject.org on behalf of Nathan Freitas nat...@freitas.net Sent: Thursday, February 19, 2015 3:01 AM To: tor-talk@lists.torproject.org Subject: Re: [tor-talk] Tor Onion Proxy Library On Wed, Feb 18, 2015, at 08:17 PM, Yaron Goland wrote: I just updated the Tor Onion Proxy Library [1]. The library will set up a Tor Onion Proxy and help you connect to it as well as use it to host a hidden service. It provides an AAR for Android and a JAR for Linux, OS/X and Windows. Thanks for updating us and reminding me of this important effort. We are looking at breaking up Orbot to be more modular itself, and may utilize your work to do so, along with our PLUTO effort for pluggable transports. The updates are: Re-wrote the readme to provide some sample code Changed build process to simplify it Updated binaries for Android, Linux, OS/X and Windows to Tor 2.5.10 Updated Android project to work with SDK 21 Updated Android binary to use PIE so it will work on Lollipop Thanks, Yaron [1] https://github.com/thaliproject/Tor_Onion_Proxy_Library/releases/tag/v0.0.2 From: Yaron Goland Sent: Thursday, July 24, 2014 6:32 PM To: tor-talk@lists.torproject.org Subject: Tor Onion Proxy Library I work on the Thali project [1] which depends on being able to host hidden services on Android, Linux, Mac and Windows. We wrote an open source library to help us host a Tor OP that that we thought would be useful to the general community - https://github.com/thaliproject/Tor_Onion_Proxy_Library The library produces an AAR (Android) and a JAR (Linux, Mac Windows) that contain the Guardian/Tor Project's Onion Proxy binaries. The code handles running the binary, configuring it, managing it, starting a hidden service, etc. The Tor_Onion_Proxy_Library started off with the Briar code for Android that Michael Rogers was kind enough to let us use [2]. We then expanded it to handle running on Linux, Mac and Windows. The code is just a wrapper around Briar's fork of jtorctl (originally from Guardian I believe) and the latest binaries from Guardian and the Tor Project. This is an alpha release, version 0.0.0 so please treat accordingly. I hope y'all find it useful. Thanks, Yaron [1] http://www.thaliproject.org/mediawiki/index.php?title=Main_Page [2] Specifically he dual licensed the code under Apache 2 so we could use it. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Obfsproxy: Multiple ServerTransportListenAddr lines obfs4
Hi, I want Obfsproxy to listen on both IPv4 and IPv6 interfaces by using the following lines in torrc: ServerTransportPlugin obfs2,obfs3 exec /usr/bin/obfsproxy managed ServerTransportListenAddr obfs2 0.0.0.0:42862 ServerTransportListenAddr obfs3 0.0.0.0:49991 ServerTransportListenAddr obfs2 [2001:::63:7572:6c79]:42862 ServerTransportListenAddr obfs3 [2001:::63:7572:6c79]:49991 I noticed, only the first line gets interpreted for each Obfsproxy protocol. I can force to listen only on IPv6 by commenting out the lines for IPv4, but I'd prefer to have a dual-stack bridge. I don't remember having this behaviour the first time I installed an Obfsproxy bridge. If I remember correctly, it worked previously, but meanwhile it is broken. Anyway, I just noticed, there is a new protocol, obfs4, but I don't know anything about it. Should I adopt this new protocol? If so, how can I do that? Is it already available in the DEB repository at http://deb.torproject.org/torproject.org? What is the minimal Ubuntu release for which it is available? Regards, MegaBrutal -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Onion Proxy Library
On Wed, Feb 18, 2015, at 08:17 PM, Yaron Goland wrote: I just updated the Tor Onion Proxy Library [1]. The library will set up a Tor Onion Proxy and help you connect to it as well as use it to host a hidden service. It provides an AAR for Android and a JAR for Linux, OS/X and Windows. Thanks for updating us and reminding me of this important effort. We are looking at breaking up Orbot to be more modular itself, and may utilize your work to do so, along with our PLUTO effort for pluggable transports. The updates are: Re-wrote the readme to provide some sample code Changed build process to simplify it Updated binaries for Android, Linux, OS/X and Windows to Tor 2.5.10 Updated Android project to work with SDK 21 Updated Android binary to use PIE so it will work on Lollipop Thanks, Yaron [1] https://github.com/thaliproject/Tor_Onion_Proxy_Library/releases/tag/v0.0.2 From: Yaron Goland Sent: Thursday, July 24, 2014 6:32 PM To: tor-talk@lists.torproject.org Subject: Tor Onion Proxy Library I work on the Thali project [1] which depends on being able to host hidden services on Android, Linux, Mac and Windows. We wrote an open source library to help us host a Tor OP that that we thought would be useful to the general community - https://github.com/thaliproject/Tor_Onion_Proxy_Library The library produces an AAR (Android) and a JAR (Linux, Mac Windows) that contain the Guardian/Tor Project's Onion Proxy binaries. The code handles running the binary, configuring it, managing it, starting a hidden service, etc. The Tor_Onion_Proxy_Library started off with the Briar code for Android that Michael Rogers was kind enough to let us use [2]. We then expanded it to handle running on Linux, Mac and Windows. The code is just a wrapper around Briar's fork of jtorctl (originally from Guardian I believe) and the latest binaries from Guardian and the Tor Project. This is an alpha release, version 0.0.0 so please treat accordingly. I hope y'all find it useful. Thanks, Yaron [1] http://www.thaliproject.org/mediawiki/index.php?title=Main_Page [2] Specifically he dual licensed the code under Apache 2 so we could use it. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor and HTTP/2?
does Tor browser team know of problems with this new HTTP flavor? Don’t know if those problems can impact Tor browser, but I already notice some trouble with TLS reusage on HTTP/2 https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/.html Perhaps the TLS behaviour allow easier way to alter anonymity. -- Aeris Protégez votre vie privée, chiffrez vos communications GPG : EFB74277 ECE4E222 OTR : 922C97CA EC0B1AD3 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor over SSH (torsocks) (?)
blo...@openmailbox.org: Is torsocks still a safe way to do this? I can't say anything interesting about torsocks as a program, and am a happy user. But there are some interesting gotchas, mostly caused by the convenient but unnecessary *magic* in modern interactive shells. One example: Type $ torsocks git push local_brach:remote_br into a bash prompt on a stock Debian system (with real branch names and the name of the remote branch not complete). Then press tab for auto-completion. The branch name will actually be auto-completed, but the connection to the repository needed to get the list of branche names won't use torsocks and Tor. Die ich rief, die Geister, / Werd' ich nun nicht los. There are ways to solve such problems though, like `man iptables` and a lot of free time. Or just using Tails. I have no idea if similar problems also apply to ssh. Cheers! -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor over SSH (torsocks) (?)
On 16 Feb (00:27:40), James Murphy wrote: On 02/15/2015 03:22 PM, blo...@openmailbox.org wrote: I want to login to my VPS over SSH. Is torsocks still a safe way to do this? A lot of the documentation (such as it is) is several years old. I would also like to know this. SSH hidden service setup and use are easy with torsocks. /etc/tor/torrc HiddenServiceDir /var/lib/tor/ssh_service/ HiddenServicePort 22 127.0.0.1:22 Then torsocks ssh user@xxx.onion works like a charm. Can anyone comment on security of torsocks? (So yeah I sent that a week ago and didn't notice that I used the wrong email address for the list so here it is) Torsocks was rewritten alost from scratch due to design issues and the code was unmaintained since 2009. This new version is 2.0 and is now packaged by most Linux distros. https://people.torproject.org/~dgoulet/torsocks/ git: https://gitweb.torproject.org/torsocks.git Now, that effort did improved the safety of it I would say quite a bit. I won't go in the technical details but it's better and maintained now. That being said, know this, torsocks is a best effort, it's not a silver bullet and it's easy to design an application that will bypass torsocks. However, you can be confident with a bunch of stuff such as ssh, wget, netcat, etc... It's extensively used with those applications on a daily basis. Tails and Whonix for instance rely on torsocks for some applications (note that their firewall gives them extra protection). I know that people are using torsocks with postfix and it works well. I would be happy to detail technical details of torsocks if someone would like to, maybe a blog post? Cheers! David -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor and HTTP/2?
Georg Koppen: Lara: intrigeri: Tor can transport basically anything that lives on top of TCP. Assuming HTTP/2 is TCP, then there's basically nothing to do on the Tor side, it should just work :) Right. But see the WebRTC issues, does Tor browser team know of problems with this new HTTP flavor? Yes. We talked to Marc Nottingham a while back which uncovered a bunch I meant Mark Nottingham, sorry about that. Georg signature.asc Description: OpenPGP digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Tor 0.2.6.3-alpha is now released!
Hi, all! The second alpha release for the 0.2.6 series has just been tagged and uploaded. You can download the source code from the website right now. Packages should become available some time over the next several days. The 0.2.6 series is now in hard feature freeze. No new feature proposals will be considered. Only regression bugs, major bugs, and significant security issues will be considered for fix. I hope we can get this one stable soon as we start on 0.2.7 development. greetings from a snowy place, -- Nick Changes in version 0.2.6.3-alpha - 2015-02-19 Tor 0.2.6.3-alpha is the third (and hopefully final) alpha release in the 0.2.6.x series. It introduces support for more kinds of sockets, makes it harder to accidentally run an exit, improves our multithreading backend, incorporates several fixes for the AutomapHostsOnResolve option, and fixes numerous other bugs besides. If no major regressions or security holes are found in this version, the next version will be a release candidate. o Deprecated versions: - Tor relays older than 0.2.4.18-rc are no longer allowed to advertise themselves on the network. Closes ticket 13555. o Major features (security, unix domain sockets): - Allow SocksPort to be an AF_UNIX Unix Domain Socket. Now high risk applications can reach Tor without having to create AF_INET or AF_INET6 sockets, meaning they can completely disable their ability to make non-Tor network connections. To create a socket of this type, use SocksPort unix:/path/to/socket. Implements ticket 12585. - Support mapping hidden service virtual ports to AF_UNIX sockets. The syntax is HiddenServicePort 80 unix:/path/to/socket. Implements ticket 11485. o Major features (changed defaults): - Prevent relay operators from unintentionally running exits: When a relay is configured as an exit node, we now warn the user unless the ExitRelay option is set to 1. We warn even more loudly if the relay is configured with the default exit policy, since this can indicate accidental misconfiguration. Setting ExitRelay 0 stops Tor from running as an exit relay. Closes ticket 10067. o Major features (directory system): - When downloading server- or microdescriptors from a directory server, we no longer launch multiple simultaneous requests to the same server. This reduces load on the directory servers, especially when directory guards are in use. Closes ticket 9969. - When downloading server- or microdescriptors over a tunneled connection, do not limit the length of our requests to what the Squid proxy is willing to handle. Part of ticket 9969. - Authorities can now vote on the correct digests and latest versions for different software packages. This allows packages that include Tor to use the Tor authority system as a way to get notified of updates and their correct digests. Implements proposal 227. Closes ticket 10395. o Major features (performance): - Make the CPU worker implementation more efficient by avoiding the kernel and lengthening pipelines. The original implementation used sockets to transfer data from the main thread to the workers, and didn't allow any thread to be assigned more than a single piece of work at once. The new implementation avoids communications overhead by making requests in shared memory, avoiding kernel IO where possible, and keeping more requests in flight at once. Implements ticket 9682. o Major features (relay): - Raise the minimum acceptable configured bandwidth rate for bridges to 50 KiB/sec and for relays to 75 KiB/sec. (The old values were 20 KiB/sec.) Closes ticket 13822. o Major bugfixes (exit node stability): - Fix an assertion failure that could occur under high DNS load. Fixes bug 14129; bugfix on Tor 0.0.7rc1. Found by jowr; diagnosed and fixed by cypherpunks. o Major bugfixes (mixed relay-client operation): - When running as a relay and client at the same time (not recommended), if we decide not to use a new guard because we want to retry older guards, only close the locally-originating circuits passing through that guard. Previously we would close all the circuits through that guard. Fixes bug 9819; bugfix on 0.2.1.1-alpha. Reported by skruffy. o Minor features (build): - New --disable-system-torrc compile-time option to prevent Tor from looking for the system-wide torrc or torrc-defaults files. Resolves ticket 13037. o Minor features (controller): - Include SOCKS_USERNAME and SOCKS_PASSWORD values in controller events so controllers can observe circuit isolation inputs. Closes ticket 8405. - ControlPort now supports the unix:/path/to/socket syntax as an alternative to the ControlSocket option, for consistency with
Re: [tor-talk] Tor Browser Bundle with Chromium
Seth David Schoen: Luis writes: What are the reasons that makes building a Tor Browser using Chromium not such a good idea? I recall reading somewhere that while making a Tor Browser with a Chromium base would have its benefits due to Chromium's superior security model (i.e. sandboxing), there are serious privacy issues that would have to be solved to make that possible. My question is what are those issues? What is preventing someone from digging out all the Google integration and possible privacy-endangering features and making a Tor Browser Bundle out of it? https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs I think that list is kept relatively up-to-date. You might also like: https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study#chrome In particular, this paragraph is relevant to the recent Superfish MITM (see http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/): The worst offender on this front is the use of the Microsoft Windows CryptoAPI for certificate validation, without any alternative. This bug means that certificate revocation checking and intermediate certificate retrieval happen outside of the browser's proxy settings, and is subject to alteration by the OEM and/or the enterprise administrator. Worse, beyond the Tor proxy issues, the use of this OS certificate validation API means that the OEM and enterprise also have a simple entry point for installing their own root certificates to enable transparent HTTPS man-in-the-middle, with full browser validation and no user consent or awareness. In fact, I tried to argue with Ryan Sleevi and Adam Langley about the dangers of using CryptoAPI in this way, but I got crickets in response. I believe that supporting such MITMs is a deliberate policy from Google corporate that they cannot change. Adam went so far as to tell me that I should just fork Chromium, because they would not even consider merging an alternate browser-only cert store, even as a user option. However, since our ultimate goal with any browser fork is to re-merge with upstream so we don't have to maintain invasive patches like this, a corporate-level blocker on basic security patches is a non-starter for any project involving Chrome. P.S. How I miss the days when the outlandish doomsday scenarios that I imagined were still merely hypothetical. It seems every week a new nightmare comes true. (Man, I sure hope I'm wrong about the likelihood of wide-scale software build system attacks. I kind of like having computers). -- Mike Perry signature.asc Description: Digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser Bundle with Chromium
This is chromium bug[1] deserves more stars from the privacy community that wants to choose to use Chrome/ Chrome OS via tor. It's a different privacy/security trade off depending on your threat model. Chrome is getting much more friendly towards multiple simultaneous profiles which makes it usable to have a privacy hardened profile. I suspect the first place we see a build system attack is in court documents or a Lavabit type scenario. [1] https://code.google.com/p/chromium/issues/detail?id=447978 On Thu, Feb 19, 2015 at 2:34 PM, Mike Perry mikepe...@torproject.org wrote: Seth David Schoen: Luis writes: What are the reasons that makes building a Tor Browser using Chromium not such a good idea? I recall reading somewhere that while making a Tor Browser with a Chromium base would have its benefits due to Chromium's superior security model (i.e. sandboxing), there are serious privacy issues that would have to be solved to make that possible. My question is what are those issues? What is preventing someone from digging out all the Google integration and possible privacy-endangering features and making a Tor Browser Bundle out of it? https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs I think that list is kept relatively up-to-date. You might also like: https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study#chrome In particular, this paragraph is relevant to the recent Superfish MITM (see http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/ ): The worst offender on this front is the use of the Microsoft Windows CryptoAPI for certificate validation, without any alternative. This bug means that certificate revocation checking and intermediate certificate retrieval happen outside of the browser's proxy settings, and is subject to alteration by the OEM and/or the enterprise administrator. Worse, beyond the Tor proxy issues, the use of this OS certificate validation API means that the OEM and enterprise also have a simple entry point for installing their own root certificates to enable transparent HTTPS man-in-the-middle, with full browser validation and no user consent or awareness. In fact, I tried to argue with Ryan Sleevi and Adam Langley about the dangers of using CryptoAPI in this way, but I got crickets in response. I believe that supporting such MITMs is a deliberate policy from Google corporate that they cannot change. Adam went so far as to tell me that I should just fork Chromium, because they would not even consider merging an alternate browser-only cert store, even as a user option. However, since our ultimate goal with any browser fork is to re-merge with upstream so we don't have to maintain invasive patches like this, a corporate-level blocker on basic security patches is a non-starter for any project involving Chrome. P.S. How I miss the days when the outlandish doomsday scenarios that I imagined were still merely hypothetical. It seems every week a new nightmare comes true. (Man, I sure hope I'm wrong about the likelihood of wide-scale software build system attacks. I kind of like having computers). -- Mike Perry -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor over SSH (torsocks) (?)
Just some clarification: sycamoreone: But there are some interesting gotchas, mostly caused by the convenient but unnecessary *magic* in modern interactive shells. unnecessary is probably the wrong word. I meant not strictly necessary and not useless. $ torsocks git push local_brach:remote_br This should be $ torsocks git push repository local_brach:remote_br And looking into /etc/bash_completion.d/ (or the zsh equivalent) might be enough to see if there is any magic for the program you want to use. Cheers! -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor and HTTP/2?
Lara: intrigeri: Tor can transport basically anything that lives on top of TCP. Assuming HTTP/2 is TCP, then there's basically nothing to do on the Tor side, it should just work :) Right. But see the WebRTC issues, does Tor browser team know of problems with this new HTTP flavor? Yes. We talked to Marc Nottingham a while back which uncovered a bunch of things we need to check when we switch to Firefox ESR 38 and led to spec amendments, too. (see: https://github.com/http2/http2-spec/issues/645). The ticket tracking this effort is #14952. Georg signature.asc Description: OpenPGP digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
