- tor-dev - lists.torproject.org

The Shadow Simulator will soon use cooperative threading to better support plug-ins
by Rob Jansen 01 Aug '15

01 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Shadow! Hello Tor! For the last couple of weeks, I have been overhauling the way Shadow interacts with plug-ins, and I want to make sure you (and others developing/using Shadow plug-ins) are aware of the upcoming changes. I am enhancing Shadow to support the following two capabilities: 1. Run plug-ins that make blocking system calls 2. Run plug-ins that create and use pthreads To achieve this, I am using a user-space cooperative threading library called pth: http://www.gnu.org/software/pth/ Pth works by storing and swapping stack states using makecontext and swapcontext (see man pages), so that we can intelligently switch back to Shadow's execution stack when the plug-in makes blocking libc function calls, and switch back to the plug-in stack only when its file descriptors are waiting for I/O or timers have expired. This same technique allows us to support would-be plug-in pthreads as application layer pth threads instead, which will help us avoid expensive kernel context switches. This will be especially useful/efficient when running thousands of nodes simultaneously, which normally would consume thousands of pthreads which are not Shadow aware. I have modified the pth library to be reentrant and thread-safe using caller-supplied states and thread-specific data, which I needed because Shadow itself runs with multiple simulator worker threads. Cool, huh!? So what does this mean? With this fancy new approach, we must still build each plug-in using LLVM/Clang in order to make use of Shadow's cool state-swapping trick, but we may no longer need to do other customization, particularly those historically needed for programs that block or use threads. Also, with these changes, Shadow's "API" has been removed, and Shadow now just calls the "main" function symbol in each plug-in directly, and the plug-in need not know anything about Shadow. I'm excited about these changes, and hope they will improve support for new plug-ins while also reducing maintenance in the long term. So far I have Shadow's built-in traffic generator running correctly with the new approach, and am now working on Tor. None of this code is public yet, but if you are interested in an example of how this would work or want some early access to the code, drop me a message off-list. Cheers! Rob - -- Rob Jansen, Ph.D. Computer Scientist Center for High Assurance Computer Systems U.S. Naval Research Laboratory rob.g.jansen(a)nrl.navy.mil robgjansen.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVu4lYAAoJEO3Z5w0UVGXoASAP/3qjW0551xxnrLwWQcrXhbiN cf7hryzU7vDzKRkdzzNbEive0JFZhDONbruJ5Lcx1BW4/uvFZ1emW0FuZFri1m7b xWW6Pp43cMDGeIaMzmWZ9UAea59wirFk/C47R/jDBkXWnZpz5Arc1DjryPbj2LqN oPcfd9JDyE9zk2Y0sSytYt3IulKA62ZOV7+WbIwhHUTj70OgXFvVLhLMMVgOBEDO rHWxDg/+5mC8WqEg4L7lS8/ivAjr1YboA4PV0uSPzgZ+208iQBbsF3DoCG/8D9kY 83xpX/+3aGdWl7XjrncpA5x7gt392fX/3EL9k8lUYu2PKPaOWmJ0/xWbGoXGJOhA epAWPr95X7DFzpcsS59sq6usDeiltFllzfxgA5TbDsUgVwOa9227ygYtK/MVifi6 gYkpZzC6YEMDR6id0ZOwwqYKTsx1Sxomyz30w5iAp1l+Grb10bhUZlfqsNx9PkuI HdBMfvNziApSOQBge36QwskGFlJobfGdpL5w0yep1MSmBJCLVSCopCllLVcbDzQX ipbjmHjJXHNaIL7DHm073VJe2XAjcoMPHHs/nhq0vTgrMFGMDsNvMJ7+66xz3iwZ V3WUjEP0fPjgGZ8MTWj2HjGOQyENa5yAmAiBJUosg1fzgeinushWfE+Zm4m0sVEJ BJttAL/8SnI4DpbIqq6e =c1wf -----END PGP SIGNATURE-----

1 0

Unreachable hidden service by some clients
by Liste 31 Jul '15

31 Jul '15

I was open some hidden service to do an experiment: All work fine. After a day all hidden service on a single server are unreachable from another server used as client. After some hous all hidden server become reachable. Some time when the hidden services are unreachable, they return to work when tor restart. What's going on? We are under attack?

2 1

onionoo.tpo stuck at 2015-07-29 07:00
by nusenu 31 Jul '15

31 Jul '15

2 1

Roster introduction
by Virgil Griffith 29 Jul '15

29 Jul '15

