- tor-dev - lists.torproject.org

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

23 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 22 Jul '15

22 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

Proposal 248: Remove all RSA identity keys
by Nick Mathewson 22 Jul '15

22 Jul '15

Filename: 248-removing-rsa-identities.txt Title: Remove all RSA identity keys Authors: Nick Mathewson Created: 15 August 2015 Status: Draft 1. Summary With 0.2.7.2-alpha, all relays will have Ed25519 identity keys. Old identity keys are 1024-bit RSA, which should not really be considered adequate. In proposal 220, we describe a migration path to start using Ed25519 keys. This proposal describes an additional migration path, for finally removing our old Ed25519 keys. See also proposal 245, which describes a migration path away from the old TAP RSA1024-based circuit extension protocol. 1.1. Steps of migration Phase 1. Prepare for routers that do not advertise their RSA identities, by teaching clients and relays and other dependent software how to handle them. Reject such routers at the authority level. Phase 2. Once all supported routers and clients are updated to phase 1, we can accept routers at the authority level which lack RSA keys. Phase 3. Once all authorities accept routers without RSA keys, we can finally remove RSA keys from relays. 2. Accepting descriptors without RSA identities We make the following changes to the descriptor format: If an ed25519 key and signature are present, then these elements may be omitted: "fignerprint", "signing-key", "router-signature". They must either be all present or all absent. If they are all absent, then the router has no RSA identity key. Authorities MUST NOT accept routers descriptors of this form in phase 1. 3. Accepting handshakes without RSA identities When performing a new version of our link handshake, only the Ed25519 key and certificates and authentication need to be performed. If the link handshake is performed this way, it is accepted as authenticating the route with an ed25519 key but no RSA key. A circuit extension EXTEND2 cell may contain an Ed25519 identity but not an RSA identity. In this case, the relay should connect the circuit to any connection with the correct ed25519 identity, regardless of RSA identity. If an EXTEND2 cell contains an RSA identity fingerprint, however, its the relay receiving it should not connect to any relay that has a different RSA identity or that has no identity, even if the Ed25519 identity does match. 4. UI updates In phase 1 we can update our UIs to refer to all relays that have Ed25519 keys by their Ed25519 keys. We can update our configuration and control port interfaces so that they accept Ed keys as well as RSA keys. During phase 1, we should warn about identifying any dual-identity relays by their Ed identity alone. For backward compatibility, we should consider a default that refers to referring to Ed25519 relays by the first 160 bits of their key. This would allow many controller-based tools to work transparently with the new key types. 5. Changes to external tools This is the big one. We need a relatively comprehensive list of tools we can break with the above changes. Anything that refers to relays by SHA1(RSA1024_id) will need to be able to remember and use an Ed25519 key instead. 5. Testing Before going forward with phase 2 and phase 3, we need to verify that we did phase 1 correctly. To do so, we should create a small temporary testing network, and verify that it works correctly as we make the phase 2 and phase 3 changes.

6 6

BOINC-based Tor wrapper
by Serg 21 Jul '15

21 Jul '15

Greetings to all developers! What do you think? BOINC - The Berkeley Open Infrastructure for Network Computing. https://boinc.berkeley.edu/ Technical wiki: https://boinc.berkeley.edu/trac/wiki/ProjectMain BOINC -> VirtualBox -> operating system with running Tor relay. Real working solutions? Yes: http://atlasathome.cern.ch/ http://lhcathome2.cern.ch/vLHCathome/ Platform diversity in Tor network may be solved by preparing images with different operating systems. The power of the Tor network may grow very quickly. Fastes reaction to Security vulnerabilities. All client will upgrade Tor images by administrator command. (all images should be signed ofcourse. It is the BOINC principle). You are doing a great job. Thank you! -- Best regards, Sergey

4 6

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

