[tor-reports] Fwd: Core Tor reports for April and May

Tue Jul 5 16:58:38 UTC 2016

Realizing just now that I sent this from the wrong email and it bounced.
Sorry!
Isabela

-------- Forwarded Message --------
Subject: 	Core Tor reports for April and May
Date: 	Fri, 17 Jun 2016 09:23:49 -0700
From: 	isabela <isabela at torproject.org>
Reply-To: 	isabela at torproject.org
Organization: 	The Tor Project
To: 	tor-reports at lists.torproject.org

Reports sent to OTF for Core Tor work in April and May.

Cheers,
Isabela

-- 
PM at TorProject.org
gpg fingerprint = 8F2A F9B6 D4A1 4D03 FDF1  B298 3224 4994 1506 4C7B
@isa

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-reports/attachments/20160705/ce32aa1a/attachment.html>
-------------- next part --------------
Core Tor April 2016 report

We worked on ticket #18613[1] which adds a new class of non-fatal replacements for tor_assert(), to avoid cases where tor_assert() could be used in a DoS attack. tor_assert() validates a condition in the () which should always be true, and if that condition happens to be false, it agressively stops tor.  But very often, when a "should always be true" condition is false, we'd prefer a less extreme behavior: stopping Tor can be exploited by a DoS attack.

Worked on #14334[2] to fix a bug when registering guard status in connection_or_connect() and worked on adding back (#18624 [3]) rule for Dir auths to only give a Guard if Stable, this will remove some unecessary complexity that we were getting with one edge case for a small fraction of unlucky clients who picked a non-Stable Guard, since when they build circuits that require the Stable flag, they will always use their second Guard for those circuits.

[1] https://trac.torproject.org/projects/tor/ticket/18613
[2] https://trac.torproject.org/projects/tor/ticket/14334
[3] https://trac.torproject.org/projects/tor/ticket/18624

-------------- next part --------------
Core Tor May 2016 report

On May we put out a new tor alpha release, Tor 0.2.8.3-alpha [1], solving some severe bugs introduced during the 0.2.8 release cycle. Among them were a crash and out-of-bounds write during authority voting, when the list of relays includes duplicate ed25519 identity keys (ticket #19032 [2])

We finalized support for an important new feature, "Fallback Directories". Previously, whenever Tor clients would connect to the network for the first time, they would learn about servers by contacting the directory authorities directly. Unfortunately, this old design placed excess load on the directory authorities, making them more susceptible to denial-of-service attack.  To make bootstrapping more robust, clients now use a list of "Fallback Directories" -- preconfigured directory caches which we expect to remain online for a while.  With ticket #17158[3], we ran an opt-in process to ensure that we could ship Tor 0.2.8 with a list of fallback directories which we believe should be available for some time in the future.

Since we have changed Tor relays to begin using using Ed25519 keys for improved security, we decided it would be important to document the storage location[4]and these keys, so that relay operators can maintain them correctly.   The how-to documentation was published on our wiki [5]; more detailed documentation on how keys are stored were added to the reference manual.

On May we also publish a 'bug retrospective' analyses for mid 2016[6], was an exercise to identify trends in the bugs we have found. By finding trends, we can try to identify ways to develop our software better. This analyses contain recommendations and we want to use them to identify actionable items to improve our future code practices. Our goal is to adopt such practices and do another restrospective in a year or two to evaluate the impact they had and what else can be improved.

[1] https://blog.torproject.org/blog/tor-0283-alpha-released
[2] https://trac.torproject.org/projects/tor/ticket/19032
[3] https://trac.torproject.org/projects/tor/ticket/17158
[4] https://trac.torproject.org/projects/tor/ticket/17853
[5] https://trac.torproject.org/projects/tor/wiki/doc/DirauthEd25519Keys
[6] https://blog.torproject.org/blog/mid-2016-tor-bug-retrospective-lessons-future-coding
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-reports/attachments/20160705/ce32aa1a/attachment.sig>