tor-dev

tor-dev@lists.torproject.org

3581 discussions

Proposal 290: Continuously update consensus methods
by Nick Mathewson 03 Mar '18

03 Mar '18

Filename: 290-deprecate-consensus-methods.txt Title: Continuously update consensus methods Author: Nick Mathewson Created: 2018-02-21 Status: Open 1. Background Directory authorities use the "consensus method" mechanism to achieve forward compatibility during voting. When each authority publishes its vote, it includes a list of numbered consensus methods that it supports. Each authority chooses to calculate the consensus according to the highest consensus method it knows supported by more than 2/3 of the voting authorities. So long as all the authorities have a method in common, they will all reach the same consensus. Consensus method 1 was first introduced in the Tor 0.2.0 series around 2008. But by 2012, we realized that we had a problem: we were stuck documenting and supporting old consensus methods indefinitely. With proposal 215, we deprecated and removed support for all consensus methods before method 13. That was good as far as it went, but it didn't solve the problem going forward: the latest consensus methods is now 28. This proposal describes a policy for removing older consensus methods going forward, so we won't have to keep supporting them forever. 2. Proposal I propose that from time to time, old consensus methods should be deprecated. Specifically, I propose that we deprecate all methods older than the highest method supported in first stable release of the oldest LTS (long-term support) release series. For example, the current oldest LTS series is 0.2.5.x. The first stable release in that series was 0.2.5.10. The highest consensus method listed by 0.2.5.10 is 18. Therefore, we should currently consider ourselves free to deprecate all methods before 18. Once 0.2.5.x is deprecated, 0.2.9.x will become the oldest LTS series. The first stable release in that series was 0.2.9.8. The highest consensus method listed by 0.2.9.8 is 25. Therefore, once 0.2.5.x is deprecated (in May 2018), we may deprecate all methods before 25. When a consensus method is deprecated, it should no longer be listed or implemented by the latest Tor releases. (It's okay for older authorities to keep advertising it.) Most consensus methods add a feature that is used in "method M or later". Deprecating method M-1 means that the feature is used in all supported consensus methods. Therefore, we can remove any code that makes the feature conditional on a consensus method, and any code for previous implementations of the feature. Some consensus methods remove a feature that was used up to method N. Deprecating method M means that the feature is no longer used by any supported consensus methods. Therefore, we can remove any code that implements the feature. A. Acknowledgments Thanks to isis and teor for the discussion that led to this proposal. I believe that teor first suggested the policy described in section 2 above. B. Client and relay compatibility notes Dear reader: you may be worrying that this proposal will cause old clients or relays to stop working prematurely. That is not the case. Consensus methods determine how the authorities behave, but they do not represent backward-incompatible changes in how they generate their consensuses.

3 2

New link on Tor Metrics: download data as CSV
by Karsten Loesing 28 Feb '18

28 Feb '18

Hi tor-dev! Today we added a small, but potentially quite useful feature to Tor Metrics. The data that is displayed in a graph can now be downloaded as CSV file by clicking on "download data as CSV". This is different from before, where we provided the larger CSV file that a graph is based on. Getting the relevant data out of that would still require some data wrangling. This has become a lot easier now. Want to try it out? Go to any graph on Tor Metrics, for example: https://metrics.torproject.org/relays-ipv6.html?start=2013-02-28&end=2018-0… Click on "download data as CSV" and you'll get just the values that are plotted in the graph. Want to learn more and maybe help us make this feature more useful? There's more about it in tickets #25282 (closed), #25383, and #25387. All the best, Karsten

1 0

DocTor Check for <3 bw auth votes available
by nusenu 28 Feb '18

28 Feb '18

Hi Damian, would be great to have a check in DocTor that sends out an email for "there are less than 3 bw auth voting auths available" thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

3 6

[release] CollecTor 1.5.0, metrics-lib 2.2.0
by iwakeh 26 Feb '18

26 Feb '18

Hi there! two new releases are available: https://dist.torproject.org/collector/1.5.0/ https://dist.torproject.org/metrics-lib/2.2.0/ These releases will be deployed on tp.o instances after several weeks of testing, and provide Tor's web server access logs that are currently available on [0] through CollecTor. All possibly privacy impacting data is removed from the logs prior publishing. What exactly is done to ensure privacy can be found in the specification doc [1]. The additions to metrics-lib's API can be read in its Javadoc pages [2]. Other details can be found in the respective change logs [3] and [4]. Please direct comments and questions to the metrics-team mailing list [5]. Cheers, iwakeh [0] https://webstats.torproject.org/ [1] https://metrics.torproject.org/web-server-logs.html [2] https://metrics.torproject.org/metrics-lib/ https://metrics.torproject.org/metrics-lib/index.html?org/torproject/descri… https://metrics.torproject.org/metrics-lib/index.html?org/torproject/descri… [3] https://gitweb.torproject.org/collector.git/tree/CHANGELOG.md?h=collector-1… [4] https://gitweb.torproject.org/metrics-lib.git/tree/CHANGELOG.md?h=metrics-l… [5] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Creating custom Tor Browser settings profile
by procmem 26 Feb '18

26 Feb '18

Hi I was wondering if Tor Broswer supports environment variables to customize about:config settings. The idea is to ship an explicitly labelled, custom profile one day to allow users seamless access to localhost daemons (like zeronet) by changing network.proxy.no_proxies_on to 0 - so they don't have to jump thru hoops or install foreign code like foxyproxy. At the same time, a separate browser profile affords regular users protection by keeping these fingerprinatble, non default settings contained and only used when the user needs them. Any way to do this?

2 1

txtorcon 0.20.0
by meejah 23 Feb '18

23 Feb '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm very happy to release txtorcon 0.20.0. This includes a few minor new features and an important bug fix if you're using a Tor new enough to have all the *PortLines changes (anything after 0.3.0.6; see Tor issue #20956). Full list of changes: * doc fixes (from hotelzululima) * Issue 246: fix endpoints so .connect on them works properly more than once (from Brian Warner) * allow a CertificateOptions to be passed as tls= to endpoints * PR 252: add method txtorcon.Tor.is_ready * PR 252: add method txtorcon.Tor.become_ready * PR 253: fix handling of certain defaults (*PortLines and friends) * fix last router (usually) missing with (new) `MicroDescriptorParser` * use OnionOO via Onion service tgel7v4rpcllsrk2.onion for txtorcon.Router.get_onionoo_details * fix parsing of Router started-times * Issue 255: removed routers always deleted following NEWCONSENSUS * Issue 279: remember proxy endpoint if it was Deferred You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.20.0 https://github.com/meejah/txtorcon/releases/tag/v0.20.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.20.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.20.0.tar.gz.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check dc80cb76b3ddacef6d671c0a088cb1a45274c0858554c32ce55d0f41421c740e txtorcon-0.20.0.tar.gz a957b3dc10f0b2b882ef6ad46d2932fa7731d5eeee6d52ba9d736d2bc4f1385f txtorcon-0.20.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJaj2AIAAoJEMJgKAMSgGmnnGUIANXkNIF8c98nwCa4Q9Xws3Hv 9zAJSWsDst/58lHka6bE5d1JWYz78fTubTC2ofOFH0MOkjeSyEtgTO58xlKY9wTC w7ohePwcV+md1wPOpciHVZMBVhqUhKGqNhMYehTXjcCEwppgXhiINgGFLaF0XSUM aJzY7laEvg2E/1p+gH0e4tkJuSVKVOK+5MWBali8YlOZY28R6w/X0Q0n8su1ntl2 bKsxpTrv+p8J+K7WvpeaXIuZnC/fRwVFZ0vtwzKtrTKimAE60yPfOi5hLUyW2PGx FkpH6B0bgl5FMiY+Y0PV8rP2DXikCibpwsipBh4AHpTYGSdMkSogjiRupkJxeeQ= =GsVt -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] [prop-meeting] [prop#267] "Tor Consensus Transparency"
by Tom Ritter 21 Feb '18

21 Feb '18

On 17 February 2018 at 00:31, isis agora lovecruft <isis(a)patternsinthevoid.net> wrote: > 1. Tuesdays @ 18:00 UTC (10:00 PST/13:00 EST/20:00 CET/05:00+1 AEDT) This time works for me. -tom

3 2

Nominate/vote for future proposal discussion meetings!
by isis agora lovecruft 21 Feb '18

21 Feb '18

Hello all, Is there an existing Tor proposal you'd like to discuss? Please use the following pad to nominate and vote for proposals for discussion. https://pad.riseup.net/p/Pxo2fQiiaSWo We'll be reviving our proposal discussion meetings soon, likely at the beginning of January once people have returned from their winter holidays. After the nominations/votes are taken, I'll start arranging meeting times. If you nominate and/or vote for a proposal, I may reach out to you at some point for your opinions on discussion items, open questions/concerns, etc. to include for the meeting preparation. Thanks! Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

6 18

Enhancement for Tor 0.3.4.x
by David Goulet 19 Feb '18

19 Feb '18

Hello everone! As an effort to better organize our 0.3.4.x release for which the merge window opens in 3 days (Feb 15th, 2018), we need to identify the enhancement(s) that we want so we can better prioritize the development during the merge window timeframe (3 months). Each feature should have its ticket marked for 0.3.4 milestone and with an Owner set so we know who is "leading" that effort. It doesn't have to be the person who code the whole thing but should be a good point of contact to start with (and it can change over time as well). It is possible that an enhancement can have more than one ticket so in this case, please make a "parent" ticket that explains the whole thing and child tickets assigned to it. The network team just had its weekly meeting and if I recall correctly, these enhancement should be planned for 0.3.4 (please the people who works on this, can you tell us the tickets and make sure they are up to date?) - Privcount (prop#280) - large CREATE cells (prop#249) If you plan to do a set of patches for a feature or enhancement, please do submit it on this thread and make sure a proper ticket exists with an Owner. Also, if you just want something in 0.3.4 as enhancement but might not work on it, it is also OK to propose it (ticket and all) but please lets try as much as possible to keep that thread focused on doable work with tickets and not just a "dump all my tor wishes" :). For this, open a ticket :). Big thanks everyone! David -- 1xYrq8XhE25CKCQqvcX/cqKg04v1HthMMM3PwaRqqdU=

5 6

Cross compiling Tor for Windows
by Alexander Færøy 19 Feb '18

19 Feb '18

Hello. I have recently been trying to wrap my head around some of the Windows/Unix I/O code of Tor to do an API experiment with the PT subsystem. While working on this I remembered that Nick did a cool trick during the development of the consensus diff feature where he managed to reproduce a Windows only test case failure with Wine on Linux using a cross compiled version of Tor that he build on Linux as well. I wanted to try out if I was able to make use of this "trick" as well and decided to write a short guide for setting up the cross compilation environment for Tor on Debian. The guide is published at https://github.com/ahf/tor-win32 The tor-win32 repository also contains a Makefile that will fetch and cross compile a minimal set of dependencies of Tor (OpenSSL, Libevent, and zlib) and Tor itself to the point where you should be able to run both tor.exe and the test suites in Wine. I hope this might be useful to someone else if they find themselves having a need to quickly try something out on "Windows" without actually having to install it -- remember though that this is not the same as running Tor and the test suites on an actual Windows machine, which is what many of our users are using! :-) Cheers, Alex. -- Alexander Færøy

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev