- tor-dev - lists.torproject.org

Alternative directory format for v3 client auth
by George Kadianakis 14 Aug '18

14 Aug '18

Hello haxxpop and David, here is a patch with an alternative directory format for v3 client auth crypto key bookkeeping as discussed yesterday on IRC: https://github.com/torproject/torspec/pull/23 Thanks for making me edit the spec because it made me think of various details that had to be thought of. Let me know if you don't like it or if something is wrong. Cheers!

3 8

[release] Onionoo 6.2-1.16.1
by Iain Learmonth 13 Aug '18

13 Aug '18

Hi, A patch release has been made for Onionoo to fix an error in the serialization of history documents. Download available at: https://dist.torproject.org/onionoo/6.2-1.16.1/ Software changes are summarized in the changelog [0]. The changes are already deployed on all onionoo.torproject.org instances. In order to benefit from this fix immediately you may wish to follow the advanced instructions listed below. If you do not do this, then after a week you should find that the problem is resolved, it will just happen more slowly as the documents are rewritten. 1. Checkout commit 18e5c04 in karsten's task-27039 branch https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-27039… 2. Run ant jar to build the jar file at generated/dist/onionoo-6.2-1.16.0-dev.jar. (You will not need the war file built.) 3. Upload this jar file along with the jar and war files for the 6.2-1.16.1 release. 4. Wait for hourly updater to end. 5. Stop hourly updater and the web server. 6. Run java -jar onionoo-6.2-1.16.0-dev.jar --rewrite-only. 7. Remove the intermediate jar file to avoid confusion. 8. Re-start the web server and the hourly updater using the files from the 6.2-1.16.1 release. Please direct comments and questions to the metrics-team mailing list [1]. Thanks, Iain -- on behalf of the Metrics Team. [0] https://gitweb.torproject.org/onionoo.git/plain/CHANGELOG.md?h=onionoo-6.2-… [1] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

[release] Onionoo 7.0 will be released after September 3, 2018
by Karsten Loesing 09 Aug '18

09 Aug '18

Hello tor-dev@, yesterday we announced Onionoo protocol version 6.2 that we released a few days before on August 3, 2018. One month later, after September 3, 2018, we're going to release Onionoo protocol version 7.0 which will make a couple backward-incompatible changes: - extend the "version" parameter to support lists and ranges, - remove redundant "1_week" and "1_month" graphs from clients documents, - change "3_months" graphs to "6_months" graphs in all documents containing history objects, - remove the "fingerprint" parameter, and - remove the previously deprecated "as_number" field from details documents. You can find more details on the Onionoo protocol page: https://metrics.torproject.org/onionoo.html If you're using any of these fields or parameters, be sure to either update your Onionoo client to support the new protocol version, or pester your Onionoo client developer to do that for you. On behalf of the Tor metrics team, Karsten

2 2

Tor Browser for arm64/v8 on RPi3
by procmem 08 Aug '18

08 Aug '18

@intrigeri I'll post there. Thanks for the heads up.

1 0

[release] Onionoo 6.2-1.16.0
by Iain Learmonth 08 Aug '18

08 Aug '18

Hi, Onionoo's protocol was extended and has a minor version jump to 6.2. Download available at: https://dist.torproject.org/onionoo/6.2-1.16.0/ Protocol changes (also summarized in [0]): Added an "as" field to details document, deprecated the "as_number" field, added an "as_name" parameter to search for relays by AS name, and added support for comma-separated lists in the "as" and the "lookup" parameters. Software changes are summarized in the changelog [1]. The changes are already deployed on all onionoo.torproject.org instances. Unfortunately there are two known bugs affecting this release that were not fixed before deployment: Timestamps in graph history documents are incorrectly formatted which is currently breaking graphs in relay search. No data is lost and the graphs will reappear once this is resolved. (See #27039 [2]) Reverse DNS names are still being looked up slowly and so are missing for most relays. (See #27050 [3]) Please direct comments and questions to the metrics-team mailing list [4]. Thanks, Iain -- on behalf of the Metrics Team. [0] https://metrics.torproject.org/onionoo.html#versions_6_1 [1] https://gitweb.torproject.org/onionoo.git/plain/CHANGELOG.md?h=onionoo-6.2-… [2] https://bugs.torproject.org/27039 [3] https://bugs.torproject.org/27050 [4] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Reviewing Trac #18642 (Teach the OOM handler about the DNS cache)
by neel＠neelc.org 06 Aug '18

06 Aug '18

Hi tor-dev@ mailing list, I have a patch for Bug #18642 (Teach the OOM handler about the DNS cache) which I would like reviewed. The URL is here: https://trac.torproject.org/projects/tor/ticket/18642 (https://trac.torproject.org/projects/tor/ticket/18642) Originally, dgoulet chose he would review, but after no response on the patch, he has emailed me that he's on vacation until the 16th of August, hence the reason why I'm emailing here. I am really keen on getting this patch in, and if there's any Tor developer here, could someone please review and merge it? Thank You, Neel Chauhan === https://www.neelc.org/

3 3

Tor Browser for arm64/v8 on RPi3
by procmem 06 Aug '18

06 Aug '18

We at Whonix are currently porting to (non-VM) physical builds on arm64 - specifically RPi3. While this is great for headless applications we are interested in GUI user adoption. Without Tor Browser for arm64 this won't be as safe as it can be. Can you please consider releasing builds for this hardware platform?

2 1

Tor Relay Guide Disagreements
by nusenu 04 Aug '18

04 Aug '18

