tor-dev September 2013

tor-dev@lists.torproject.org

59 participants
70 discussions

regarding control spec for hidden service descriptor
by Qingping Hou 04 Sep '13

04 Sep '13

Hi all, I am currently working on ticket 8510: https://trac.torproject.org/projects/tor/ticket/8510 However, I notice that in the control spec, there is no event related to hidden service descriptors. Should we add a new event in the spec? For example, we can have something like the following: HS_DESC SP REQUESTED SP OnionAddress SP DescptorID SP AuthType SP HsDir SP Any thoughts? Cheers, qp

4 10

Re: [tor-dev] Pluggable Transport Browser Bundle FTE Integration
by Arlo Breault 03 Sep '13

03 Sep '13

> On Sat, Aug 31, 2013 at 09:43:21PM -0400, Kevin P Dyer wrote: > > === Building/Testing Tor on Linux/OSX/Windows > > I'm trying to understand exactly how the current build/release process works > > for tor. In regards to the PT TBB it seems like there are a few resources > > [1,2,3]. However, is there a canonical documentation on how the release process > > works? I'm especially interested in what you guys are doing to produce builds > > on Windows. Are you using virtualization or do you have a few physical build > > machines? > > [1] https://gitweb.torproject.org/pluggable-transports/bundle.git > > [2] https://lists.torproject.org/pipermail/tor-dev/2013-June/005056.html > > [3] https://gitweb.torproject.org/builders/tor-browser-bundle.git > > > > https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/bu… You may have an easier time with MinGW than Cygwin. One way to get a compatible shell environment is to install Git Bash from, http://git-scm.com/downloads

1 0

Draft of proposal "Migrate HS identity keys to Ed25519"
by George Kadianakis 03 Sep '13

03 Sep '13

