- tor-dev - lists.torproject.org

3.2.10 compiler warnings
by grarpamp 11 Mar '18

11 Mar '18

Test from an older system before it was updated, unlikely to be prevalent, so don't bother fixing unless obvious. src/common/confline.c:135: warning: 'include_list' may be used uninitialized in this function src/common/confline.c:135: warning: 'include_list' may be used uninitialized in this function src/or/connection.c:1883: warning: passing argument 1 of 'TO_OR_CONN' discards qualifiers from pointer target type src/or/conscache.c:426: warning: passing argument 2 of 'consensus_cache_entry_map' discards qualifiers from pointer target type src/or/control.c:6815: warning: passing argument 1 of 'TO_OR_CONN' discards qualifiers from pointer target type src/or/scheduler.c:577: warning: format '%ld' expects type 'long int', but argument 5 has type 'time_t' src/or/connection.c:1883: warning: passing argument 1 of 'TO_OR_CONN' discards qualifiers from pointer target type src/or/conscache.c:426: warning: passing argument 2 of 'consensus_cache_entry_map' discards qualifiers from pointer target type src/or/control.c:6815: warning: passing argument 1 of 'TO_OR_CONN' discards qualifiers from pointer target type src/or/scheduler.c:577: warning: format '%ld' expects type 'long int', but argument 5 has type 'time_t' src/test/vote_descriptors.inc:93: warning: string length '4135' is greater than the length '4095' ISO C99 compilers are required to support src/test/test_hs_descriptor.inc:224: warning: string length '14104' is greater than the length '4095' ISO C99 compilers are required to support src/test/test_microdesc.c:648: warning: string length '5844' is greater than the length '4095' ISO C99 compilers are required to support src/test/test_descriptors.inc:305: warning: string length '10571' is greater than the length '4095' ISO C99 compilers are required to support

2 2

Proposal Waterfilling
by Florentin Rochet 10 Mar '18

10 Mar '18

Hello everyone, In order that our paper does not fall into the list of "yet another seems-to-be-cool-feature is that never going to be discussed because researchers moved on another topic", here is an attached proposal in which we summarize our work published in the last PETS event and how it can be implemented. And, if you find this interesting, I would be glad to submit a patch :) Any kind of feedbacks is more than welcome! Cheers! Florentin

8 29

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