Hi Vinícius, (moving this discussion to the tor-dev mailing list since this isn't limited to the OpenBSD ticket scope https://trac.torproject.org/projects/tor/ticket/26619#comment:14 ) Vinícius wrote: > you [nusenu] took over /FreeBSD, /BSDUpdates, and /OpenBSD and enabled the 'read- > only' mode all by yourself without even consulting the original author or > anyone else [...] > is there any particular reason why you enabled the read-only mode on > /FreeBSD, /BSDUpdates, and /OpenBSD? I think this a pretty odd behavior. > I'm sorry. if you do want to own all these pages (and many other more), > please tell us. The Tor Relay Guide wiki page [1] has been 'read-only' pretty much since we launched it, it has been decided a few months ago in [0]. Anyway read-only mode shouldn't affect you personally. Since you are listed on the tor people page I assume you can simply ask for the permissions to edit 'read-only' pages. I'd still ask you to open tickets for changes like your change to the FreeBSD page instead of applying them directly so we can discuss them before applying and to avoid the necessary efforts. On 2018-07-10 I split out the OS specific instructions into their subpages: /DebianUbuntu /FreeBSD ... because of this move content that was previously read-only until then became writable but that wasn't an intentional step. On 2018-08-02 you changed the FreeBSD page [4], here are two lines (examples) of your replacements: my text: change the nickname "myNiceRelay" to a name that you like Change the email address bellow and be aware that it will be published got replaced with: CHANGE THE NICKNAME WRITE YOUR EMAIL ADDRESS I'm not sure I would consider these replacements an improvement since they remove information without giving any reasoning for removing it in the comment. Besides the removal of information this also introduces inconsistency in the torrc file we used so far in the guide. I reverted your change and addressed the issue you brought up (net.inet.ip.random_id ordering, /etc/pkg/FreeBSD.conf modification) and made the content read-only again (like it was until 2018-07-10). > ggus is that page's [/OpenBSD] author and he allowed me to edit the contents of that > page (the same is also applied to the /FreeBSD page; There has been no comment by ggus on #26619 (/OpenBSD) for a month so I went ahead and assigned it to me, but I'll pull out of that ticket now. https://trac.torproject.org/projects/tor/ticket/26619 ggus didn't create /FreeBSD [3]. > should we always open tickets with suggestions? - sadly it > also sounds extra odd, because when I did open tickets (#27006 and > #27007), a few minutes later you changed contents all by yourself #27006 is about /DragonFlyBSD I've never touched that page? https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DragonFlyBSD?ac… #27007 was about creating /NetBSD - which you did. I didn't consider my change - where I replaced the ORPort to use 443 (because we used that port everytime that works out of the box on a platform) to be part of the "create the /NetBSD page": https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/NetBSD?action=d… Going forward I'd propose the following to minimize the fraction and overhead: I assume you maintain: /TorRelayGuide-ptbr /TorRelayGuide/OpenBSD /TorRelayGuide/NetBSD /TorRelayGuide/DragonFlyBSD I'll keep maintaining: /TorRelayGuide /TorRelayGuide/DebianUbuntu /TorRelayGuide/CentOSRHEL /TorRelayGuide/Fedora /TorRelayGuide/FreeBSD /TorRelayGuide/openSUSE All pages should be read-only and writable to authorized users/maintainer, but feel free to have the pages you maintain world writable. All non-maintainer changes are expected to go through a ticket. After a timeout of 7 days with no maintainer response the ticket opener might proceed with applying the proposed change. I'll propose a list of requirements for a platform to be listed on the main page. kind regards, nusenu [0] https://trac.torproject.org/projects/tor/ticket/24497 [1] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide [2] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD [3] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD?action=… [4] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD?sfp_ema… -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 2

WTF-PAD and the future
by George Kadianakis 03 Aug '18

03 Aug '18

Hello Mike, I had a talk with Marc and Mohsen today about WTF-PAD. I now understand much more about WTF-PAD and how it works with regards to histograms. I think I might even understand enough to start some sort of conversation about it: Here are some takeaways: 1) Marc and Mohsen think that WTF-PAD might not be the way forward because of its various drawbacks and its complexity. Apparently there are various attacks on WTF-PAD that Roger has discovered (SENDME cells side-channels?) and also the deep learning crowd has done some pretty good damage to the WTF-PAD padding (90%-60% accuracy?). They also told me that achieving needed precision on the timings might be a PITA. 2) From what I understand you are also hoping to use WTF-PAD to protect against circuit fingerprinting and not just website fingerprinting. They told me that while this might be plausible, there is no current research on how well it can achieve that. Are we hoping to do that? And what research remains here? How can I help? Which parts of the Tor circuit protocol are we hoping to hide? 3) Marc and Mohsen suggested using application-layer defences because the application-layer has much better view of the actual structures that are sent on the wire, instead of the black box view that the network layer has. In particular they were mainly concerned about onion services fingerprinting because they are part of a restricted closed world, whereas they were less concerned about the entire internet because of its vast size. They suggested that we could investigate using the service-side "alpaca" library for onion services (e.g. as part of securedrop?) which should resolve the most pressing concern of HS identification. 4) They also told me of research by Tobias Pulls which eliminates the needs for histograms in WTF-PAD and instead it samples from the probability distribution directly. They think that this can simplify things somewhat. Any thoughts on this? Let me know what you think. I still don't understand the entire space completely yet, so please be gentle. ;) Cheers! :)

5 7

Mentorship needed for beginner.
by Yogesh Singh 30 Jul '18

30 Jul '18

Hey, I'm an undergrad with CS majors and have developed interest for networking. I would like to contribute to the Tor projects. It would be of great help if someone could mentor me where to begin with. Regards, Yogesh

2 1