Greetz, I'm posting the draft of a proposal that specifies how to upgrade the identity keys of HSes (currently RSA-1024) to use Ed25519. This proposal is supposed to go along with a proposal that specifies how to hide HS descriptors from HSDirs. I'm going to post that second proposal in a few minutes. This proposal is incredibly drafty in the sense that I might have forgotten to specify things that need to be specified. On the other hand, "release early; release often" they say, so here it goes. Inlining: Filename: xxx-hs-ecc-id-keys.txt Title: Migrate HS identity keys to Ed25519 Author: George Kadianakis Created: 10 August 2013 Target: 0.2.5.x Status: Draft [More draft than Guiness.] 0. Overview: This proposal suggests the adoption of ECDSA keys as the long-term identity keys of Hidden Services. It also proposes the adoption of ECDSA keys for the per-introduction-point service key that was introduced in the v2 hidden service protocol. This proposal specifies the key generation procedure, paths where the keys should be stored, and flagday/migration procedures. XXX 1. Motivation: Hidden Services currently use an RSA-1024 keypair as their long-term identity keys. RSA-1024 is considered weak and should be replaced. Dan Bernstein's ed25519 ECDSA scheme provides 2^128 bits of security and better signature performance than RSA. Furthermore, the keysize is much smaller than the keys of RSA. 2. Related proposals This document is part of a proposal triptych. Upcoming sister proposals are: - "Stop HS address enumeration by HSDirs", where we propose an alternative HS descriptor format that will not allow HSDirs to learn the addresses of the Hidden Services it serves. - "Deployment strategy for recent HS proposals", where we specify how these proposals should be deployed without making people angry. 3. Changes to the current HS protocol 3.0. Overview of changes to the current HS protocol There are two places where RSA-1024 is used in the current HS: Longterm RSA-1024 "identity keys" are used by the HSes to authenticate themselves to clients. Multiple short-term RSA-1024 "service keys" are used by the HSes for each introduction point so that they don't reveal their identity key. This proposal specifies: a) The generation of the new ed25519 long-term identity keys and service keys (#KEYGEN) b) The new HS descriptor format (v3) that contains identity keys and service keys (#NEWDESC) c) A way for clients to upload and fetch v3 descriptors from HSDirs (#HSDIRV3) 3.1. Generation of ed25519 keypairs (#KEYGEN) 3.1.0. Generation of long-term ed25519 identity key Compliant Hidden Services need to generate a fresh ed25519 keypair and store the private key in: $HiddenServiceDirectory/hs_ed25519_privkey For deployment and migration reasons, the new ed25519 keys must be kept alongside with the old RSA-1024 keys. 3.1.1. Generation of short-term ed25519 service keys Hidden Services generate an ed25519 service key for each introduction point -- instead of the RSA-1024 key they currently generate. 3.2. New v3 Hidden Service descriptors 3.2.0. New v3 Hidden Service Descriptor Format (#NEWDESC) v2 Hidden Service descriptors contain both the long-term identity public key of the Hidden Service, and service keys for each introduction point. It also contains a signature of the descriptor. We need to change all these fields to carry our brand new ed25519 keys. For v3 Hidden Service descriptors, we keep the v2 format and perform the following changes: [*] The "permanent-key" field is replaced by "permanent-key-ed25519": "permanent-key-ed25519" NL an ed25519 public key [Exactly once] The public key of the hidden service which is required to verify the "descriptor-id" and the "signature-ed25519". In base64 format with terminating =s removed. [*] The "service-key" field is replaced by "service-key-ed25519': "service-key-ed25519" NL an ed25519 public key [Exactly once] The public key that can be used to encrypt messages to the hidden service. In base64 format with terminating =s removed. [*] The "signature" field is replaced by "signature-ed25519': "signature-ed25519" NL signature-string [At end, exactly once] A signature of all fields above with the private ed25519 key of the hidden service. In base64 format with terminating =s removed. 3.2.1. Uploading v3 HS descriptors to HSDirs (#HSDIRV3) A new type of Hidden Service Directory Server must be established which understands v3 Hidden Service descriptors. The Hidden Service follows the same publishing procedure as for v2 descriptors but instead of sending an HTTP 'POST' to "/tor/rendezvous2/publish", the HS sends the 'POST' request to "/tor/rendezvous3/publish". (This part of the proposal conflicts with the "Stop HS address enumeration by HSDirs" proposal.) 3.3. Fetching v3 HS descriptors from HSDirs (#HSDIRV3) When a client needs to fetch a v3 Hidden Service Descriptor from an HSDir, it follows the exact same procedure as for v2 descriptors but instead of sending an HTTP 'GET' to "/tor/rendezvous2/<z>", it sends an HTTP 'GET' to "/tor/rendezvous3/<z>". (This part of the proposal conflicts with the "Stop HS address enumeration by HSDirs" proposal) 3.4. Service keys and INTRODUCE cells In INTRODUCE cells, when v2 descriptors are used, PK_ID is defined as the hash of the service key. This means that we don't need to change the format of INTRODUCE cells since we can just use the hash of the ed25519 service key. # XXX will this cause problems?

3 5

Re: [tor-dev] Help with rebasing arma's n23-5 tor branch to current master
by Karsten Loesing 03 Sep '13

03 Sep '13

(Moving this discussion back to tor-dev@ with Charlie's permission.) On 8/6/13 4:10 AM, Charlie Belmer wrote: > Hey Karsten, > > I've been reading up on Shadow & Scallion to do some performance testing on > N23. Before I go too far down that road, I wanted to check in with you. > > Are there existing blueprints or best practices I should be following? Thanks for looking into this! So, I wouldn't call the following notes blueprints or best practices, but they are a description of what I would do to run Shadow simulations of your branch. First of all, be sure to read the Shadow wiki which has contains lots of interesting stuff: https://github.com/shadow/shadow/wiki The next step would be to get a vanilla Tor master (that your branch is based on) running in a minimal or tiny Shadow network. It's probably easiest to use a local Ubuntu VM for this. Or you can start an m1.large EC2 instance for the tiny network, or an even smaller instance for the minimal network. Once that simulation succeeds, you'll want to run another simulation using your branch, extract performance metrics using Shadow's analyze script, produce a PDF with graphs also using the analyze script, and then wonder if things are faster than before. The minimal or tiny networks are mostly there to learn that things are working as expected. You'll probably want larger networks for real performance results, but starting small to get everything working is probably easier. Sounds doable, I guess. However, here's where things start to get tricky: in order to simulate Tor master (or a branch based on it) in Shadow, you'll have to perform quite a few extra steps like compiling your own CMake and Clang/LLVM. Not really hard, but you need to get all pieces together before Shadow does what you want. I'm pasting detailed instructions that I used to simulate Steven's uTP branch in Shadow below as an example. Not everything applies to your branch, but it should give you the general idea. If something remains unclear, please feel free to ask! > Depending how it goes, I'd also look at re-trying adaptive 23 or tuning the > existing implementation. Neat! We should probably include Mashael in that discussion once you have a working and simulated n23-5 branch. Maybe she has ideas what parts need tweaking. I'm cc'ing her in this mail so she knows what you're working on. In any case, having a working rebased n23-5 branch is already a big step forward. Thanks! Karsten === START OF INSTRUCTIONS === Launch new EC2 instance running Ubuntu Server 13.04 64 bit Set ulimit -n to 25000, see Shadow wiki for details https://github.com/shadow/shadow/wiki/Preparing-your-machine#system-configs… $ sudo apt-get update $ sudo apt-get upgrade Clone and test-compile modified libutp $ sudo apt-get install build-essential git automake libssl-dev libevent-dev $ mkdir src $ cd src/ $ git clone https://github.com/sjmurdoch/libutp $ cd libutp/ $ make $ cd ../ Clone and test-compile Tor branch utp $ git clone https://git.torproject.org/tor.git $ cd tor/ $ git remote add sjm217 https://git.torproject.org/sjm217/tor.git $ git fetch sjm217 $ git checkout -b utp sjm217/utp $ ./autogen.sh $ LDFLAGS="-L/home/ubuntu/src/libutp" CFLAGS="-I/home/ubuntu/src/libutp" LIBS="-lutp -lrt" ./configure --disable-asciidoc $ make $ make distclean $ cd ../ Modify Tor to use uTP for all links (or "0 &&" for not using uTP for any link) diff --git a/src/or/channeltls.c b/src/or/channeltls.c index 0551b73..b7b36e1 100644 --- a/src/or/channeltls.c +++ b/src/or/channeltls.c @@ -418,7 +418,7 @@ channel_tls_connect(const tor_addr_t *addr, uint16_t port, /* Create a uTP connection */ tor_addr_to_sockaddr(addr, port, (struct sockaddr*)&sin, sizeof(sin)); tor_addr_to_str(addr_str, addr, sizeof(addr_str), 0); - if (!strncmp(addr_str, "128.232.10.129", sizeof(addr_str))) { + if (1 || !strncmp(addr_str, "128.232.10.129", sizeof(addr_str))) { log_info(LD_CHANNEL, "Trying uTP connection to %s", addr_str); tlschan->utp = UTP_Create(tor_UTPSendToProc, tlschan, (const struct sockaddr*)&sin, Install CMake 2.8.10 $ wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz $ tar xf cmake-2.8.10.2.tar.gz $ cd cmake-2.8.10.2/ $ ./configure $ make $ export PATH=~/src/cmake-2.8.10.2/bin:$PATH $ cd ../ $ which cmake # result: /home/ubuntu/src/cmake-2.8.10.2/bin/cmake Build Clang and LLVM from source $ wget http://llvm.org/releases/3.2/llvm-3.2.src.tar.gz $ wget http://llvm.org/releases/3.2/clang-3.2.src.tar.gz $ tar xaf llvm-3.2.src.tar.gz $ tar xaf clang-3.2.src.tar.gz $ cp -R clang-3.2.src llvm-3.2.src/tools/clang $ cd llvm-3.2.src/ $ mkdir build $ cd build/ $ cmake -DCMAKE_INSTALL_PREFIX=/home/ubuntu/.local ../. $ make $ make install $ export PATH=~/.local/bin/:$PATH $ cd ../../ $ which clang # result: /home/ubuntu/.local/bin//clang Install Shadow $ sudo apt-get install gcc xz-utils make automake autoconf cmake tidy libtidy-dev libglib2.0 libglib2.0-dev dstat pdftk python2.7 python-matplotlib python-numpy python-scipy $ git clone https://github.com/shadow/shadow.git $ cd shadow $ ./setup dependencies $ ./setup build -g -i /home/ubuntu/src/libutp -i /usr/include/x86_64-linux-gnu/c++/4.7 -l /home/ubuntu/src/libutp --tor-prefix /home/ubuntu/src/tor --tor-lib utp $ ./setup install $ export PATH=~/.shadow/bin/:$PATH Simulate tiny network in Shadow $ cd resource/examples/scallion/ $ tar xf tiny-4GB-m1.large.tar.xz $ cd tiny-4GB-m1.large/ $ scallion Graph simulation results Add one line to beginning of analyze.py: import matplotlib; matplotlib.use('Agg') For additional traffic simulations: $ grep -v "\[traffic-" scallion.log > scallion-notraffic.log $ cd ~/src/ $ mkdir results $ cd results/ $ python ~/src/shadow/contrib/analyze.py parse --output uTP-1 ~/src/shadow/resource/examples/scallion/tiny-4GB-m1.large/data-utp-1/scallion.log $ python ~/src/shadow/contrib/analyze.py parse --output uTP-0 ~/src/shadow/resource/examples/scallion/tiny-4GB-m1.large/data-utp-0/scallion.log $ python ~/src/shadow/contrib/analyze.py parse --output vanilla ~/src/shadow/resource/examples/scallion/tiny-4GB-m1.large/data-vanilla/scallion.log $ python ~/src/shadow/contrib/analyze.py plot --title "sjm217's utp branch (#9166)" --prefix "sjm217-utp" --data vanilla/ "vanilla 0.2.4.4-alpha" --data uTP-1/ "uTP for all links" --data uTP-0/ "uTP for none of the links" === END OF INSTRUCTIONS ===

1 1

[RELEASE] Torsocks 2.0.0-rc2
by David Goulet 02 Sep '13

02 Sep '13

Greetings everyone! After a week or so, the release candidate 2 is now out after receiving various contributions for BSD and OS X support. A quick note. Please use the Github bug tracker for any issues and *not* trac.torproject.org. Until this code base is accepted as a potential replacement for the old version, please use the current repository issue tracker. Here is the ChangeLog: 2013-09-02 torsocks 2.0.0-rc2 * Fix: remove FAQ file from Makefile * Fix: remove out of date and inaccurate FAQ * Tests: add connection object unit test * Fix: Improve README file * Tests: add onion pool subsystem unit test * Use extern for tsocks_libc_* in torsocks.h * Define LIBC_SYSCALL_ for OS X * Make sure __darwin__ is defined * Fix: explicitly ignore fileno return value * Use AC_CHECK_FUNC rather than AC_LINK_IFELSE. * Find out if we really need libdl. * Define LIBC_SYSCALL_ for FreeBSD. * Use SYS_ from <sys/syscall.h>. * Include <sys/socket.h> for AF_INET*. * Use getsockname(2) for finding out socket address family Please continue to test, review and contribute it! :) Tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc2.tar.gz Big thanks to all contributors for that release! Cheers! David

1 0

Searchable metrics archive - Onionoo-like API available online for probing
by Kostas Jakeliunas 02 Sep '13

02 Sep '13

Hello, this accompanies my status report [1], and includes info how to query the searchable metrics archive for anyone curious. I also refer to the original (now semi-outdated) project proposal/document. [0] Only sending to tor-dev@for now. The Onionoo-like backend is listening on http://ts.mkj.lt:5555/ (backup URI where it's actually running (domain unrelated): ravinesmp.com:5555) This document details how it can be queried: https://github.com/wfn/torsearch/blob/master/docs/onionoo_api.md (It is, by design, an almost-subset (it does change some things as of now, though) of the Onionoo API [2].) Try not to DoS the thing, it is still fragile! :) (or, maybe do, but gently?) I will try to follow-up with a more detailed email, but this will have to do for now. Anyone curious should refer to the API doc. I'll soon add date range parameters, so it will become somewhat more useful. Examples: http://ts.mkj.lt:5555/details?search=mor http://ts.mkj.lt:5555/details?search=79. http://ts.mkj.lt:5555/statuses?lookup=9695DFC35FFEB861329B9F1AB04C46397020C… Please report any inconsistencies / errors / time-outs / anything that takes a few seconds or more to execute. I'm logging the queries (together with IP addresses for now - for shame!), so will be able to later correlate activity with database load, which will hopefully provide some realistic semi-benchmark-like data. [0]: http://kostas.mkj.lt/gsoc2013/gsoc2013.html [1]: https://lists.torproject.org/pipermail/tor-dev/2013-August/005310.html [2]: https://onionoo.torproject.org/ -- Kostas. 0x0e5dce45 @ pgp.mit.edu

2 3

Re: [tor-dev] Pluggable Transport Browser Bundle FTE Integration
by David Fifield 02 Sep '13

02 Sep '13

On Sat, Aug 31, 2013 at 09:43:21PM -0400, Kevin P Dyer wrote: > === Building/Testing Tor on Linux/OSX/Windows > I'm trying to understand exactly how the current build/release process works > for tor. In regards to the PT TBB it seems like there are a few resources > [1,2,3]. However, is there a canonical documentation on how the release process > works? I'm especially interested in what you guys are doing to produce builds > on Windows. Are you using virtualization or do you have a few physical build > machines? > [1] https://gitweb.torproject.org/pluggable-transports/bundle.git > [2] https://lists.torproject.org/pipermail/tor-dev/2013-June/005056.html > [3] https://gitweb.torproject.org/builders/tor-browser-bundle.git There is fragmented documentation on how releases work. I have been building the PT bundles, but I have nothing to do with the building of the vanilla bundles from which the PT bundles are derived. The PT bundles are built by unzipping the vanilla bundles, copying some programs inside and modifying the torrc, and zipping the bundles back up. The PT build is mostly driven by this makefile: https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/Ma… You should know that there are two varieties of the vanilla Tor Browser Bundle: the beta 2.0 series (e.g. https://blog.torproject.org/blog/new-tor-02416-rc-packages-and-updated-stab…) and the alpha 3.0 series (e.g. https://blog.torproject.org/blog/tor-browser-bundle-30alpha3-released). They differ much in their build process. We are using the 2.0 series to build the PT bundles, and there is no 3.0 version of the PT bundles. I would like to have the PT bundles built using the same deterministic process as is used for the 3.0 bundles (e.g. https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and…). See https://trac.torproject.org/projects/tor/ticket/9444 for the status of this project. Some further reading: https://trac.torproject.org/projects/tor/ticket/8019#comment:3 Much of the PT bundle build process is automated, but it still takes me two or three hours to boot VMs, download everything, verify signatures, build, sign, upload, and announce. I use VMs for the GNU/Linux and Windows builds. I use a physical Mac mini running OS X 10.8 for the Mac builds. (This is one reason I want to move the PT bundles to the 3.0 series--they cross-compile for all platforms and don't require a Windows VM or physical Mac.) The instructions for setting up the VMs and Mac are here: https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/bu… https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/bu… https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/bu… > Prior to doing anything with FTE. I'd love to be able to create my own build > environment that produces that current obfs2+obfs3+flash_proxy bundles [6] > across all 4 OS/architecture configurations. > [6] https://www.torproject.org/docs/pluggable-transports.html.en Start with bundle-gnulinux.txt, as that's probably the easiest one. George told me that you have to use whatever the current Debian version number is rather than 7.0.0. It would help if you cna keep track of what parts of the instructions didn't work for you. David Fifield

1 0

Fraudulent PGP key with my email address (CEE1590D)
by Erinn Clark 02 Sep '13

02 Sep '13

Hello everyone, I discovered that there is a key out there (CEE1590D) associated with my Tor email address that is NOT me. I don't know who generated it, but I can think of many nefarious or incompetent reasons why they might have done it. This email is for two purposes: 1. To inform you that this is NOT MY KEY. Do not under any circumstances trust anything that may have ever been signed or encrypted with this key. I looked around and was unable to find anything, but nonetheless, it is out there and that is creepy. 2. If anyone on any of these lists has encountered this key anywhere -- the main fear being that it has been used to fraudulently sign packages of some kind -- can you please let me/us know ASAP? Tor Project official signatures are listed here: https://www.torproject.org/docs/signing-keys.html.en Consider that the canonical source for all signatures! Be suspicious of anything not listed there and let us know if you ever find anything. Thanks, The Real Erinn

2 1

Re: [tor-dev] Pluggable Transport Browser Bundle FTE Integration
by Kevin P Dyer 01 Sep '13

01 Sep '13

[Taking this discussion to tor-dev.] On Sun, Sep 1, 2013 at 6:32 AM, George Kadianakis <desnacked(a)riseup.net>wrote: > Kevin P Dyer <kpdyer(a)gmail.com> writes: > > > Hi George/David, > > > > Hi Kevin, > > > I spoke with Roger at USENIX. He said you're the pluggable transport (PT) > > gatekeepers. Please bear with me while I get up to speed. > > > > My goals: > > 1. I want Format-Transforming Encryption (FTE) [4] to be a "deployed" PT > in > > the PT TBB. > > 2. I want FTE to be integrated seamlessly with your existing deployment > > process. > > > > My initial roadblocks: > > > > === Building/Testing Tor on Linux/OSX/Windows > > I'm trying to understand exactly how the current build/release process > > works for tor. In regards to the PT TBB it seems like there are a few > > resources [1,2,3]. However, is there a canonical documentation on how the > > release process works? I'm especially interested in what you guys are > doing > > to produce builds on Windows. Are you using virtualization or do you > have a > > few physical build machines? > > > > Prior to doing anything with FTE. I'd love to be able to create my own > > build environment that produces that current obfs2+obfs3+flash_proxy > > bundles [6] across all 4 OS/architecture configurations. > > > > Building PTTBBs is mainly done by David these days. He has documented > his process here: > https://gitweb.torproject.org/pluggable-transports/bundle.git > (For example for Windows you would look here: > > https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/bu… > ) > > The release process is not standarized. David is doing PTTBB releases > in a best-effort manner. > Right. On first glance, looks like this process will increase in complexity (and utilize more of David's time) as the number of PTs increases. I need to better understand the build process, then. > > === Implementing Managed Mode in FTE > > I've implemented preliminary functionality for "managed" mode in FTE. > > However, I think I'm confused about the role of managed mode. > > > > Say I add "Bridge fte IP:port" to torrc. Is "IP:port" supposed to be a > tor > > bridge, or a server-side PT service? If it's the former, then it seems > that > > the PT is completely responsible for managing a list of its own PT > servers. > > If it is the latter, I can't figure out how to dynamically determine, via > > the "managed" environmental variables, how to capture user-entered > > "IP:port" information in Vidalia. > > > > It is the latter. <IP:port> points to the server-side PT service. It > does *not* point to the ORPort of the bridge (we don't care about it). > > > Concretely, if I have "Bridge fte IP1:port" and ""Bridge fte IP2:port" in > > my torrc, how does "IP1:port" and "IP2:port" get propagated to my PT via > > the managed interface? > > > > The <IP:port> is *not* passed to your transport using the managed > mode. Instead, <IP:port> is passed to your transport using the SOCKS > protocol. That is, when Tor wants to connect to the bridge, it does a > SOCKS handshake to your transport, and asks your transport to connect > to <IP:port>. Is this documented anywhere? > > === How do we invoke PTs? > > I had this discussion with Roger, but I don't see any open tickets or > clear > > discussion on this already. If we have N>1 PTs and at least one bridge > per > > PT, how do we select which PT (and which bridge associated with that PT) > to > > use? Determinism is bad because then only one PT is used. Booting up all > > PTs is bad, especially if (say) the PTs make network connections prior to > > any incoming SOCKS connections. Selecting a random PT is potentially bad, > > too, depending upon how hostile and persistent and stateful the adversary > > is. > > > > That's an interesting question. I'm not sure if the process of Tor > picking bridges is deterministic or not. I should test it out. David > might know. > > (A good scenario would be that Tor treats bridges like guards and > selects some at random to build circuits.) We should definitely try to flesh this out. > > We should probably chat about this. (Maybe you already have and I'm out > of > > the loop?) It is especially important as the number of PTs increases. > > > > I'm happy to take this discussion (or a subset of it) public, if you > think > > it'll help others. I just didn't want to spam tor-dev/tor-assistants with > > this initial email. > > > > Yes, let's take it public. > Feel free to CC tor-dev in your next reply. > Done. > BTW, on the topic of deploying your PT, have you seen: > https://lists.torproject.org/pipermail/tor-dev/2013-August/005231.html ? > > FTE seems to be missing out on the code quality front. > The Python code is quite complex and undocumented. There is also some > C++ code in the codebase that is also complex and undocumented. We > have decided that we won't ship C/C++ code in PTs, except if it's dead > easy to review or if it has gotten heavily scrutinized. Any chance > that the C++ code could be written in a memory-safe language? Roughly, FTE has an offline mode (building DFAs, needs to be done once) and an online mode (transporting data, deployed to everyone.) In terms of C++ code, there are ~300 line of C++ code used in online mode that were implemented for performance-critical algorithms. Implementing this code in Python will slow FTE down by at least an order of magnitude. I'll document why I made this decision. Alternatively, any suggestions for a memory-safe language that allows hooks for Python and affords the same performance as C++? In terms of reducing complexity of the Python code, and increasing code documentation, do you have concrete suggestions? It would be great if you could raise a few issues on FTE's github [7]. My time is limited and I would prefer to focus on the things you care about. Thanks, Kevin > [1] https://gitweb.torproject.org/pluggable-transports/bundle.git > > [2] https://lists.torproject.org/pipermail/tor-dev/2013-June/005056.html > > [3] https://gitweb.torproject.org/builders/tor-browser-bundle.git > > [4] https://kpdyer.com/fte/ > > [5] > > > https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/180-pluggabl… > > [6] https://www.torproject.org/docs/pluggable-transports.html.en > [7] https://github.com/redjack/FTE

1 0

Trac upgraded to 0.12.3
by Erinn Clark 01 Sep '13

01 Sep '13

Hello everyone! Weasel and I have upgraded https://trac.torproject.org to a newer version. Right now it has all of the functionality you were already accustomed to, but in the next few days it will get some more exciting features, like git integration. (I already verified that we are able to do it with our current git setup, but I will need to go through and poke at individual repos to make sure it works correctly.) Right now I'm just starting with a small list: arm, tor-browser-bundle, obfsproxy, stem, tor, torbrowser, and torbutton. (I tried bridgedb but trac freaks out because it doesn't like something about that repo; I will try to figure out what's wrong after I finish these others). If you want git integration for your repo(s), please file a ticket against the Trac component and I'll see what I can do! Once the git integration works, we'll demo a code review tool (http://trac-hacks.org/wiki/CodeReviewerPlugin). I'll email again once we're further along with both of these processes. In the meanwhile, let me know if you run into any issues with the new trac. Also, I would be remiss if I did not mention Mike's new favorite feature: a tag cloud. https://trac.torproject.org/projects/tor/tags Thanks, Erinn (& weasel)

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev September 2013