Hello everyone. This is my first report on the Roster project and I wanted to give you all an introduction what it is and where it's going. I'm interested in seeing Tor grow. Current work towards this is tor2web and now Roster. Roster is the rebranded continuation of the "Torati" proposal which I first mentioned here: https://lists.torproject.org/pipermail/tor-dev/2014-June/006975.html In short the gist is to: * Socially incentivize operators to run relays. * Make the operator experience more compelling. * Gamify operating a Tor relay. The main difference between Roster and Globe/Atlas is that Roster provides information at the level of *operators*, not individual relays. In Roster information is aggregated and metrics are summed across all relays of a family. The idea is that when you run a relay, you generate nerd points and badges. And then when people Google your name/alias, they will see how many nerd points+badges you have and they will be in awe of your epic geek-street-cred. In addition to improving operator experience, there are proposals for encouraging operators to do things Tor management like them to do such as upgrading to the latest Tor version and/or probably setting up their Families. E.g., a badge for using the latest/recommended Tor software. That's the gist of it. I will be spending most of my time on tor-relays@ and talking with operators there. So if you want to follow day-to-day stuff subscribe there. Main things accomplished so far: * Setup the basic website at: http://www.tor-roster.org/ * I have an assistant whom I've taken under my wing. His name is Sean Saito <saitosean(a)ymail.com>. He's a Computer Science student at Yale-NUS here in Singapore. He wishes to become more involved in The Tor Project and this is his first Tor-related experience. * We also have discussed with the tor-relays@ list candidate badges. Are interested in additional badge proposals. --- https://lists.torproject.org/pipermail/tor-relays/2015-June/007228.html That's it so far. -Virgil

3 5

[Measurement Team] Next IRC meeting happens tomorrow, Jul 29, 14:00 UTC in #tor-project
by Karsten Loesing 29 Jul '15

29 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team tomorrow on Wednesday, July 29, 2015, 14:00 UTC in #tor-project http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150729T14 Two weeks ago we created a list of existing measurement-related products and last week we brainstormed what tools we would want to exist if none of these existed yet. Logs of all past meetings are available here: http://meetbot.debian.net/tor-project/2015/tor-project.2015-07-08-14.06.log… http://meetbot.debian.net/tor-project/2015/tor-project.2015-07-15-14.00.log… http://meetbot.debian.net/tor-project/2015/tor-project.2015-07-22-14.00.log… While I found the last two meetings extremely productive, I want to suggest a slightly looser-defined agenda this week: - Introductions, problems, products, priorities: any feedback, remarks, comments on what we did in the previous three weeks (for example, I'm planning to present a roadmap document based on the two pads we worked on in the past two weeks) - 1-1-1 task exchange: you get 1 minute to describe a task that would take somebody else roughly 1 hour and that they will do for you within 1 week (review a document, write some analysis code, fix a small bug, etc.; better come prepared to get the most out of this; give 1, take 1) - Misc/discussion: whatever comes up during the meeting If you think this can be fun, please join us at the meeting! Talk to you tomorrow! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVt5O9AAoJEJD5dJfVqbCrqVUH/jKEjckSOEY+1hOpz7cyPXFr E6Z7L64gDSUlCJ68YeADA5C8Y1kG6Pzkhb+Z7zGigJp7ZdEWI8xLbhUtXcgE6cQY 9pyqYd+IK/zNrSdUTgHEfpfHF0sAyHCgMcUMuNQ0Vt82IFxyWef30MJm/w6jvis8 v5iFRLbDut1YZ+xXmm/Y6YyyXxCuSPE/rKxQUbIXFAqf3Nz4207tC4VF9h53vKeF aZr5fnZC6j3cdt0QbPi3vBYMsw9oU0Z9HDpleEh639uEM07wq7wamBvvOKJioNtT 0IcwlDoCDx5ldyZsCNE9aOdVzwkzDjYBRytgNJUHzTyh+yjmFzlIR3a5H8KTVrI= =FCO3 -----END PGP SIGNATURE-----

1 0

Tor Browser/Tor Applications Team Meeting temporarily moved to Tuesday 18:00 UTC
by Mike Perry 26 Jul '15

26 Jul '15

The Tor Browser team meeting will be temporarily moved this week to Tuesday (July 28th) at 18:00 UTC, due to scheduling conflicts for Georg and me. Because of an additional conflict with the Tor Patch Workshop, we will likely be using #tor-project on irc.oftc.net instead of #tor-dev, as well. We're also expanding the meeting in general to open it up to anyone who is working on user-facing Tor client applications (such as Tor Birdy, Tor Messenger, Ricochet, GetTor, Satori, etc). If you work on something user-facing and want to discuss UI/UX, censorship circumvention configuration, or any related topics, please join us! The meeting format is described here: https://lists.torproject.org/pipermail/tbb-dev/2014-February/000000.html -- Mike Perry

1 0

