- tor-dev - lists.torproject.org

Cryptocurrency: Total Energy Analysis - Crypto Uses Less Than Fiat
by grarpamp 17 Jun '19

17 Jun '19

(from tor-dev: PoW DoS defenses Prop 305: INTRO Cell) On 6/16/19, Chelsea Holland Komlo <me(a)chelseakomlo.com> wrote: > Given the significant environmental impact of POW in other distributed > systems (blockchain), we should not implement schemes that solve a > problem for Tor but create problems for people elsewhere (potentially > irreversible environmental damage). > > https://www.theguardian.com/technology/2018/nov/05/energy-cost-of-mining-bi… One must first understand and enumerate the *entirety of all global energy inputs* going into and making up the legacy fiat currency banking systems, from both Government and Corporate sectors, and its results, before attempting to make any claims that cryptocurrency is "worse" [1]. Such cataloging and analysis requires more work, more data, more actual redpill thought, than just simple hashrate/J/$... so of course people take shortcuts in such articles, as do other people in their pronouncements stemming from them. > Other less-destructive schemes exist to prevent DoS attacks. POW is a > method, not a goal in itself. Taking a step back and examining the full > spectrum of available tools would be better. The needs and model for overlay nets, ie tor, will of course be different than those above. And always interesting where tech various ends up being applied. [1] Hint: Cryptocurrency actually consumes less, and further finally forces inefficiency and other undesired things out of Fiat by displacing it... hopefully faster than it can adapt. Some say that has a value, one that many will be quite happy to sink a bit of premium into if need be.

2 1

OTRv4 summit at PETS2019
by Sofia Celi 17 Jun '19

17 Jun '19