21 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [I hope this message is not considered noise by people on this list, but we haven't yet decided where these announcements should be sent. Until we have, I'm planning to send these messages to this list and tag them with [Measurement Team], so that people can filter these messages if they absolutely don't care. Thanks for understanding.] Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team tomorrow on Wednesday, July 22, 2015, 14:00 UTC in #tor-project http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150722T14 Two weeks ago we started with introductions, and last week we created a list of measurement-related products and started writing fact sheets for some of them. Logs 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… This week I suggest the following agenda: - Introductions, 5 min (only if someone didn't introduce themselves yet) - Problems, 5-10 min: did anything else come up since last week - Products, 5 min: what are we doing with fact sheets - Priorities, 30 min: should we focus more on a certain aspect of measurements in the Tor network, while temporarily suspending or even permanently dropping other aspects? - Misc, 5 min: anything else you come up with Regarding the Priorities item, I'd want us to do another collaborative round involving a pad where we temporarily assume that no single Tor measurement-related tool exists or ever existed and where we brainstorm what tools we should build to measure (passively collect, actively probe, sanitize, archive, pre-process, feed back, aggregate, visualize) things in the Tor network. Maybe we can conclude that brainstorming session by deriving some suggestions for prioritizing our work, given the fact that some of the tools already exist. Hope that sounds interesting to you, but please remember that this discussion will happen tomorrow, not on this mailing list. If you want to participate, 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 iQEcBAEBAgAGBQJVrjlvAAoJEJD5dJfVqbCrJp4IAMiq9Wp4N+ZEjaMdnXPPkMJS 5ItvmsxPxPZkhckrJafZtayE+3x+xfIZG44shgps53DKACxrtDxGdVruZRuA8o3f FGGLZ/YXQj7JJBiVGDn/vIXCfC4fuZSU5K4QYZeG9nDdspKl6HiB/xyavcF76mZw bQNyLU1870On1iQc7Ka9lP8+wO5WyfkJl0jspEs2GrRNMxK68hHakG8rFMVuE9z8 BQnqV113TQtSGJcpoWkfMeNQo0vf/BgbWVgE5/FA9x27WqQtS06oRfwxVMhgGYoW KNWVHyw0R7AG/1WEG/DTR8B/2M7iYVUmr4BrIjaaBo7GLYhySvo/z90fSiFz4Jg= =x3uM -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] [tor-commits] [tor/master] Remove the HidServDirV2 and VoteOnHidServDirectoriesV2 options
by Roger Dingledine 21 Jul '15

21 Jul '15

Isis: I'd like to highlight this change for you, since it means that the bridge authority's networkstatus files are now going to have HSDir flags on the bridge status lines. I don't know if this is going to be a problem for any of your parsing code in any way (hopefully not), but I figured now's a great time to let you know it's coming. --Roger On Thu, Jul 16, 2015 at 07:47:05PM +0000, nickm(a)torproject.org wrote: > --- a/src/or/networkstatus.c > +++ b/src/or/networkstatus.c > @@ -1678,7 +1678,7 @@ networkstatus_getinfo_by_purpose(const char *purpose_string, time_t now) > if (bridge_auth && ri->purpose == ROUTER_PURPOSE_BRIDGE) > dirserv_set_router_is_running(ri, now); > /* then generate and write out status lines for each of them */ > - set_routerstatus_from_routerinfo(&rs, node, ri, now, 0, 0); > + set_routerstatus_from_routerinfo(&rs, node, ri, now, 0); > smartlist_add(statuses, networkstatus_getinfo_helper_single(&rs)); > } SMARTLIST_FOREACH_END(ri);

2 2

Per-transport bridge bandwidth and bridge counts
by David Fifield 21 Jul '15

21 Jul '15