Proposal 249: Allow CREATE cells with >505 bytes of handshake data
by Nick Mathewson 24 Jul '15

24 Jul '15

Filename: 249-large-create-cells.txt Title: Allow CREATE cells with >505 bytes of handshake data Authors: Nick Mathewson Created: 23 July 15 Status: Draft 1. Summary There have been multiple proposals over the last year or so for adding post-quantum cryptography to Tor's circuit extension handshakes. (See for example https://eprint.iacr.org/2015/008 or https://eprint.iacr.org/2015/287 .) These proposals share the property that the request and reply for a handshake message do not fit in a single RELAY cell. In this proposal I describe a new CREATE2V cell for handshakes that don't fit in a 505-byte CREATE2 cell's HDATA section, and a means for fragmenting these CREATE2V cells across multiple EXTEND2 cells. I also discuss replies, migration, and DoS-mitigation strategies. 2. CREATE2V and CREATED2V First, we add two variable-width cell types, CREATE2V and CREATED2V. These cell formats are nearly the same as CREATE2 and CREATED2. (Here specified using Trunnel.) struct create2v_cell_body { /* Handshake type */ u16 htype; /* Length of handshake data */ u16 hlen; /* Handshake data */ u8 hdata[hlen]; /* Padding data to be ignored */ u8 ignored[]; }; struct created2v_cell_body { /* Handshake replay length */ u16 hlen; /* Handshake reply data */ u8 hdata[hlen]; /* Padding data to be ignored */ u8 ignored[]; }; The 'ignored' fields, which extend to the end of the variable-length cells, are reserved. Initiators MAY set them to any length, but MUST fill them with zero-valued bytes. Responders MUST ignore them, regardless of what they contain. When a CREATE2V cell is generated in response to a set of EXTEND2 cells, these fields are set by the relay that receives the EXTEND2 cells. (The purpose of the 'ignored' fields here is future-proofing and padding.) 3. Fragmented EXTEND2 cells Without changing the current EXTEND2 cell format, we change its semantics: If the 'HLEN' field in an EXTEND2 cell describes a handshake data section that would be too long to fit in the EXTEND2 cell's payload, the handshake data of the EXTEND2 cell is to be continued in one or more subsequent EXTEND2 cells. These subsequent cells MUST have zero link specifiers, handshake type 0xFFFF, and handshake data length field set to zero. Similarly, if the 'HLEN' field in an EXTENDED2 cell would be too long to fit into the EXTENDED2 cell's payload, the handshake reply data of the EXTENDED2 cell is to be continued in one or more subsequent EXTENDED2 cells. These subsequent cells must have the handshake data length field set to zero. These cells must be sent on the circuit with no intervening cells. If any intervening cells are received, the receiver SHOULD destroy the circuit. 4. Example So for example, if we are a client, and we need to send a 2000-byte handshake to extend a circuit from relay X to relay Y, we might send cells as follows: EXTEND2 { nspec = 2; { node ID for Y, taking 22 bytes. } { node address for Y, taking 8 bytes } htype = {whatever the handshake type is.} hlen = 2000 hdata = { the first 462 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the final 62 bytes of the handshake } } Upon receiving this last cell, the relay X would send a create2v cell to Y, containing the entire handshake. 5. Migration We can and should implement the EXTEND2 fragmentation feature before we implement anything that uses it. If we can get it widely deployed before it's needed, we can use the new handshake types whenever both of the involved relays support this proposal. Clients MUST NOT sent fragmented EXTEND2 cells to relays that don't support them, since this would cause them to close the circuit. Relays MAY send CREATE2V and CREATED2V cells to relays that don't support them, since unrecognized cell types are ignored. 6. Resource management issues This feature requires relays and clients to buffer EXTEND2 cell bodies for incoming cells until the entire CREATE2V/CREATED2V body has arrived. To avoid memory-related denial-of-service attacks, the buffers allocated for this data need to be counted against the total data usage of the circuit. Appendix A. A rejected idea for migration In section 5 above, I gave up on the idea of allowing relay A to extend to relay B with a large CREATE cell when relay A does not support this proposal. There are other ways to do this, but they are impressively kludgey. For example, we could have a fake CREATE cell for new handshake types that always elicits a "yes, keep going!" CREATED cell. Then the client could send the rest of the handshake and receive the rest of the CREATED cell as RELAY cells inside the circuit. This design would add an extra round-trip to circuit extension whenever it was used, however, and would violate a number of Tor's assumptions about circuits (e.g., by having half-created circuits, where authentication hasn't actually been performed). So I'm guessing we shouldn't do that.

1 0

[Patch] or/config.c for MSVC
by Gisle Vanem 24 Jul '15