Hi, Tor people! My name is Sofía and I'm the person leading the OTRv4 initiative. I don't know if this is the best place to send this, so if it is not, let me know ;) As part of the work on creating the version 4 of the OTR (Off-the-Record) messaging protocol, we are running a summit in Stockholm, Sweden, the 15 of July, in the morning. This summit runs in parallel with the Privacy Enhancing Technology Symposium 2019 (PETS2019, https://petsymposium.org/2019/index.php) It will be a summit around the work done in the field of secure messaging, deniability and privacy on July 15 on the morning (that is, the day before the start of PETS 2019). It will be held at the Royal Institute of Technology (KTH). You can find it on the official PETS2019 programm: https://petsymposium.org/2019/program.php and on the official otr website: http://otr.im/ The OTRv4 summit will feature a mix of a discussions, short talks and presentations which aim to highlight the importance of privacy, security and deniability in a secure messaging setting to researchers, students, activists and developers. The final schedule for the event will be announced closer to the event. The workshop will start at 9 am and end at 12.30 pm. As one of our developers and my current partner, Ola Bini, has been detained in Ecuador with no actual evidence, we will also talk about this. You can read about this in the latest EFF statement: https://www.eff.org/deeplinks/2019/06/eff-ohchr-iachr-cybercrime-law-interc… We will like that you join us there... so let us know if you can! Thank you! The OTRv4 team -- Sofía Celi @claucece Cryptographic research and implementation at CAD: https://autonomia.digital/ EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F

2 2

Proposal 304: Extending SOCKS5 Onion Service Error Codes
by David Goulet 06 Jun '19

06 Jun '19

3 2

Dealing with critical sbws tickets
by teor 05 Jun '19

05 Jun '19

Hi juga, I read your meeting notes from this week's network team meeting: juga(offline): Week of 05/20 (planned) - Add Tor version to the bandwidth file (#30196) Week of 05/20 (actual) Week of 06/03 (plan) - Continue with #30406: Refactor header constants in sbws to use Stem's one For the next few weeks, can you focus on fixing critical sbws bugs, and helping with authority deployments? Here's what I think we could do: I would like us to deploy sbws to 3/6 bandwidth authorities some time in June. We can do this deployment as soon as another directory authority operator is ready. To deploy more than 3 sbws instances, we need to fix these critical sbws bugs: We need sbws to generate bandwidth lines for all relays with results, even if they are not Running in the sbws tor client's current consensus. https://trac.torproject.org/projects/tor/ticket/29710#comment:13 We need sbws to use MaxAdvertisedBandwidth from the latest descriptors: https://trac.torproject.org/projects/tor/ticket/30733 We also need to look for any more critical bugs in sbws. Here are some ways we can check for bugs: We need to check if all sbws instances exclude some relays, to help us find any more bugs in sbws: https://trac.torproject.org/projects/tor/ticket/30735 90% of sbws measurement attempts fail. But these are internal errors, not network errors. So it looks like sbws has a relay selection bug: https://trac.torproject.org/projects/tor/ticket/30719#comment:2 After we do these tasks, we can deploy sbws to 4 bandwidth authorities. What do you think? T

2 2

Raising AuthDirMaxServersPerAddr to 4?
by Roger Dingledine 04 Jun '19

04 Jun '19

Hi folks, I've been talking to a longtime exit relay operator, who is in the odd position of having a good 1gbit network connection, but only one IP address. He used to push an average of 500mbit on his exit relay, but then the HSDir DoS flatlined his relay for a while (!), and now, perhaps due to the bwauth variability, his exit relay only recovered to maybe 200mbit. He is running a second exit relay on that IP address, but also perhaps due to the bwauth variability, it hasn't attracted much attention either. The real answer is to fix the bandwidth measurement infrastructure. But while we're patiently waiting for progress there, I've been thinking to raise moria1's AuthDirMaxServersPerAddr to 4, i.e. to allow 4 relays per IP address onto the network. I don't think it would significantly increase our risk due to Sybil attacks, whereas there is a clear benefit in terms of some more 100's of mbits of good exit relay capacity. I will propose this change to the dir-auth list in a bit, but here is your chance to point out surprising impacts that I haven't thought of. Thanks! --Roger

3 14

Release: obfs4proxy-0.0.10
by Yawning Angel 02 Jun '19

02 Jun '19

Hello, I just tagged obfs4proxy-0.0.10. The primary changes are a minor fix to the meek_lite behavior when using `utls` as the TLS implementation, and a series of updates (primarily following upstream) to the `utls` library. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.1… https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.1… Changes in version 0.0.10 - 2019-04-12: - Disable behavior distinctive to crypto/tls when using utls. - Bump the version of the utls fork. Regards, -- Yawning Angel

5 6

Should we allow matrix.org users on tor IRC channels?
by teor 01 Jun '19

01 Jun '19

Hi all, JeremyRand has asked us to allow matrix.org users on the tor IRC channels on irc.oftc.net. matrix.org users are rejected at the moment, because they are not registered with OFTC. For details, see: https://trac.torproject.org/projects/tor/ticket/30717 T -- teor ----------------------------------------------------------------------

1 0

Fwd: Orbot 16.1.0-BETA-1-tor-0.4.0.4-rc
by Nathan Freitas 31 May '19

31 May '19

Tor 0.4.0.4 working well on Android. We've updated the tor-android library to 0.4.0.4-rc, and included it in the latest Orbot beta. It is available via Gradle at the usual spot (see below): https://github.com/guardianproject/tor-android/releases/tag/tor-android-bin… maven { url "https://raw.githubusercontent.com/guardianproject/gpmaven/master" } implementation 'org.torproject:tor-android-binary:0.4.0.4-rc' -------- Forwarded Message -------- Subject: Orbot 16.1.0-BETA-1-tor-0.4.0.4-rc Date: Fri, 31 May 2019 16:25:20 -0400 From: Nathan of Guardian <nathan(a)guardianproject.info> Organisation: Guardian Project To: Guardian Dev <guardian-dev(a)lists.mayfirst.org> /** 16.1.0-BETA-1-tor-0.4.0.4-rc / 31 May 2019 / 417e4fcd0720be57328d63a96d2c9fc0e119330f **/ TAG: https://gitlab.com/guardianproject/orbot/tags/16.1.0-BETA-1-tor-0.4.0.4-rc Thanks to @bitmold @sisbell and @eighthave for all the great work, not to mention the core Tor dev team making all things mobile better every day! APKs posted at: https://guardianproject.info/releases/ [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-arm64-v8a-release.apk 2019-05-31 15:17 12M [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-arm64-v8a-release.apk.asc 2019-05-31 15:17 833 [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-armeabi-release.apk 2019-05-31 15:18 12M [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-armeabi-release.apk.asc 2019-05-31 15:18 833 [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-armeabi-v7a-release.apk 2019-05-31 15:18 12M [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-armeabi-v7a-release.apk.asc 2019-05-31 15:18 833 [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-universal-release.apk 2019-05-31 15:18 32M [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-universal-release.apk.asc 2019-05-31 15:18 833 [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-x86-release.apk 2019-05-31 15:18 12M [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-x86-release.apk.asc 2019-05-31 15:18 833 [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-x86_64-release.apk 2019-05-31 15:18 12M [ ] Orbot-16.1.0-BETA-1-tor-0.4.0.4-rc-fullperm-x86_64-release.apk.asc 417e4fcd update version to 16100003 aka 16.1.0-BETA-1-tor-0.4.0.4-rc 7ae000d0 fix pdnsd/VPN support dde1957d Merge pull request #219 from bitmold/delete_minimalperm_manifest a251d52f Merge pull request #218 from bitmold/ndk_app_platform_warning eda464bb remove incorrect torFile assignment a1c5806a update tor-android to 0.4.0.4-rc ad2e875b We no longer use the minimalperm product flavor so there's no need to keep this manifest file in app/src 917e49f5 Removes warning on ndk-build where the target API for NDK (16) is greater than the sdk version defined for the project. Since nothing was specified in the manifest it defaulted to 1 but we can set this to Orbot's minSdkVersion of 16 to get rid of this warning f83a98f4 Merge branch 'sisbell-issue_199' ff7d3dd5 (sisbell-issue_199) Merge branch 'issue_199' of https://github.com/sisbell/orbot into sisbell-issue_199 7c2cfc3e Merge pull request #212 from sisbell/issue_211 1316fd65 Merge branch 'bitmold-no_personalized_learning_kb' e3fd4afa (bitmold-no_personalized_learning_kb) Merge branch 'no_personalized_learning_kb' of https://github.com/bitmold/orbot into bitmold-no_personalized_learning_kb aa8ad867 Merge pull request #204 from bitmold/unreferenced_classes 16826a49 Merge branch 'bitmold-removed_obsolete_version_checks' 17154609 (bitmold-removed_obsolete_version_checks) Merge branch 'removed_obsolete_version_checks' of https://github.com/bitmold/orbot into bitmold-removed_obsolete_version_checks 0e4b42a7 add close bracket 4cee987c Merge branch 'master' into removed_obsolete_version_checks 08c35bd3 Remove unused resources. ae4ce1c9 Fixes #211: Resource Not Found on Command Line Build 2fb7e05a Merge pull request #210 from eighthave/fastlane 57120100 rename all metadata locale dirs after the Fastlane/Play names baced180 setup Fastlane to upload to Google Play d2feefdd Removed Obsolete @TaretApi Annotations for API Levels that are lower than Orbot's minimum, API Level 16 a32452e7 Make text inputs in Orbot declare that they do want to opt out of IME personalized learning. Of course, IMEs may ignore this request, but it's a nudge in the direction of Tor's general philosophy on user privacy, particularly with regards to minimizing the footprint that a Tor app leaves on the user's device. 7d8e41a6 Removed Constraint Layout Dependency 5d04d418 Removed Unused Classes 2b6abd7e Removed Obsolete Version Checks cd6560fa Merge pull request #202 from bitmold/no_constraint_layout a5d5c99f (public/master, gl/master) remove unused launcher art 9257b66f don't shrink or minify for now 56917567 (tag: 16.0.6-BETA-2-tor-0.3.5.8) many small changes to support new binary loading, startup and more - improved handling of port conflicts - fixed loading of tor binary on arm64-v8a - changed how w e execute shell commands 8ed080f9 Removed Constraint Layout Dependency 2a76b7af (tag: 16.0.6-BETA-1-tor-0.3.5.8) updated to SDK 28, added android.permission.FOREGROUND_SERVICE permission fb14c76c fixed strings with two many \\ escapes 45575772 updating to tor-0.3.5.8-rc to add support for Android Q 22d5ffdf update gradle tools 76796fea Merge pull request #200 from eighthave/fastlane-supply 6ba0cecc add .gitlab-ci.yml setup with errorprone 3face00a build gradle to 4.4.1, and make gradlew verify the download 69bd7fe9 move app store graphics into fdroid/fastlane file layout f93c11e7 Merge pull request #190 from SkewedZeppelin/master 8ab13f63 Fixup bad indentation from 6e4b7008 12b91c44 Expose PreferIPv6 and NoIPv4Traffic options 8ad76680 Move Google repo above jcenter d4befad1 cleanup and binary loading fixes 2d4e2a5f update tor to 0.3.5.6-RC 0f314214 (tag: 16.0.5-RC-2-tor-0.3.4.9) update to 16.0.5-RC-2-tor-0.3.4.9 2c59c848 ensure startForeground() is always immediately called - since we use startForegroundServce() we must ensure the receiving service complies!

1 0

Merger and Mainline Handovers
by teor 30 May '19

30 May '19

Hi Nick, George, David, (I'm sending this email to tor-dev so everyone knows how Core Tor merges are going.) Mainline Mergers David is back from leave, so I'm going to stop doing mainline merges. But please let me know if there's a merge I can help with. (Email or Signal is best, IRC has a lot of backlog.) Do we need to do a handover some time? The next team meeting might be a good time. Mainline Merge Ready Tickets I moved my mainline merge trac wiki queries to this page: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Mainlin… That page should show all of the mainline merge_ready tickets, sorted by owner and reviewer. Your name is in bold, so you can work out which tickets you should merge. (We want 3 people to look at every ticket before it merges, except for trivial changes.) Here is our full list of task tracking wiki pages: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam#TaskTra… When does 0.4.0 stop being mainline? It looks like people aren't merging backports to 0.4.0 any more. That's probably a good idea: we should minimise release candidate changes. When should I start doing 0.4.0 merges as part of the backports? Backport Status We released 0.4.0.4-rc last week, so I'm going to backport some low-risk changes to 0.2.9 and later. Most of these changes have been tested in 0.4.0.3-alpha. I should be able to do the backports tomorrow or Tuesday. Here are the backports for the next few days: https://trac.torproject.org/projects/tor/wiki/user/teor#Backports:0.5dayspe… Here are the backports I will do after I get back from my leave in May: https://trac.torproject.org/projects/tor/wiki/user/teor/HiddenBackports T -- teor ----------------------------------------------------------------------

2 2

Network team: New status page for 0.4.1; help needed on ticket triage
by Nick Mathewson 30 May '19

30 May '19

Hi! This mail is mainly for the network-team folks, but I'm sending it to tor-dev anyway in case it's helpful to anybody else. I've made a new page for our 0.4.1 status, based on Teor's previous 040 status page. Here it is: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… Note that this time I'm using two different keywords: 041-must and 041-should. The difference here is that 041 stuff should be things that would really block a release candidate, whereas 041-should stuff is stuff that we might in theory release without fixing. (It might annoy our users or violate our best practices, so we _should_ try to fix it, at least.) At the bottom of the page are all the tickets in the milestone that are *not* marked 041-must or 041-should. Some of these are things we could still fix anyway in 041; many will be removed. Let's triage these together! As discussed at the last meeting, we are currently in feature freeze for 0.4.1. Other than tickets that are marked "postfreeze-ok", we're planning not to take any more features in Tor 0.4.1. (Network team folks, please remember to spend your time on 041-must and 041-should tickets, and on Sponsor 19 tickets. If we make enough progress on these, we can open up 0.4.2 for merging early.) happy hacking, -- Nick

1 1