I made some graphs that show the count and total bandwidth of all bridges, broken down by transport. https://people.torproject.org/~dcf/graphs/pt-bandwidth-2015-07-11/pt-bandwi… https://people.torproject.org/~dcf/graphs/pt-bandwidth-2015-07-11/pt-count.… The top part of the graph is non-default bridges, and the bottom is default bridges (the ones that ship with Tor Browser). Note the varying vertical scales. Source code and data are here: https://people.torproject.org/~dcf/graphs/pt-bandwidth-2015-07-11.tar.gz https://people.torproject.org/~dcf/graphs/pt-bandwidth-2015-07-11/pt-bandwi… I have a question about getting bandwidth numbers. What I want is something like available bandwidth capacity; i.e., how much headroom transports have given their level of use. I think that the bandwidth numbers I'm using are partially conflated with usage. Notice how parts of pt-count.png are flat while pt-bandwidth.png has a weekly pattern. The bandwidth number I'm using is the "w Bandwidth=" line from a bridge-network-status document. It looks like this: r starman qgM+62FgGytzEtibYqqiPcPtijQ mdOOBxVOTpw8loBezhSDZxLIcXs 2015-07-03 21:39:31 10.174.163.60 9002 0 s Fast Guard Running Stable Valid w Bandwidth=2646 p reject 1-65535 dir-spec.txt says: An estimate of the bandwidth of this relay, in an arbitrary unit (currently kilobytes per second). Used to weight router selection. See section 3.4.2 for details on how the value of Bandwidth is determined in a consensus." Section 3.4.2 says: When we speak of a router's bandwidth in this section, we mean either its measured bandwidth, or its advertised bandwidth.... The bandwidth in a "w" line should be taken as the best estimate of the router's actual capacity that the authority has. For now, this should be the lesser of the observed bandwidth and bandwidth rate limit from the server descriptor. It is given in kilobytes per second, and capped at some arbitrary value (currently 10 MB/s). I don't know where observed bandwidth comes from. Is there some kind of external test that measures it, or does it come from measuring user traffic? Another option for getting bandwidth is the "bandwidth" line in a bridge-server-descriptor document. It looks like this: bandwidth 1073741824 1073741824 2646895 The three fields are bandwidth-avg bandwidth-burst bandwidth-observed. dir-spec.txt says: Estimated bandwidth for this router, in bytes per second. The "average" bandwidth is the volume per second that the OR is willing to sustain over long periods; the "burst" bandwidth is the volume that the OR is willing to sustain in very short intervals. The "observed" value is an estimate of the capacity this relay can handle. The relay remembers the max bandwidth sustained output over any ten second period in the past day, and another sustained input. The "observed" value is the lesser of these two numbers. So it seems that bandwidth-observed is not what we want, because it's derived from current usage. bandwidth-avg and bandwidth-burst aren't useful because they are operator-controlled and often left at the default of 1 GB/s. Yet another option is the speed of serving consensuses, the "dirreq-v3-tunneled-dl" line in a bridge-extra-info document: dirreq-v3-tunneled-dl complete=13624,timeout=1456,running=4,min=1938,d1=21008,d2=43181,q1=53397,d3=63519,d4=88911,md=117048,d6=146982,d7=180109,q3=199979,d8=223313,d9=298860,max=1558627 You can take the "md=" field, for example, to get median B/s for serving consensuses.

3 3

Commit broken code to otherwsie working master
by l.m 20 Jul '15

20 Jul '15

Hi, Is it normal for a core developer to want to commit broken code to master? I mean if the code is known to be completely broken. Wouldn't it be better to fix the code that is broken before commit. I mean master is a basis for working code isn't it? --leeroy

2 1

4th status report for OnioNS
by Jesse V 19 Jul '15

19 Jul '15

Hello again everyone, This report covers the period of time that I spent in Washington, DC at the hidden service meetings. I made excellent progress on this project. On the 10th, for example, I pushed nearly 30 commits. I fixed many significant bugs and improved many areas that would make the software easier to understand and to configure. * Created a separate and fully-fledged manpage for the hidden service, server, and client aspects of the software. * Client-side and HS-side are now complete and working reliably. The hidden service can generate a Record (a claim on a domain name) and transmit it over a Tor circuit to a remote server. The client now has a binary that launches the Tor executable, the onions-client binary, and a Stem script when the Tor Browser opens, and can now shut them all down properly now. * Fixed a show-stopping bug that prevented the Stem script from launching automatically with the Tor Browser. (George, this bug was why I had to launch Stem manually when I showed the software to you.) The error thrown for this bug was large and unhelpful, but the fix was amusingly simple: https://github.com/Jesse-V/OnioNS-client/commit/9e80691b02e2a843b26ac21b6b0… * Many bug fixes and enhancement updates, including some points of confusion. * Improved flexibility for hosting a server, including the capability to bind to a custom TCP port. * Finalized event logging and a flag to specify where the log goes. Logs on the client-side now go in an OnioNS folder inside the Tor Browser directory. * Migrated flag-parsing from the tclap library I found long ago on SourceForge to Unix popt. * Added a system installation of Tor as a dependency for the hidden service code. * Minor code cleanup. Global sources of randomness were also discussed at the hidden service meetings. I need a source of timestamped archivable randomness that the whole network agrees on in order to securely build OnioNS into a distributed system. The global randomness also has implications for the next generation of hidden service protocols, so there was an overall need to get something together. We made good progress towards this goal. I was able to show Roger and George a demonstration of OnioNS. I registered example.tor and arma.example.tor, pointed example.tor at a HS that I was hosting on my laptop and arma.example.tor at Roger's hidden service (duskgytldkxiuqc6.onion) and uploaded the Record over a Tor circuit to a remote machine, Server A. I then manually transfered the JSON-encoded data structures from Server A to Server B, another machine. Then I launched the Tor Browser (with my binary substitution in place) so that all of the client-side programs were running. I entered "example.tor" into the Tor Browser and as expected arrived at my hidden service, and then typed arma.example.tor into the browser and as expected loaded duskgytldkxiuqc6.onion. This was a great test. The server-to-server communication needs a few bug fixes, but most of that code is in place. As soon as that is complete, I should be about ready for a beta test. Jesse V.

2 1