24 Jul '15

This gcc-centric macro in or/config.c doesn't work well in MSVC v16/18: #define COMPLAIN(args...) \ STMT_BEGIN log_warn(LD_CONFIG, args); STMT_END I suggest it should be patched like this: --- a/config.c 2015-05-06 22:22:09 +0000 +++ b/config.c 2015-05-06 23:15:57 +0000 @@ -2571,8 +2571,8 @@ #define REJECT(arg) \ STMT_BEGIN *msg = tor_strdup(arg); return -1; STMT_END -#define COMPLAIN(args...) \ - STMT_BEGIN log_warn(LD_CONFIG, args); STMT_END +#define COMPLAIN(args, ...) \ + STMT_BEGIN log_warn(LD_CONFIG, args, ## __VA_ARGS__); STMT_END /** Log a warning message iff <b>filepath</b> is not absolute. * Warning message must contain option name <b>option</b> and ------- All recent compilers supports '__VA_ARGS__'? -- --gv

3 5

☎ Second Computer Graphics, Multimedia and Image Processing - 2015 Malaysia
by Conference Alert 23 Jul '15

23 Jul '15

The Second International Conference on Computer Graphics, Multimedia and Image Processing (CGMIP2015) Universitas Siswa Bangsa Internasional Jakarta, Indonesia October 29-31, 2015 http://sdiwc.net/conferences/cgmip2015/ cgmip15(a)sdiwc.net ---------------------------------------------- CALL FOR PAPERS, WORKSHOP and SPECIAL SESSIONS ---------------------------------------------- Research topics not limited to: - 3D imaging - Case studies and emerging technologies - Color and texture - Computational geometry - Computer art and entertainment (including games) - Case studies - Classification and clustering techniques - Compression methods - Computer animation - Curves and meshes - e-Learning applications and computer graphics - Emerging technologies - Emerging display technologies - Face recognition, face detection, and gesture recognition - Fractal geometry and applications - Graphics algorithms and applications - Graph theory in image processing and vision - Human-computer interfaces - Image compression, coding, and encryption - Image feature extraction - Image geometry and multi-view geometry - Immersive virtual reality - Interactive digital media - Simulation and virtual reality - Software tools for virtual reality - Surface modeling - Virtual environments - Virtual laboratories - Virtual reality, visualization, and education - Visualization All registered papers will be included in SDIWC Digital Library, and in the proceedings of the conference. All submitted papers will be reviewed by a minimum of two reviewers. The published proceedings will be indexed in ResearchBib, in addition, they will be reviewed for POSSIBLE inclusion within the INSPEC, EI, DBLP, Microsoft Academic Research, ResearchGate, and Google Scholar Databases. Important Dates =============== Submission Deadline: September 29, 2015 Notification of Acceptance: 2-4 weeks from the submission date Camera Ready Submission: October 19, 2015 Registration Deadline: October 19, 2015 Conference Dates: October 29-31, 2015

1 0

Fwd: [DNSOP] [Gen-art] review: draft-ietf-dnsop-onion-tld-00
by hellekin 23 Jul '15

23 Jul '15

Dear Tor developers, would it be possible to add https://torproject.org/spec page, including anchors for the various specifications: #tor-protocol, #tor-rendezvous, etc. pointing to the repository, to accommodate the General Area Review Team's comments, enable future stable reference to Tor specs, and move on? That would be very, very simple to implement, and very, very useful as a temporary fix since I don't see the Tor project nor the IETF releasing Tor specs RFCs before the CAB forum's deadline is reached within four months. Thank you, == hk -------- Forwarded Message -------- Subject: [DNSOP] [Gen-art] review: draft-ietf-dnsop-onion-tld-00 Date: Sat, 18 Jul 2015 05:25:25 -0400 From: Joel M. Halpern <jmh(a)joelhalpern.com> To: A. Jean Mahoney <mahoney(a)nostrum.com>, General Area Review Team <gen-art(a)ietf.org>, dnsop(a)ietf.org I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dnsop-onion-tld-00 The .onion Special-Use Domain Name Reviewer: Joel Halpern Review Date: 18-July-2015 IETF LC End Date: 11-August-2015 IESG Telechat date: N/A Summary: This document is nearly ready for publication as a Proposed Standard RFC Major issues: It seems to this reviewer that at least the definition of how to use these names, reference tor-rendezvous, needs to be a normative reference. It appears likely that tor-address also ought to be a normative reference. Minor issues: It is not clear that a github reference without version identification is sufficiently stable for a normative reference from an RFC. Nits/editorial comments: _______________________________________________ DNSOP mailing list DNSOP(a)ietf.org https://www.ietf.org/mailman/listinfo/dnsop

3 10