tor-commits
Threads by month
- ----- 2025 -----
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
November 2015
- 20 participants
- 856 discussions

[translation/tails-persistence-setup_completed] Update translations for tails-persistence-setup_completed
by translation@torproject.org 05 Nov '15
by translation@torproject.org 05 Nov '15
05 Nov '15
commit c5f0ab8689f2c7df369c5e28b36c83110c202034
Author: Translation commit bot <translation(a)torproject.org>
Date: Thu Nov 5 17:15:26 2015 +0000
Update translations for tails-persistence-setup_completed
---
pt/pt.po | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/pt/pt.po b/pt/pt.po
index 3269ef7..6a52cd2 100644
--- a/pt/pt.po
+++ b/pt/pt.po
@@ -6,8 +6,9 @@
# alfalb.as, 2015
# Lídia Martins <lolplayer713(a)gmail.com>, 2015
# kagazz <lourenxo_619(a)hotmail.com>, 2014
+# Luís Barroso <lacmbarroso(a)gmail.com>, 2015
# alfalb_mansil, 2014
-# MMSRS <h_manuela_rodsilva(a)gmail.com>, 2015
+# Manuela Silva <h_manuela_rodsilva(a)gmail.com>, 2015
# Nizia Dantas <nizia.dantas(a)gmail.com>, 2014
# Andrew Melim <nokostya.translation(a)gmail.com>, 2014
# Pedro Albuquerque <palbuquerque73(a)gmail.com>, 2014
@@ -16,9 +17,9 @@ msgid ""
msgstr ""
"Project-Id-Version: The Tor Project\n"
"Report-Msgid-Bugs-To: Tails developers <tails(a)boum.org>\n"
-"POT-Creation-Date: 2015-08-05 19:02+0200\n"
-"PO-Revision-Date: 2015-09-14 14:11+0000\n"
-"Last-Translator: MMSRS <h_manuela_rodsilva(a)gmail.com>\n"
+"POT-Creation-Date: 2015-10-26 14:15+0100\n"
+"PO-Revision-Date: 2015-11-05 16:46+0000\n"
+"Last-Translator: Luís Barroso <lacmbarroso(a)gmail.com>\n"
"Language-Team: Portuguese (http://www.transifex.com/otf/torproject/language/pt/)\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
@@ -123,10 +124,18 @@ msgid "Lists downloaded by APT"
msgstr "Listas transferidas por APT"
#: ../lib/Tails/Persistence/Configuration/Presets.pm:168
+msgid "Icedove"
+msgstr "Icedove"
+
+#: ../lib/Tails/Persistence/Configuration/Presets.pm:170
+msgid "Icedove profiles and locally stored email"
+msgstr "Perfil do Icedove e email armazenado localmente"
+
+#: ../lib/Tails/Persistence/Configuration/Presets.pm:178
msgid "Dotfiles"
msgstr "Ficheiros Dot"
-#: ../lib/Tails/Persistence/Configuration/Presets.pm:170
+#: ../lib/Tails/Persistence/Configuration/Presets.pm:180
msgid ""
"Symlink into $HOME every file or directory found in the `dotfiles' directory"
msgstr "Hiperligação simbólica com $HOME de todos os ficheiros ou diretorias encontradas na diretoria 'dotfiles'"
1
0

[translation/tails-persistence-setup] Update translations for tails-persistence-setup
by translation@torproject.org 05 Nov '15
by translation@torproject.org 05 Nov '15
05 Nov '15
commit ef7582afdf11d2639269515dd54135c343fd50a7
Author: Translation commit bot <translation(a)torproject.org>
Date: Thu Nov 5 17:15:22 2015 +0000
Update translations for tails-persistence-setup
---
pt/pt.po | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/pt/pt.po b/pt/pt.po
index e79b2f3..6a52cd2 100644
--- a/pt/pt.po
+++ b/pt/pt.po
@@ -6,8 +6,9 @@
# alfalb.as, 2015
# Lídia Martins <lolplayer713(a)gmail.com>, 2015
# kagazz <lourenxo_619(a)hotmail.com>, 2014
+# Luís Barroso <lacmbarroso(a)gmail.com>, 2015
# alfalb_mansil, 2014
-# MMSRS <h_manuela_rodsilva(a)gmail.com>, 2015
+# Manuela Silva <h_manuela_rodsilva(a)gmail.com>, 2015
# Nizia Dantas <nizia.dantas(a)gmail.com>, 2014
# Andrew Melim <nokostya.translation(a)gmail.com>, 2014
# Pedro Albuquerque <palbuquerque73(a)gmail.com>, 2014
@@ -17,8 +18,8 @@ msgstr ""
"Project-Id-Version: The Tor Project\n"
"Report-Msgid-Bugs-To: Tails developers <tails(a)boum.org>\n"
"POT-Creation-Date: 2015-10-26 14:15+0100\n"
-"PO-Revision-Date: 2015-10-27 08:44+0000\n"
-"Last-Translator: carolyn <carolyn(a)anhalt.org>\n"
+"PO-Revision-Date: 2015-11-05 16:46+0000\n"
+"Last-Translator: Luís Barroso <lacmbarroso(a)gmail.com>\n"
"Language-Team: Portuguese (http://www.transifex.com/otf/torproject/language/pt/)\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
@@ -124,11 +125,11 @@ msgstr "Listas transferidas por APT"
#: ../lib/Tails/Persistence/Configuration/Presets.pm:168
msgid "Icedove"
-msgstr ""
+msgstr "Icedove"
#: ../lib/Tails/Persistence/Configuration/Presets.pm:170
msgid "Icedove profiles and locally stored email"
-msgstr ""
+msgstr "Perfil do Icedove e email armazenado localmente"
#: ../lib/Tails/Persistence/Configuration/Presets.pm:178
msgid "Dotfiles"
1
0

[translation/liveusb-creator] Update translations for liveusb-creator
by translation@torproject.org 05 Nov '15
by translation@torproject.org 05 Nov '15
05 Nov '15
commit 67e81a10f4449d7b62a099a8af34c95ecb06bb82
Author: Translation commit bot <translation(a)torproject.org>
Date: Thu Nov 5 16:15:20 2015 +0000
Update translations for liveusb-creator
---
nl/nl.po | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/nl/nl.po b/nl/nl.po
index 2d4268f..d29eba6 100644
--- a/nl/nl.po
+++ b/nl/nl.po
@@ -19,7 +19,7 @@ msgstr ""
"Project-Id-Version: The Tor Project\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2015-11-02 21:23+0100\n"
-"PO-Revision-Date: 2015-11-03 15:44+0000\n"
+"PO-Revision-Date: 2015-11-05 16:13+0000\n"
"Last-Translator: Volluta <volluta(a)tutanota.com>\n"
"Language-Team: Dutch (http://www.transifex.com/otf/torproject/language/nl/)\n"
"MIME-Version: 1.0\n"
@@ -80,7 +80,7 @@ msgid ""
"<li>The encrypted persistent storage of the Tails USB stick that you are currently using is not copied.</li>\n"
"\n"
"</ul>"
-msgstr ""
+msgstr "<ul>\n<li>Installeer Tails op een andere USB stick door het kopieren van het Tails systeem wat je op dit moment gebruikt..</li>\n\n<li>De USB stick waarop je installeert is geformatteerd en alle data is verwijderd.</li>\n\n<li> Het ge-encrypte persistente opslag van de Tails USB stick die u op dit moment gebruikt is niet gekopieerd.</li>\n\n</ul>"
#: ../liveusb/launcher_ui.py:157
msgid ""
1
0
commit 5a370618859573ed1eb5dabbe0ed2e773a579817
Author: Nick Mathewson <nickm(a)torproject.org>
Date: Thu Nov 5 09:53:05 2015 -0500
Delete trailing whitespace in md files
---
doc/HACKING/CodingStandards.md | 6 +++---
doc/HACKING/GettingStarted.md | 13 +++++--------
doc/HACKING/HelpfulTools.md | 5 ++---
doc/HACKING/ReleasingTor.md | 18 +++++++++---------
4 files changed, 19 insertions(+), 23 deletions(-)
diff --git a/doc/HACKING/CodingStandards.md b/doc/HACKING/CodingStandards.md
index f7541d7..d2fc784 100644
--- a/doc/HACKING/CodingStandards.md
+++ b/doc/HACKING/CodingStandards.md
@@ -81,7 +81,7 @@ in changes to make a draft changelog, and clear the directory. We'll
then edit the draft changelog into a nice readable format.
What needs a changes file?
-
+
* A not-exhaustive list: Anything that might change user-visible
behavior. Anything that changes internals, documentation, or the build
system enough that somebody could notice. Big or interesting code
@@ -89,7 +89,7 @@ What needs a changes file?
did that happen, and/or why did we do that" 6 months down the line.
Why use changes files instead of Git commit messages?
-
+
* Git commit messages are written for developers, not users, and they
are nigh-impossible to revise after the fact.
@@ -151,7 +151,7 @@ Functions not to write
----------------------
Try to never hand-write new code to parse or generate binary
-formats. Instead, use trunnel if at all possible. See
+formats. Instead, use trunnel if at all possible. See
https://gitweb.torproject.org/trunnel.git/tree
diff --git a/doc/HACKING/GettingStarted.md b/doc/HACKING/GettingStarted.md
index 4ab26b7..0295adc 100644
--- a/doc/HACKING/GettingStarted.md
+++ b/doc/HACKING/GettingStarted.md
@@ -40,8 +40,8 @@ Once you've reached this point, here's what you need to know.
1. Get the source.
We keep our source under version control in Git. To get the latest
- version, run
-
+ version, run
+
git clone https://git.torproject.org/git/tor
This will give you a checkout of the master branch. If you're
@@ -54,7 +54,7 @@ Once you've reached this point, here's what you need to know.
Our overall code structure is explained in the "torguts" documents,
currently at
-
+
git clone https://git.torproject.org/user/nickm/torguts.git
Find a part of the code that looks interesting to you, and start
@@ -88,7 +88,7 @@ Once you've reached this point, here's what you need to know.
For your first patch, it is probably NOT a good idea to make
something huge or invasive. In particular, you should probably
avoid:
-
+
* Major changes spread across many parts of the codebase.
* Major changes to programming practice or coding style.
* Huge new features or protocol changes.
@@ -182,9 +182,6 @@ Once you've reached this point, here's what you need to know.
say so! And if you won't have time to make some of the
changes, you should say that too, so that other developers
will be able to pick up the unfinished portion.
-
+
Congratulations! You have now written your first patch, and gotten
it integrated into mainline Tor.
-
-
-
diff --git a/doc/HACKING/HelpfulTools.md b/doc/HACKING/HelpfulTools.md
index 810519c..a7f36e6 100644
--- a/doc/HACKING/HelpfulTools.md
+++ b/doc/HACKING/HelpfulTools.md
@@ -101,7 +101,7 @@ working connection to the internet:
Running gcov for unit test coverage
-----------------------------------
-
+
./configure --enable-coverage
make
make check
@@ -243,7 +243,7 @@ We use the 'doxygen' utility to generate documentation from our
source code. Here's how to use it:
1. Begin every file that should be documented with
-
+
/**
* \file filename.c
* \brief Short description of the file.
@@ -291,4 +291,3 @@ source code. Here's how to use it:
6. See the Doxygen manual for more information; this summary just
scratches the surface.
-
diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md
index 845a61b..c58e349 100644
--- a/doc/HACKING/ReleasingTor.md
+++ b/doc/HACKING/ReleasingTor.md
@@ -6,20 +6,20 @@ Here are the steps Roger takes when putting out a new Tor release:
1. Use it for a while, as a client, as a relay, as a hidden service,
and as a directory authority. See if it has any obvious bugs, and
- resolve those.
-
+ resolve those.
+
As applicable, merge the `maint-X` branch into the `release-X` branch.
2. Gather the `changes/*` files into a changelog entry, rewriting many
of them and reordering to focus on what users and funders would find
interesting and understandable.
- 1. Make sure that everything that wants a bug number has one.
+ 1. Make sure that everything that wants a bug number has one.
Make sure that everything which is a bugfix says what version
it was a bugfix on.
-
+
2. Concatenate them.
-
+
3. Sort them by section. Within each section, sort by "version it's
a bugfix on", else by numerical ticket order.
@@ -55,7 +55,7 @@ Here are the steps Roger takes when putting out a new Tor release:
If a given changes stanza showed up in a different release (e.g.
maint-0.2.1), be sure to make the stanzas identical (so people can
distinguish if these are the same change).
-
+
5. Merge them in.
6. Clean everything one last time.
@@ -94,7 +94,7 @@ Here are the steps Roger takes when putting out a new Tor release:
in their approved versions list.
7. Sign the tarball, then sign and push the git tag:
-
+
gpg -ba <the_tarball>
git tag -u <keyid> tor-0.2.x.y-status
git push origin tag tor-0.2.x.y-status
@@ -103,12 +103,12 @@ Here are the steps Roger takes when putting out a new Tor release:
`/srv/dist-master.torproject.org/htdocs/` on dist-master. When you want
it to go live, you run "static-update-component dist.torproject.org"
on dist-master.
-
+
Edit `include/versions.wmi` and `Makefile` to note the new version.
9. Email the packagers (cc'ing tor-assistants) that a new tarball is up.
The current list of packagers is:
-
+
- {weasel,gk,mikeperry} at torproject dot org
- {blueness} at gentoo dot org
- {paul} at invizbox dot io
1
0
commit 43ce4626f1c23f723a3007e91cfb1ed5f8a75712
Author: Nick Mathewson <nickm(a)torproject.org>
Date: Thu Nov 5 09:46:40 2015 -0500
add release notes
---
doc/HACKING/ReleasingTor.md | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md
index 12a0765..845a61b 100644
--- a/doc/HACKING/ReleasingTor.md
+++ b/doc/HACKING/ReleasingTor.md
@@ -68,6 +68,16 @@ Here are the steps Roger takes when putting out a new Tor release:
to a release-0.2.x branch, manually commit the changelogs to the later
git branches too.
+ If you're doing the first stable release in a series, you need to
+ create a ReleaseNotes for the series as a whole. To get started
+ there, copy all of the Changelog entries from the series into a new
+ file, and run `./scripts/maint/sortChanges.py` on it. That will
+ group them by category. Then kill every bugfix entry for fixing
+ bugs that were introduced within that release series; those aren't
+ relevant changes since the last series. At that point, it's time
+ to start sorting and condensing entries. (Generally, we don't edit the
+ text of existing entries, though.)
+
4. In `maint-0.2.x`, bump the version number in `configure.ac` and run
`scripts/maint/updateVersions.pl` to update version numbers in other
places, and commit. Then merge `maint-0.2.x` into `release-0.2.x`.
1
0

05 Nov '15
commit 7bce3efb9e86e13a7cb40163bc5ec35807ef1c1b
Author: Nick Mathewson <nickm(a)torproject.org>
Date: Thu Nov 5 09:24:33 2015 -0500
Start the ReleaseNotes for 0.2.7.5.
This is just the changelogs for 0.2.7.[1234]-{alpha,rc} passed through
sortChanges.pl.
---
ReleaseNotes | 781 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 781 insertions(+)
diff --git a/ReleaseNotes b/ReleaseNotes
index 44cda49..b84c4da 100644
--- a/ReleaseNotes
+++ b/ReleaseNotes
@@ -2,6 +2,787 @@
This document summarizes new features and bugfixes in each stable release
of Tor. If you want to see more detailed descriptions of the changes in
each development snapshot, see the ChangeLog file.
+
+Changes in version 0.2.7.5- 2015-11-??
+ XXXX WRITE A BLURB
+
+ o Major features (controller):
+ - Add the ADD_ONION and DEL_ONION commands that allow the creation
+ and management of hidden services via the controller. Closes
+ ticket 6411.
+ - New "GETINFO onions/current" and "GETINFO onions/detached"
+ commands to get information about hidden services created via the
+ controller. Part of ticket 6411.
+ - New HSFETCH command to launch a request for a hidden service
+ descriptor. Closes ticket 14847.
+ - New HSPOST command to upload a hidden service descriptor. Closes
+ ticket 3523. Patch by "DonnchaC".
+
+ o Major features (Ed25519 identity keys, Proposal 220):
+ - Add support for offline encrypted Ed25519 master keys. To use this
+ feature on your tor relay, run "tor --keygen" to make a new master
+ key (or to make a new signing key if you already have a master
+ key). Closes ticket 13642.
+ - All relays now maintain a stronger identity key, using the Ed25519
+ elliptic curve signature format. This master key is designed so
+ that it can be kept offline. Relays also generate an online
+ signing key, and a set of other Ed25519 keys and certificates.
+ These are all automatically regenerated and rotated as needed.
+ Implements part of ticket 12498.
+ - Directory authorities now vote on Ed25519 identity keys along with
+ RSA1024 keys. Implements part of ticket 12498.
+ - Directory authorities track which Ed25519 identity keys have been
+ used with which RSA1024 identity keys, and do not allow them to
+ vary freely. Implements part of ticket 12498.
+ - Microdescriptors now include Ed25519 identity keys. Implements
+ part of ticket 12498.
+
+ o Major features (Ed25519 keys, keypinning):
+ - The key-pinning option on directory authorities is now advisory-
+ only by default. In a future version, or when the AuthDirPinKeys
+ option is set, pins are enforced again. Disabling key-pinning
+ seemed like a good idea so that we can survive the fallout of any
+ usability problems associated with Ed25519 keys. Closes
+ ticket 17135.
+
+ o Major features (Ed25519 performance):
+ - Improve the runtime speed of Ed25519 signature verification by
+ using Ed25519-donna's batch verification support. Implements
+ ticket 16533.
+ - Improve the speed of Ed25519 operations and Curve25519 keypair
+ generation when built targeting 32 bit x86 platforms with SSE2
+ available. Implements ticket 16535.
+
+ o Major features (Hidden services):
+ - Add the torrc option HiddenServiceNumIntroductionPoints, to
+ specify a fixed number of introduction points. Its maximum value
+ is 10 and default is 3. Using this option can increase a hidden
+ service's reliability under load, at the cost of making it more
+ visible that the hidden service is facing extra load. Closes
+ ticket 4862.
+ - Remove the adaptive algorithm for choosing the number of
+ introduction points, which used to change the number of
+ introduction points (poorly) depending on the number of
+ connections the HS sees. Closes ticket 4862.
+
+ o Major features (onion key cross-certification):
+ - Relay descriptors now include signatures of their own identity
+ keys, made using the TAP and ntor onion keys. These signatures
+ allow relays to prove ownership of their own onion keys. Because
+ of this change, microdescriptors will no longer need to include
+ RSA identity keys. Implements proposal 228; closes ticket 12499.
+
+ o Major features (performance testing):
+ - The test-network.sh script now supports performance testing.
+ Requires corresponding chutney performance testing changes. Patch
+ by "teor". Closes ticket 14175.
+
+ o Major features (performance):
+ - Improve the runtime speed of Ed25519 operations by using the
+ public-domain Ed25519-donna by Andrew M. ("floodyberry").
+ Implements ticket 16467.
+ - Improve the runtime speed of the ntor handshake by using an
+ optimized curve25519 basepoint scalarmult implementation from the
+ public-domain Ed25519-donna by Andrew M. ("floodyberry"), based on
+ ideas by Adam Langley. Implements ticket 9663.
+
+ o Major features (relay, Ed25519):
+ - Add a --newpass option to allow changing or removing the
+ passphrase of an encrypted key with tor --keygen. Implements part
+ of ticket 16769.
+ - Add a new OfflineMasterKey option to tell Tor never to try loading
+ or generating a secret Ed25519 identity key. You can use this in
+ combination with tor --keygen to manage offline and/or encrypted
+ Ed25519 keys. Implements ticket 16944.
+ - On receiving a HUP signal, check to see whether the Ed25519
+ signing key has changed, and reload it if so. Closes ticket 16790.
+ - Significant usability improvements for Ed25519 key management. Log
+ messages are better, and the code can recover from far more
+ failure conditions. Thanks to "s7r" for reporting and diagnosing
+ so many of these!
+
+ o Major features (security, hidden services):
+ - Hidden services, if using the EntryNodes option, are required to
+ use more than one EntryNode, in order to avoid a guard discovery
+ attack. (This would only affect people who had configured hidden
+ services and manually specified the EntryNodes option with a
+ single entry-node. The impact was that it would be easy to
+ remotely identify the guard node used by such a hidden service.
+ See ticket for more information.) Fixes ticket 14917.
+
+ o Major bugfixes (client-side privacy, also in 0.2.6.9):
+ - Properly separate out each SOCKSPort when applying stream
+ isolation. The error occurred because each port's session group
+ was being overwritten by a default value when the listener
+ connection was initialized. Fixes bug 16247; bugfix on
+ 0.2.6.3-alpha. Patch by "jojelino".
+
+ o Major bugfixes (correctness):
+ - Fix a use-after-free bug in validate_intro_point_failure(). Fixes
+ bug 17401; bugfix on 0.2.7.3-rc.
+
+ o Major bugfixes (hidden service clients, stability, also in 0.2.6.10):
+ - Stop refusing to store updated hidden service descriptors on a
+ client. This reverts commit 9407040c59218 (which indeed fixed bug
+ 14219, but introduced a major hidden service reachability
+ regression detailed in bug 16381). This is a temporary fix since
+ we can live with the minor issue in bug 14219 (it just results in
+ some load on the network) but the regression of 16381 is too much
+ of a setback. First-round fix for bug 16381; bugfix
+ on 0.2.6.3-alpha.
+
+ o Major bugfixes (hidden services):
+ - Revert commit that made directory authorities assign the HSDir
+ flag to relay without a DirPort; this was bad because such relays
+ can't handle BEGIN_DIR cells. Fixes bug 15850; bugfix
+ on tor-0.2.6.3-alpha.
+ - When cannibalizing a circuit for an introduction point, always
+ extend to the chosen exit node (creating a 4 hop circuit).
+ Previously Tor would use the current circuit exit node, which
+ changed the original choice of introduction point, and could cause
+ the hidden service to skip excluded introduction points or
+ reconnect to a skipped introduction point. Fixes bug 16260; bugfix
+ on 0.1.0.1-rc.
+
+ o Major bugfixes (memory leaks):
+ - Fix a memory leak in ed25519 batch signature checking. Fixes bug
+ 17398; bugfix on 0.2.6.1-alpha.
+ - Fix a memory leak in rend_cache_failure_entry_free(). Fixes bug
+ 17402; bugfix on 0.2.7.3-rc.
+ - Fix a memory leak when reading an expired signing key from disk.
+ Fixes bug 17403; bugfix on 0.2.7.2-rc.
+
+ o Major bugfixes (open file limit):
+ - The open file limit wasn't checked before calling
+ tor_accept_socket_nonblocking(), which would make Tor exceed the
+ limit. Now, before opening a new socket, Tor validates the open
+ file limit just before, and if the max has been reached, return an
+ error. Fixes bug 16288; bugfix on 0.1.1.1-alpha.
+
+ o Major bugfixes (relay, Ed25519):
+ - Avoid crashing on 'tor --keygen'. Fixes bug 16679; bugfix on
+ 0.2.7.2-alpha. Reported by "s7r".
+ - Improve handling of expired signing keys with offline master keys.
+ Fixes bug 16685; bugfix on 0.2.7.2-alpha. Reported by "s7r".
+
+ o Major bugfixes (security, correctness):
+ - Fix an error that could cause us to read 4 bytes before the
+ beginning of an openssl string. This bug could be used to cause
+ Tor to crash on systems with unusual malloc implementations, or
+ systems with unusual hardening installed. Fixes bug 17404; bugfix
+ on 0.2.3.6-alpha.
+
+ o Major bugfixes (stability, also in 0.2.6.10):
+ - Stop crashing with an assertion failure when parsing certain kinds
+ of malformed or truncated microdescriptors. Fixes bug 16400;
+ bugfix on 0.2.6.1-alpha. Found by "torkeln"; fix based on a patch
+ by "cypherpunks_backup".
+ - Stop random client-side assertion failures that could occur when
+ connecting to a busy hidden service, or connecting to a hidden
+ service while a NEWNYM is in progress. Fixes bug 16013; bugfix
+ on 0.1.0.1-rc.
+
+ o Minor features (client):
+ - Add GroupWritable and WorldWritable options to unix-socket based
+ SocksPort and ControlPort options. These options apply to a single
+ socket, and override {Control,Socks}SocketsGroupWritable. Closes
+ ticket 15220.
+ - Relax the validation done to hostnames in SOCKS5 requests, and
+ allow a single trailing '.' to cope with clients that pass FQDNs
+ using that syntax to explicitly indicate that the domain name is
+ fully-qualified. Fixes bug 16674; bugfix on 0.2.6.2-alpha.
+ - Relax the validation of hostnames in SOCKS5 requests, allowing the
+ character '_' to appear, in order to cope with domains observed in
+ the wild that are serving non-RFC compliant records. Resolves
+ ticket 16430.
+
+ o Minor features (client-side privacy):
+ - New KeepAliveIsolateSOCKSAuth option to indefinitely extend circuit
+ lifespan when IsolateSOCKSAuth and streams with SOCKS
+ authentication are attached to the circuit. This allows
+ applications like TorBrowser to manage circuit lifetime on their
+ own. Implements feature 15482.
+ - When logging malformed hostnames from SOCKS5 requests, respect
+ SafeLogging configuration. Fixes bug 16891; bugfix on 0.1.1.16-rc.
+
+ o Minor features (clock-jump tolerance):
+ - Recover better when our clock jumps back many hours, like might
+ happen for Tails or Whonix users who start with a very wrong
+ hardware clock, use Tor to discover a more accurate time, and then
+ fix their clock. Resolves part of ticket 8766.
+
+ o Minor features (command-line interface):
+ - Make --hash-password imply --hush to prevent unnecessary noise.
+ Closes ticket 15542. Patch from "cypherpunks".
+ - Print a warning whenever we find a relative file path being used
+ as torrc option. Resolves issue 14018.
+
+ o Minor features (compilation):
+ - Fail during configure if we're trying to build against an OpenSSL
+ built without ECC support. Fixes bug 17109, bugfix on 0.2.7.1-alpha
+ which started requiring ECC.
+ - Give a warning as early as possible when trying to build with an
+ unsupported OpenSSL version. Closes ticket 16901.
+
+ o Minor features (control protocol):
+ - Support network-liveness GETINFO key and NETWORK_LIVENESS event in
+ the control protocol. Resolves ticket 15358.
+
+ o Minor features (controller):
+ - Add DirAuthority lines for default directory authorities to the
+ output of the "GETINFO config/defaults" command if not already
+ present. Implements ticket 14840.
+ - Controllers can now use "GETINFO hs/client/desc/id/..." to
+ retrieve items from the client's hidden service descriptor cache.
+ Closes ticket 14845.
+ - Implement a new controller command "GETINFO status/fresh-relay-
+ descs" to fetch a descriptor/extrainfo pair that was generated on
+ demand just for the controller's use. Implements ticket 14784.
+
+ o Minor features (directory authorities):
+ - Directory authorities no longer vote against the "Fast", "Stable",
+ and "HSDir" flags just because they were going to vote against
+ "Running": if the consensus turns out to be that the router was
+ running, then the authority's vote should count. Patch from Peter
+ Retzlaff; closes issue 8712.
+
+ o Minor features (directory authorities, security, also in 0.2.6.9):
+ - The HSDir flag given by authorities now requires the Stable flag.
+ For the current network, this results in going from 2887 to 2806
+ HSDirs. Also, it makes it harder for an attacker to launch a sybil
+ attack by raising the effort for a relay to become Stable to
+ require at the very least 7 days, while maintaining the 96 hours
+ uptime requirement for HSDir. Implements ticket 8243.
+
+ o Minor features (DoS-resistance):
+ - Make it harder for attackers to overload hidden services with
+ introductions, by blocking multiple introduction requests on the
+ same circuit. Resolves ticket 15515.
+
+ o Minor features (geoIP):
+ - Update geoip and geoip6 to the October 9 2015 Maxmind GeoLite2
+ Country database.
+ - Update geoip and geoip6 to the September 3 2015 Maxmind GeoLite2
+ Country database.
+ - Update geoip to the April 8 2015 Maxmind GeoLite2 Country database.
+ - Update geoip6 to the April 8 2015 Maxmind GeoLite2
+ Country database.
+
+ o Minor features (geoip, also in 0.2.6.10):
+ - Update geoip to the June 3 2015 Maxmind GeoLite2 Country database.
+ - Update geoip6 to the June 3 2015 Maxmind GeoLite2 Country database.
+
+ o Minor features (hidden services):
+ - Add the new options "HiddenServiceMaxStreams" and
+ "HiddenServiceMaxStreamsCloseCircuit" to allow hidden services to
+ limit the maximum number of simultaneous streams per circuit, and
+ optionally tear down the circuit when the limit is exceeded. Part
+ of ticket 16052.
+ - Client now uses an introduction point failure cache to know when
+ to fetch or keep a descriptor in their cache. Previously, failures
+ were recorded implicitly, but not explicitly remembered. Closes
+ ticket 16389.
+ - Relays need to have the Fast flag to get the HSDir flag. As this
+ is being written, we'll go from 2745 HSDirs down to 2342, a ~14%
+ drop. This change should make some attacks against the hidden
+ service directory system harder. Fixes ticket 15963.
+ - Turn on hidden service statistics collection by setting the torrc
+ option HiddenServiceStatistics to "1" by default. (This keeps
+ track only of the fraction of traffic used by hidden services, and
+ the total number of hidden services in existence.) Closes
+ ticket 15254.
+
+ o Minor features (HS popularity countermeasure):
+ - To avoid leaking HS popularity, don't cycle the introduction point
+ when we've handled a fixed number of INTRODUCE2 cells but instead
+ cycle it when a random number of introductions is reached, thus
+ making it more difficult for an attacker to find out the amount of
+ clients that have used the introduction point for a specific HS.
+ Closes ticket 15745.
+
+ o Minor features (logging):
+ - Include the Tor version in all LD_BUG log messages, since people
+ tend to cut and paste those into the bugtracker. Implements
+ ticket 15026.
+
+ o Minor features (pluggable transports):
+ - When launching managed pluggable transports on Linux systems,
+ attempt to have the kernel deliver a SIGTERM on tor exit if the
+ pluggable transport process is still running. Resolves
+ ticket 15471.
+ - When launching managed pluggable transports, setup a valid open
+ stdin in the child process that can be used to detect if tor has
+ terminated. The "TOR_PT_EXIT_ON_STDIN_CLOSE" environment variable
+ can be used by implementations to detect this new behavior.
+ Resolves ticket 15435.
+
+ o Minor features (portability):
+ - Use C99 variadic macros when the compiler is not GCC. This avoids
+ failing compilations on MSVC, and fixes a log-file-based race
+ condition in our old workarounds. Original patch from Gisle Vanem.
+
+ o Minor features (testing):
+ - Add a test to verify that the compiler does not eliminate our
+ memwipe() implementation. Closes ticket 15377.
+ - Add make rule `check-changes` to verify the format of changes
+ files. Closes ticket 15180.
+ - Add unit tests for control_event_is_interesting(). Add a compile-
+ time check that the number of events doesn't exceed the capacity
+ of control_event_t.event_mask. Closes ticket 15431, checks for
+ bugs similar to 13085. Patch by "teor".
+ - Command-line argument tests moved to Stem. Resolves ticket 14806.
+ - Integrate the ntor, backtrace, and zero-length keys tests into the
+ automake test suite. Closes ticket 15344.
+ - Remove assertions during builds to determine Tor's test coverage.
+ We don't want to trigger these even in assertions, so including
+ them artificially makes our branch coverage look worse than it is.
+ This patch provides the new test-stem-full and coverage-html-full
+ configure options. Implements ticket 15400.
+
+ o Minor features (testing, authorities, documentation):
+ - New TestingDirAuthVote{Exit,Guard,HSDir}IsStrict flags to
+ explicitly manage consensus flags in testing networks. Patch by
+ "robgjansen", modified by "teor". Implements part of ticket 14882.
+
+ o Minor bug fixes (torrc exit policies):
+ - In each instance above, usage advice is provided to avoid the
+ message. Resolves ticket 16069. Patch by "teor". Fixes part of bug
+ 16069; bugfix on 0.2.4.7-alpha.
+ - In torrc, "accept6 *" and "reject6 *" ExitPolicy lines now only
+ produce IPv6 wildcard addresses. Previously they would produce
+ both IPv4 and IPv6 wildcard addresses. Patch by "teor". Fixes part
+ of bug 16069; bugfix on 0.2.4.7-alpha.
+ - When parsing torrc ExitPolicies, we now issue an info-level
+ message when expanding an "accept/reject *" line to include both
+ IPv4 and IPv6 wildcard addresses. Related to ticket 16069.
+ - When parsing torrc ExitPolicies, we now warn for a number of cases
+ where the user's intent is likely to differ from Tor's actual
+ behavior. These include: using an IPv4 address with an accept6 or
+ reject6 line; using "private" on an accept6 or reject6 line; and
+ including any ExitPolicy lines after accept *:* or reject *:*.
+ Related to ticket 16069.
+
+ o Minor bugfixes (authority):
+ - Don't assign "HSDir" to a router if it isn't Valid and Running.
+ Fixes bug 16524; bugfix on 0.2.7.2-alpha.
+ - Downgrade log messages about Ed25519 key issues if they are in old
+ cached router descriptors. Fixes part of bug 16286; bugfix
+ on 0.2.7.2-alpha.
+ - When we find an Ed25519 key issue in a cached descriptor, stop
+ saying the descriptor was just "uploaded". Fixes another part of
+ bug 16286; bugfix on 0.2.7.2-alpha.
+
+ o Minor bugfixes (build):
+ - Improve out-of-tree builds by making non-standard rules work and
+ clean up additional files and directories. Fixes bug 15053; bugfix
+ on 0.2.7.0-alpha.
+
+ o Minor bugfixes (command-line interface):
+ - When "--quiet" is provided along with "--validate-config", do not
+ write anything to stdout on success. Fixes bug 14994; bugfix
+ on 0.2.3.3-alpha.
+ - When complaining about bad arguments to "--dump-config", use
+ stderr, not stdout.
+
+ o Minor bugfixes (compilation):
+ - Fix an integer overflow warning in test_crypto_slow.c. Fixes bug
+ 17251; bugfix on 0.2.7.2-alpha.
+ - Fix compilation of sandbox.c with musl-libc. Fixes bug 17347;
+ bugfix on 0.2.5.1-alpha. Patch from 'jamestk'.
+ - Repair compilation with the most recent (unreleased, alpha)
+ vesions of OpenSSL 1.1. Fixes part of ticket 17237.
+
+ o Minor bugfixes (compilation, also in 0.2.6.9):
+ - Build with --enable-systemd correctly when libsystemd is
+ installed, but systemd is not. Fixes bug 16164; bugfix on
+ 0.2.6.3-alpha. Patch from Peter Palfrader.
+
+ o Minor bugfixes (configuration, unit tests):
+ - Only add the default fallback directories when the DirAuthorities,
+ AlternateDirAuthority, and FallbackDir directory config options
+ are set to their defaults. The default fallback directory list is
+ currently empty, this fix will only change tor's behavior when it
+ has default fallback directories. Includes unit tests for
+ consider_adding_dir_servers(). Fixes bug 15642; bugfix on
+ 90f6071d8dc0 in 0.2.4.7-alpha. Patch by "teor".
+
+ o Minor bugfixes (control port):
+ - Repair a warning and a spurious result when getting the maximum
+ number of file descriptors from the controller. Fixes bug 16697;
+ bugfix on 0.2.7.2-alpha.
+
+ o Minor bugfixes (controller):
+ - Add the descriptor ID in each HS_DESC control event. It was
+ missing, but specified in control-spec.txt. Fixes bug 15881;
+ bugfix on 0.2.5.2-alpha.
+
+ o Minor bugfixes (correctness):
+ - For correctness, avoid modifying a constant string in
+ handle_control_postdescriptor. Fixes bug 15546; bugfix
+ on 0.1.1.16-rc.
+ - Remove side-effects from tor_assert() calls. This was harmless,
+ because we never disable assertions, but it is bad style and
+ unnecessary. Fixes bug 15211; bugfix on 0.2.5.5, 0.2.2.36,
+ and 0.2.0.10.
+ - When calling channel_free_list(), avoid calling smartlist_remove()
+ while inside a FOREACH loop. This partially reverts commit
+ 17356fe7fd96af where the correct SMARTLIST_DEL_CURRENT was
+ incorrectly removed. Fixes bug 16924; bugfix on 0.2.4.4-alpha.
+
+ o Minor bugfixes (crypto error-handling, also in 0.2.6.10):
+ - Check for failures from crypto_early_init, and refuse to continue.
+ A previous typo meant that we could keep going with an
+ uninitialized crypto library, and would have OpenSSL initialize
+ its own PRNG. Fixes bug 16360; bugfix on 0.2.5.2-alpha, introduced
+ when implementing ticket 4900. Patch by "teor".
+
+ o Minor bugfixes (documentation):
+ - Advise users on how to configure separate IPv4 and IPv6 exit
+ policies in the manpage and sample torrcs. Related to ticket 16069.
+ - Fix an error in the manual page and comments for
+ TestingDirAuthVoteHSDir[IsStrict], which suggested that a HSDir
+ required "ORPort connectivity". While this is true, it is in no
+ way unique to the HSDir flag. Of all the flags, only HSDirs need a
+ DirPort configured in order for the authorities to assign that
+ particular flag. Patch by "teor". Fixed as part of 14882; bugfix
+ on 0.2.6.3-alpha.
+ - Fix the usage message of tor-resolve(1) so that it no longer lists
+ the removed -F option. Fixes bug 16913; bugfix on 0.2.2.28-beta.
+
+ o Minor bugfixes (Ed25519):
+ - Fix a memory leak when reading router descriptors with expired
+ Ed25519 certificates. Fixes bug 16539; bugfix on 0.2.7.2-alpha.
+
+ o Minor bugfixes (hidden service):
+ - Fix an out-of-bounds read when parsing invalid INTRODUCE2 cells on
+ a client authorized hidden service. Fixes bug 15823; bugfix
+ on 0.2.1.6-alpha.
+ - Remove an extraneous newline character from the end of hidden
+ service descriptors. Fixes bug 15296; bugfix on 0.2.0.10-alpha.
+
+ o Minor bugfixes (hidden services):
+ - Avoid crashing with a double-free bug when we create an ephemeral
+ hidden service but adding it fails for some reason. Fixes bug
+ 16228; bugfix on 0.2.7.1-alpha.
+ - Fix a crash when reloading configuration while at least one
+ configured and one ephemeral hidden service exists. Fixes bug
+ 16060; bugfix on 0.2.7.1-alpha.
+
+ o Minor bugfixes (interface):
+ - Print usage information for --dump-config when it is used without
+ an argument. Also, fix the error message to use different wording
+ and add newline at the end. Fixes bug 15541; bugfix
+ on 0.2.5.1-alpha.
+
+ o Minor bugfixes (Linux seccomp2 sandbox):
+ - Use the sandbox in tor_open_cloexec whether or not O_CLOEXEC is
+ defined. Patch by "teor". Fixes bug 16515; bugfix on 0.2.3.1-alpha.
+ - Allow bridge authorities to run correctly under the seccomp2
+ sandbox. Fixes bug 16964; bugfix on 0.2.5.1-alpha.
+ - Allow routers with ed25519 keys to run correctly under the
+ seccomp2 sandbox. Fixes bug 16965; bugfix on 0.2.7.2-alpha.
+
+ o Minor bugfixes (Linux seccomp2 sandbox, also in 0.2.6.10):
+ - Allow pipe() and pipe2() syscalls in the seccomp2 sandbox: we need
+ these when eventfd2() support is missing. Fixes bug 16363; bugfix
+ on 0.2.6.3-alpha. Patch from "teor".
+
+ o Minor bugfixes (Linux seccomp2 sandbox, also in 0.2.6.9):
+ - Allow systemd connections to work with the Linux seccomp2 sandbox
+ code. Fixes bug 16212; bugfix on 0.2.6.2-alpha. Patch by
+ Peter Palfrader.
+ - Fix sandboxing to work when running as a relay, by allowing the
+ renaming of secret_id_key, and allowing the eventfd2 and futex
+ syscalls. Fixes bug 16244; bugfix on 0.2.6.1-alpha. Patch by
+ Peter Palfrader.
+
+ o Minor bugfixes (logs):
+ - When building Tor under Clang, do not include an extra set of
+ parentheses in log messages that include function names. Fixes bug
+ 15269; bugfix on every released version of Tor when compiled with
+ recent enough Clang.
+
+ o Minor bugfixes (network):
+ - When attempting to use fallback technique for network interface
+ lookup, disregard loopback and multicast addresses since they are
+ unsuitable for public communications.
+
+ o Minor bugfixes (open file limit):
+ - Fix set_max_file_descriptors() to set by default the max open file
+ limit to the current limit when setrlimit() fails. Fixes bug
+ 16274; bugfix on tor- 0.2.0.10-alpha. Patch by dgoulet.
+
+ o Minor bugfixes (portability):
+ - Check correctly for Windows socket errors in the workqueue
+ backend. Fixes bug 16741; bugfix on 0.2.6.3-alpha.
+ - Fix the behavior of crypto_rand_time_range() when told to consider
+ times before 1970. (These times were possible when running in a
+ simulated network environment where time()'s output starts at
+ zero.) Fixes bug 16980; bugfix on 0.2.7.1-alpha.
+ - Restore correct operation of TLS client-cipher detection on
+ OpenSSL 1.1. Fixes bug 14047; bugfix on 0.2.7.2-alpha.
+ - Try harder to normalize the exit status of the Tor process to the
+ standard-provided range. Fixes bug 16975; bugfix on every version
+ of Tor ever.
+ - Use libexecinfo on FreeBSD to enable backtrace support. Fixes part
+ of bug 17151; bugfix on 0.2.5.2-alpha. Patch from Marcin Cieślak.
+
+ o Minor bugfixes (relay):
+ - Ensure that worker threads actually exit when a fatal error or
+ shutdown is indicated. This fix doesn't currently affect the
+ behavior of Tor, because Tor workers never indicates fatal error
+ or shutdown except in the unit tests. Fixes bug 16868; bugfix
+ on 0.2.6.3-alpha.
+ - Fix a rarely-encountered memory leak when failing to initialize
+ the thread pool. Fixes bug 16631; bugfix on 0.2.6.3-alpha. Patch
+ from "cypherpunks".
+ - Unblock threads before releasing the work queue mutex to ensure
+ predictable scheduling behavior. Fixes bug 16644; bugfix
+ on 0.2.6.3-alpha.
+
+ o Minor bugfixes (sandbox):
+ - Add the "hidserv-stats" filename to our sandbox filter for the
+ HiddenServiceStatistics option to work properly. Fixes bug 17354;
+ bugfix on tor-0.2.6.2-alpha. Patch from David Goulet.
+
+ o Minor bugfixes (security, exit policies):
+ - ExitPolicyRejectPrivate now also rejects the relay's published
+ IPv6 address (if any), and any publicly routable IPv4 or IPv6
+ addresses on any local interfaces. ticket 17027. Patch by "teor".
+ Fixes bug 17027; bugfix on 0.2.0.11-alpha.
+
+ o Minor bugfixes (statistics):
+ - Disregard the ConnDirectionStatistics torrc options when Tor is
+ not a relay since in that mode of operation no sensible data is
+ being collected and because Tor might run into measurement hiccups
+ when running as a client for some time, then becoming a relay.
+ Fixes bug 15604; bugfix on 0.2.2.35.
+
+ o Minor bugfixes (systemd):
+ - Fix an accidental formatting error that broke the systemd
+ configuration file. Fixes bug 16152; bugfix on 0.2.7.1-alpha.
+ - Tor's systemd unit file no longer contains extraneous spaces.
+ These spaces would sometimes confuse tools like deb-systemd-
+ helper. Fixes bug 16162; bugfix on 0.2.5.5-alpha.
+
+ o Minor bugfixes (test networks):
+ - When self-testing reachability, use ExtendAllowPrivateAddresses to
+ determine if local/private addresses imply reachability. The
+ previous fix used TestingTorNetwork, which implies
+ ExtendAllowPrivateAddresses, but this excluded rare configurations
+ where ExtendAllowPrivateAddresses is set but TestingTorNetwork is
+ not. Fixes bug 15771; bugfix on 0.2.6.1-alpha. Patch by "teor",
+ issue discovered by CJ Ess.
+
+ o Minor bugfixes (testing):
+ - Add unit tests for get_interface_address* failure cases. Fixes bug
+ 17173; bugfix on 0.2.7.3-rc. Patch by fk/teor.
+ - Check for matching value in server response in ntor_ref.py. Fixes
+ bug 15591; bugfix on 0.2.4.8-alpha. Reported and fixed
+ by "joelanders".
+ - Fix breakage when running 'make check' with BSD make. Fixes bug
+ 17154; bugfix on 0.2.7.3-rc. Patch by Marcin Cieślak.
+ - Make the get_ifaddrs_* unit tests more tolerant of different
+ network configurations. (Don't assume every test box has an IPv4
+ address, and don't assume every test box has a non-localhost
+ address.) Fixes bug 17255; bugfix on 0.2.7.3-rc. Patch by "teor".
+ - Set the severity correctly when testing
+ get_interface_addresses_ifaddrs() and
+ get_interface_addresses_win32(), so that the tests fail gracefully
+ instead of triggering an assertion. Fixes bug 15759; bugfix on
+ 0.2.6.3-alpha. Reported by Nicolas Derive.
+ - Skip backtrace tests when backtrace support is not compiled in.
+ Fixes part of bug 17151; bugfix on 0.2.7.1-alpha. Patch from
+ Marcin Cieślak.
+
+ o Minor bugfixes (tests):
+ - Use the configured Python executable when running test-stem-full.
+ Fixes bug 16470; bugfix on 0.2.7.1-alpha.
+
+ o Minor bugfixes (tests, also in 0.2.6.9):
+ - Fix a crash in the unit tests when built with MSVC2013. Fixes bug
+ 16030; bugfix on 0.2.6.2-alpha. Patch from "NewEraCracker".
+
+ o Minor bugfixes (threads, comments):
+ - Always initialize return value in compute_desc_id in rendcommon.c
+ Patch by "teor". Fixes part of bug 16115; bugfix on 0.2.7.1-alpha.
+ - Check for NULL values in getinfo_helper_onions(). Patch by "teor".
+ Fixes part of bug 16115; bugfix on 0.2.7.1-alpha.
+ - Remove undefined directive-in-macro in test_util_writepid clang
+ 3.7 complains that using a preprocessor directive inside a macro
+ invocation in test_util_writepid in test_util.c is undefined.
+ Patch by "teor". Fixes part of bug 16115; bugfix on 0.2.7.1-alpha.
+
+ o Code simplification and refactoring:
+ - Change the function that's called when we need to retry all
+ downloads so that it only reschedules the downloads to happen
+ immediately, rather than launching them all at once itself. This
+ further simplifies Tor's callgraph.
+ - Define WINVER and _WIN32_WINNT centrally, in orconfig.h, in order
+ to ensure they remain consistent and visible everywhere.
+ - Move some format-parsing functions out of crypto.c and
+ crypto_curve25519.c into crypto_format.c and/or util_format.c.
+ - Move the client-only parts of init_keys() into a separate
+ function. Closes ticket 16763.
+ - Move the hacky fallback code out of get_interface_address6() into
+ separate function and get it covered with unit-tests. Resolves
+ ticket 14710.
+ - Refactor hidden service client-side cache lookup to intelligently
+ report its various failure cases, and disentangle failure cases
+ involving a lack of introduction points. Closes ticket 14391.
+ - Remove some vestigial workarounds for the MSVC6 compiler. We
+ haven't supported that in ages.
+ - Remove the unused "nulterminate" argument from buf_pullup().
+ - Simplify the microdesc_free() implementation so that it no longer
+ appears (to code analysis tools) to potentially invoke a huge
+ suite of other microdesc functions.
+ - Simply the control graph further by deferring the inner body of
+ directory_all_unreachable() into a callback. Closes ticket 16762.
+ - The link authentication code has been refactored for better
+ testability and reliability. It now uses code generated with the
+ "trunnel" binary encoding generator, to reduce the risk of bugs
+ due to programmer error. Done as part of ticket 12498.
+ - Treat the loss of an owning controller as equivalent to a SIGTERM
+ signal. This removes a tiny amount of duplicated code, and
+ simplifies our callgraph. Closes ticket 16788.
+ - Use our own Base64 encoder instead of OpenSSL's, to allow more
+ control over the output. Part of ticket 15652.
+ - When generating an event to send to the controller, we no longer
+ put the event over the network immediately. Instead, we queue
+ these events, and use a Libevent callback to deliver them. This
+ change simplifies Tor's callgraph by reducing the number of
+ functions from which all other Tor functions are reachable. Closes
+ ticket 16695.
+ - Wrap Windows-only C files inside '#ifdef _WIN32' so that tools
+ that try to scan or compile every file on Unix won't decide that
+ they are broken.
+
+ o Documentation:
+ - Fix capitalization of SOCKS in sample torrc. Closes ticket 15609.
+ - Improve the descriptions of statistics-related torrc options in
+ the manpage to describe rationale and possible uses cases. Fixes
+ issue 15550.
+ - Improve the layout and formatting of ./configure --help messages.
+ Closes ticket 15024. Patch from "cypherpunks".
+ - Include a specific and (hopefully) accurate documentation of the
+ torrc file's meta-format in doc/torrc_format.txt. This is mainly
+ of interest to people writing programs to parse or generate torrc
+ files. This document is not a commitment to long-term
+ compatibility; some aspects of the current format are a bit
+ ridiculous. Closes ticket 2325.
+ - Include the TUNING document in our source tarball. It is referred
+ to in the ChangeLog and an error message. Fixes bug 16929; bugfix
+ on 0.2.6.1-alpha.
+ - Note that HiddenServicePorts can take a unix domain socket. Closes
+ ticket 17364.
+ - Recommend a 40 GB example AccountingMax in torrc.sample rather
+ than a 4 GB max. Closes ticket 16742.
+ - Standardize on the term "server descriptor" in the manual page.
+ Previously, we had used "router descriptor", "server descriptor",
+ and "relay descriptor" interchangeably. Part of ticket 14987.
+
+ o New system requirements:
+ - Tor no longer includes workarounds to support Libevent versions
+ before 1.3e. Libevent 2.0 or later is recommended. Closes
+ ticket 15248.
+
+ o Removed code:
+ - Remove `USE_OPENSSL_BASE64` and the corresponding fallback code
+ and always use the internal Base64 decoder. The internal decoder
+ has been part of tor since tor-0.2.0.10-alpha, and no one should
+ be using the OpenSSL one. Part of ticket 15652.
+ - Remove the 'tor_strclear()' function; use memwipe() instead.
+ Closes ticket 14922.
+ - Remove the code that would try to aggressively flush controller
+ connections while writing to them. This code was introduced in
+ 0.1.2.7-alpha, in order to keep output buffers from exceeding
+ their limits. But there is no longer a maximum output buffer size,
+ and flushing data in this way caused some undesirable recursions
+ in our call graph. Closes ticket 16480.
+ - The internal pure-C tor-fw-helper tool is now removed from the Tor
+ distribution, in favor of the pure-Go clone available from
+ https://gitweb.torproject.org/tor-fw-helper.git/ . The libraries
+ used by the C tor-fw-helper are not, in our opinion, very
+ confidence- inspiring in their secure-programming techniques.
+ Closes ticket 13338.
+
+ o Removed features:
+ - Remove the (seldom-used) DynamicDHGroups feature. For anti-
+ fingerprinting we now recommend pluggable transports; for forward-
+ secrecy in TLS, we now use the P-256 group. Closes ticket 13736.
+ - Remove the HidServDirectoryV2 option. Now all relays offer to
+ store hidden service descriptors. Related to 16543.
+ - Remove the VoteOnHidServDirectoriesV2 option, since all
+ authorities have long set it to 1. Closes ticket 16543.
+ - Remove the undocumented "--digests" command-line option. It
+ complicated our build process, caused subtle build issues on
+ multiple platforms, and is now redundant since we started
+ including git version identifiers. Closes ticket 14742.
+ - Tor no longer contains checks for ancient directory cache versions
+ that didn't know about microdescriptors.
+ - Tor no longer contains workarounds for stat files generated by
+ super-old versions of Tor that didn't choose guards sensibly.
+ - Tor no longer supports copies of OpenSSL that are missing support
+ for Elliptic Curve Cryptography. (We began using ECC when
+ available in 0.2.4.8-alpha, for more safe and efficient key
+ negotiation.) In particular, support for at least one of P256 or
+ P224 is now required, with manual configuration needed if only
+ P224 is available. Resolves ticket 16140.
+ - Tor no longer supports versions of OpenSSL before 1.0. (If you are
+ on an operating system that has not upgraded to OpenSSL 1.0 or
+ later, and you compile Tor from source, you will need to install a
+ more recent OpenSSL to link Tor against.) These versions of
+ OpenSSL are still supported by the OpenSSL, but the numerous
+ cryptographic improvements in later OpenSSL releases makes them a
+ clear choice. Resolves ticket 16034.
+
+ o Testing:
+ - Add a new set of callgraph analysis scripts that use clang to
+ produce a list of which Tor functions are reachable from which
+ other Tor functions. We're planning to use these to help simplify
+ our code structure by identifying illogical dependencies.
+ - Add new 'test-full' and 'test-full-online' targets to run all
+ tests, including integration tests with stem and chutney.
+ - Autodetect CHUTNEY_PATH if the chutney and Tor sources are side-
+ by-side in the same parent directory. Closes ticket 16903. Patch
+ by "teor".
+ - Document use of coverity, clang static analyzer, and clang dynamic
+ undefined behavior and address sanitizers in doc/HACKING. Include
+ detailed usage instructions in the blacklist. Patch by "teor".
+ Closes ticket 15817.
+ - Make "bridges+hs" the default test network. This tests almost all
+ tor functionality during make test-network, while allowing tests
+ to succeed on non-IPv6 systems. Requires chutney commit 396da92 in
+ test-network-bridges-hs. Closes tickets 16945 (tor) and 16946
+ (chutney). Patches by "teor".
+ - Make the test-workqueue test work on Windows by initializing the
+ network before we begin.
+ - New make target (make test-network-all) to run multiple applicable
+ chutney test cases. Patch from Teor; closes 16953.
+ - Now that OpenSSL has its own scrypt implementation, add an unit
+ test that checks for interoperability between libscrypt_scrypt()
+ and OpenSSL's EVP_PBE_scrypt() so that we could not use libscrypt
+ and rely on EVP_PBE_scrypt() whenever possible. Resolves
+ ticket 16189.
+ - The link authentication protocol code now has extensive tests.
+ - The relay descriptor signature testing code now has
+ extensive tests.
+ - The test_workqueue program now runs faster, and is enabled by
+ default as a part of "make check".
+ - Unit test dns_resolve(), dns_clip_ttl() and dns_get_expiry_ttl()
+ functions in dns.c. Implements a portion of ticket 16831.
+ - Use environment variables rather than autoconf substitutions to
+ send variables from the build system to the test scripts. This
+ change should be easier to maintain, and cause 'make distcheck' to
+ work better than before. Fixes bug 17148.
+ - When building Tor with testing coverage enabled, run Chutney tests
+ (if any) using the 'tor-cov' coverage binary.
+ - When running test-network or test-stem, check for the absence of
+ stem/chutney before doing any build operations.
+
+
+
+
Changes in version 0.2.6.10 - 2015-07-12
Tor version 0.2.6.10 fixes some significant stability and hidden
service client bugs, bulletproofs the cryptography init process, and
1
0

[tor/release-0.2.7] Remove all bugfix-on-0.2.7.x items from ReleaseNotes
by nickm@torproject.org 05 Nov '15
by nickm@torproject.org 05 Nov '15
05 Nov '15
commit 6292a3fcf48ec5b177cee8cec1b542661ae2bb54
Author: Nick Mathewson <nickm(a)torproject.org>
Date: Thu Nov 5 09:29:27 2015 -0500
Remove all bugfix-on-0.2.7.x items from ReleaseNotes
---
ReleaseNotes | 90 ++--------------------------------------------------------
1 file changed, 2 insertions(+), 88 deletions(-)
diff --git a/ReleaseNotes b/ReleaseNotes
index b84c4da..131d015 100644
--- a/ReleaseNotes
+++ b/ReleaseNotes
@@ -4,7 +4,7 @@ of Tor. If you want to see more detailed descriptions of the changes in
each development snapshot, see the ChangeLog file.
Changes in version 0.2.7.5- 2015-11-??
- XXXX WRITE A BLURB
+ XXXX WRITE A BLURB XXXX
o Major features (controller):
- Add the ADD_ONION and DEL_ONION commands that allow the creation
@@ -117,10 +117,6 @@ Changes in version 0.2.7.5- 2015-11-??
connection was initialized. Fixes bug 16247; bugfix on
0.2.6.3-alpha. Patch by "jojelino".
- o Major bugfixes (correctness):
- - Fix a use-after-free bug in validate_intro_point_failure(). Fixes
- bug 17401; bugfix on 0.2.7.3-rc.
-
o Major bugfixes (hidden service clients, stability, also in 0.2.6.10):
- Stop refusing to store updated hidden service descriptors on a
client. This reverts commit 9407040c59218 (which indeed fixed bug
@@ -147,10 +143,6 @@ Changes in version 0.2.7.5- 2015-11-??
o Major bugfixes (memory leaks):
- Fix a memory leak in ed25519 batch signature checking. Fixes bug
17398; bugfix on 0.2.6.1-alpha.
- - Fix a memory leak in rend_cache_failure_entry_free(). Fixes bug
- 17402; bugfix on 0.2.7.3-rc.
- - Fix a memory leak when reading an expired signing key from disk.
- Fixes bug 17403; bugfix on 0.2.7.2-rc.
o Major bugfixes (open file limit):
- The open file limit wasn't checked before calling
@@ -159,12 +151,6 @@ Changes in version 0.2.7.5- 2015-11-??
file limit just before, and if the max has been reached, return an
error. Fixes bug 16288; bugfix on 0.1.1.1-alpha.
- o Major bugfixes (relay, Ed25519):
- - Avoid crashing on 'tor --keygen'. Fixes bug 16679; bugfix on
- 0.2.7.2-alpha. Reported by "s7r".
- - Improve handling of expired signing keys with offline master keys.
- Fixes bug 16685; bugfix on 0.2.7.2-alpha. Reported by "s7r".
-
o Major bugfixes (security, correctness):
- Fix an error that could cause us to read 4 bytes before the
beginning of an openssl string. This bug could be used to cause
@@ -218,9 +204,6 @@ Changes in version 0.2.7.5- 2015-11-??
as torrc option. Resolves issue 14018.
o Minor features (compilation):
- - Fail during configure if we're trying to build against an OpenSSL
- built without ECC support. Fixes bug 17109, bugfix on 0.2.7.1-alpha
- which started requiring ECC.
- Give a warning as early as possible when trying to build with an
unsupported OpenSSL version. Closes ticket 16901.
@@ -344,7 +327,7 @@ Changes in version 0.2.7.5- 2015-11-??
explicitly manage consensus flags in testing networks. Patch by
"robgjansen", modified by "teor". Implements part of ticket 14882.
- o Minor bug fixes (torrc exit policies):
+ o Minor bugfixes (torrc exit policies):
- In each instance above, usage advice is provided to avoid the
message. Resolves ticket 16069. Patch by "teor". Fixes part of bug
16069; bugfix on 0.2.4.7-alpha.
@@ -362,21 +345,6 @@ Changes in version 0.2.7.5- 2015-11-??
including any ExitPolicy lines after accept *:* or reject *:*.
Related to ticket 16069.
- o Minor bugfixes (authority):
- - Don't assign "HSDir" to a router if it isn't Valid and Running.
- Fixes bug 16524; bugfix on 0.2.7.2-alpha.
- - Downgrade log messages about Ed25519 key issues if they are in old
- cached router descriptors. Fixes part of bug 16286; bugfix
- on 0.2.7.2-alpha.
- - When we find an Ed25519 key issue in a cached descriptor, stop
- saying the descriptor was just "uploaded". Fixes another part of
- bug 16286; bugfix on 0.2.7.2-alpha.
-
- o Minor bugfixes (build):
- - Improve out-of-tree builds by making non-standard rules work and
- clean up additional files and directories. Fixes bug 15053; bugfix
- on 0.2.7.0-alpha.
-
o Minor bugfixes (command-line interface):
- When "--quiet" is provided along with "--validate-config", do not
write anything to stdout on success. Fixes bug 14994; bugfix
@@ -385,8 +353,6 @@ Changes in version 0.2.7.5- 2015-11-??
stderr, not stdout.
o Minor bugfixes (compilation):
- - Fix an integer overflow warning in test_crypto_slow.c. Fixes bug
- 17251; bugfix on 0.2.7.2-alpha.
- Fix compilation of sandbox.c with musl-libc. Fixes bug 17347;
bugfix on 0.2.5.1-alpha. Patch from 'jamestk'.
- Repair compilation with the most recent (unreleased, alpha)
@@ -406,11 +372,6 @@ Changes in version 0.2.7.5- 2015-11-??
consider_adding_dir_servers(). Fixes bug 15642; bugfix on
90f6071d8dc0 in 0.2.4.7-alpha. Patch by "teor".
- o Minor bugfixes (control port):
- - Repair a warning and a spurious result when getting the maximum
- number of file descriptors from the controller. Fixes bug 16697;
- bugfix on 0.2.7.2-alpha.
-
o Minor bugfixes (controller):
- Add the descriptor ID in each HS_DESC control event. It was
missing, but specified in control-spec.txt. Fixes bug 15881;
@@ -449,10 +410,6 @@ Changes in version 0.2.7.5- 2015-11-??
- Fix the usage message of tor-resolve(1) so that it no longer lists
the removed -F option. Fixes bug 16913; bugfix on 0.2.2.28-beta.
- o Minor bugfixes (Ed25519):
- - Fix a memory leak when reading router descriptors with expired
- Ed25519 certificates. Fixes bug 16539; bugfix on 0.2.7.2-alpha.
-
o Minor bugfixes (hidden service):
- Fix an out-of-bounds read when parsing invalid INTRODUCE2 cells on
a client authorized hidden service. Fixes bug 15823; bugfix
@@ -460,14 +417,6 @@ Changes in version 0.2.7.5- 2015-11-??
- Remove an extraneous newline character from the end of hidden
service descriptors. Fixes bug 15296; bugfix on 0.2.0.10-alpha.
- o Minor bugfixes (hidden services):
- - Avoid crashing with a double-free bug when we create an ephemeral
- hidden service but adding it fails for some reason. Fixes bug
- 16228; bugfix on 0.2.7.1-alpha.
- - Fix a crash when reloading configuration while at least one
- configured and one ephemeral hidden service exists. Fixes bug
- 16060; bugfix on 0.2.7.1-alpha.
-
o Minor bugfixes (interface):
- Print usage information for --dump-config when it is used without
an argument. Also, fix the error message to use different wording
@@ -479,8 +428,6 @@ Changes in version 0.2.7.5- 2015-11-??
defined. Patch by "teor". Fixes bug 16515; bugfix on 0.2.3.1-alpha.
- Allow bridge authorities to run correctly under the seccomp2
sandbox. Fixes bug 16964; bugfix on 0.2.5.1-alpha.
- - Allow routers with ed25519 keys to run correctly under the
- seccomp2 sandbox. Fixes bug 16965; bugfix on 0.2.7.2-alpha.
o Minor bugfixes (Linux seccomp2 sandbox, also in 0.2.6.10):
- Allow pipe() and pipe2() syscalls in the seccomp2 sandbox: we need
@@ -515,12 +462,6 @@ Changes in version 0.2.7.5- 2015-11-??
o Minor bugfixes (portability):
- Check correctly for Windows socket errors in the workqueue
backend. Fixes bug 16741; bugfix on 0.2.6.3-alpha.
- - Fix the behavior of crypto_rand_time_range() when told to consider
- times before 1970. (These times were possible when running in a
- simulated network environment where time()'s output starts at
- zero.) Fixes bug 16980; bugfix on 0.2.7.1-alpha.
- - Restore correct operation of TLS client-cipher detection on
- OpenSSL 1.1. Fixes bug 14047; bugfix on 0.2.7.2-alpha.
- Try harder to normalize the exit status of the Tor process to the
standard-provided range. Fixes bug 16975; bugfix on every version
of Tor ever.
@@ -559,8 +500,6 @@ Changes in version 0.2.7.5- 2015-11-??
Fixes bug 15604; bugfix on 0.2.2.35.
o Minor bugfixes (systemd):
- - Fix an accidental formatting error that broke the systemd
- configuration file. Fixes bug 16152; bugfix on 0.2.7.1-alpha.
- Tor's systemd unit file no longer contains extraneous spaces.
These spaces would sometimes confuse tools like deb-systemd-
helper. Fixes bug 16162; bugfix on 0.2.5.5-alpha.
@@ -575,44 +514,19 @@ Changes in version 0.2.7.5- 2015-11-??
issue discovered by CJ Ess.
o Minor bugfixes (testing):
- - Add unit tests for get_interface_address* failure cases. Fixes bug
- 17173; bugfix on 0.2.7.3-rc. Patch by fk/teor.
- Check for matching value in server response in ntor_ref.py. Fixes
bug 15591; bugfix on 0.2.4.8-alpha. Reported and fixed
by "joelanders".
- - Fix breakage when running 'make check' with BSD make. Fixes bug
- 17154; bugfix on 0.2.7.3-rc. Patch by Marcin Cieślak.
- - Make the get_ifaddrs_* unit tests more tolerant of different
- network configurations. (Don't assume every test box has an IPv4
- address, and don't assume every test box has a non-localhost
- address.) Fixes bug 17255; bugfix on 0.2.7.3-rc. Patch by "teor".
- Set the severity correctly when testing
get_interface_addresses_ifaddrs() and
get_interface_addresses_win32(), so that the tests fail gracefully
instead of triggering an assertion. Fixes bug 15759; bugfix on
0.2.6.3-alpha. Reported by Nicolas Derive.
- - Skip backtrace tests when backtrace support is not compiled in.
- Fixes part of bug 17151; bugfix on 0.2.7.1-alpha. Patch from
- Marcin Cieślak.
-
- o Minor bugfixes (tests):
- - Use the configured Python executable when running test-stem-full.
- Fixes bug 16470; bugfix on 0.2.7.1-alpha.
o Minor bugfixes (tests, also in 0.2.6.9):
- Fix a crash in the unit tests when built with MSVC2013. Fixes bug
16030; bugfix on 0.2.6.2-alpha. Patch from "NewEraCracker".
- o Minor bugfixes (threads, comments):
- - Always initialize return value in compute_desc_id in rendcommon.c
- Patch by "teor". Fixes part of bug 16115; bugfix on 0.2.7.1-alpha.
- - Check for NULL values in getinfo_helper_onions(). Patch by "teor".
- Fixes part of bug 16115; bugfix on 0.2.7.1-alpha.
- - Remove undefined directive-in-macro in test_util_writepid clang
- 3.7 complains that using a preprocessor directive inside a macro
- invocation in test_util_writepid in test_util.c is undefined.
- Patch by "teor". Fixes part of bug 16115; bugfix on 0.2.7.1-alpha.
-
o Code simplification and refactoring:
- Change the function that's called when we need to retry all
downloads so that it only reschedules the downloads to happen
1
0

[tor/release-0.2.7] Re-order and condense some ReleaseNotes items
by nickm@torproject.org 05 Nov '15
by nickm@torproject.org 05 Nov '15
05 Nov '15
commit 99d39e937e43ddc79c0a089de2c3e436e055461b
Author: Nick Mathewson <nickm(a)torproject.org>
Date: Thu Nov 5 09:39:44 2015 -0500
Re-order and condense some ReleaseNotes items
---
ReleaseNotes | 243 ++++++++++++++++++++++++----------------------------------
1 file changed, 100 insertions(+), 143 deletions(-)
diff --git a/ReleaseNotes b/ReleaseNotes
index 131d015..029dd61 100644
--- a/ReleaseNotes
+++ b/ReleaseNotes
@@ -6,6 +6,24 @@ each development snapshot, see the ChangeLog file.
Changes in version 0.2.7.5- 2015-11-??
XXXX WRITE A BLURB XXXX
+ o New system requirements:
+ - Tor no longer includes workarounds to support Libevent versions
+ before 1.3e. Libevent 2.0 or later is recommended. Closes
+ ticket 15248.
+ - Tor no longer supports copies of OpenSSL that are missing support
+ for Elliptic Curve Cryptography. (We began using ECC when
+ available in 0.2.4.8-alpha, for more safe and efficient key
+ negotiation.) In particular, support for at least one of P256 or
+ P224 is now required, with manual configuration needed if only
+ P224 is available. Resolves ticket 16140.
+ - Tor no longer supports versions of OpenSSL before 1.0. (If you are
+ on an operating system that has not upgraded to OpenSSL 1.0 or
+ later, and you compile Tor from source, you will need to install a
+ more recent OpenSSL to link Tor against.) These versions of
+ OpenSSL are still supported by the OpenSSL, but the numerous
+ cryptographic improvements in later OpenSSL releases makes them a
+ clear choice. Resolves ticket 16034.
+
o Major features (controller):
- Add the ADD_ONION and DEL_ONION commands that allow the creation
and management of hidden services via the controller. Closes
@@ -36,24 +54,43 @@ Changes in version 0.2.7.5- 2015-11-??
vary freely. Implements part of ticket 12498.
- Microdescriptors now include Ed25519 identity keys. Implements
part of ticket 12498.
+ - Add a --newpass option to allow changing or removing the
+ passphrase of an encrypted key with tor --keygen. Implements part
+ of ticket 16769.
+ - Add a new OfflineMasterKey option to tell Tor never to try loading
+ or generating a secret Ed25519 identity key. You can use this in
+ combination with tor --keygen to manage offline and/or encrypted
+ Ed25519 keys. Implements ticket 16944.
+ - On receiving a HUP signal, check to see whether the Ed25519
+ signing key has changed, and reload it if so. Closes ticket 16790.
+ - Significant usability improvements for Ed25519 key management. Log
+ messages are better, and the code can recover from far more
+ failure conditions. Thanks to "s7r" for reporting and diagnosing
+ so many of these!
- o Major features (Ed25519 keys, keypinning):
- - The key-pinning option on directory authorities is now advisory-
- only by default. In a future version, or when the AuthDirPinKeys
- option is set, pins are enforced again. Disabling key-pinning
- seemed like a good idea so that we can survive the fallout of any
- usability problems associated with Ed25519 keys. Closes
- ticket 17135.
-
- o Major features (Ed25519 performance):
+ o Major features (ECC performance):
- Improve the runtime speed of Ed25519 signature verification by
using Ed25519-donna's batch verification support. Implements
ticket 16533.
- Improve the speed of Ed25519 operations and Curve25519 keypair
generation when built targeting 32 bit x86 platforms with SSE2
available. Implements ticket 16535.
+ - Improve the runtime speed of Ed25519 operations by using the
+ public-domain Ed25519-donna by Andrew M. ("floodyberry").
+ Implements ticket 16467.
+ - Improve the runtime speed of the ntor handshake by using an
+ optimized curve25519 basepoint scalarmult implementation from the
+ public-domain Ed25519-donna by Andrew M. ("floodyberry"), based on
+ ideas by Adam Langley. Implements ticket 9663.
o Major features (Hidden services):
+ - Hidden services, if using the EntryNodes option, are required to
+ use more than one EntryNode, in order to avoid a guard discovery
+ attack. (This would only affect people who had configured hidden
+ services and manually specified the EntryNodes option with a
+ single entry-node. The impact was that it would be easy to
+ remotely identify the guard node used by such a hidden service.
+ See ticket for more information.) Fixes ticket 14917.
- Add the torrc option HiddenServiceNumIntroductionPoints, to
specify a fixed number of introduction points. Its maximum value
is 10 and default is 3. Using this option can increase a hidden
@@ -72,44 +109,6 @@ Changes in version 0.2.7.5- 2015-11-??
of this change, microdescriptors will no longer need to include
RSA identity keys. Implements proposal 228; closes ticket 12499.
- o Major features (performance testing):
- - The test-network.sh script now supports performance testing.
- Requires corresponding chutney performance testing changes. Patch
- by "teor". Closes ticket 14175.
-
- o Major features (performance):
- - Improve the runtime speed of Ed25519 operations by using the
- public-domain Ed25519-donna by Andrew M. ("floodyberry").
- Implements ticket 16467.
- - Improve the runtime speed of the ntor handshake by using an
- optimized curve25519 basepoint scalarmult implementation from the
- public-domain Ed25519-donna by Andrew M. ("floodyberry"), based on
- ideas by Adam Langley. Implements ticket 9663.
-
- o Major features (relay, Ed25519):
- - Add a --newpass option to allow changing or removing the
- passphrase of an encrypted key with tor --keygen. Implements part
- of ticket 16769.
- - Add a new OfflineMasterKey option to tell Tor never to try loading
- or generating a secret Ed25519 identity key. You can use this in
- combination with tor --keygen to manage offline and/or encrypted
- Ed25519 keys. Implements ticket 16944.
- - On receiving a HUP signal, check to see whether the Ed25519
- signing key has changed, and reload it if so. Closes ticket 16790.
- - Significant usability improvements for Ed25519 key management. Log
- messages are better, and the code can recover from far more
- failure conditions. Thanks to "s7r" for reporting and diagnosing
- so many of these!
-
- o Major features (security, hidden services):
- - Hidden services, if using the EntryNodes option, are required to
- use more than one EntryNode, in order to avoid a guard discovery
- attack. (This would only affect people who had configured hidden
- services and manually specified the EntryNodes option with a
- single entry-node. The impact was that it would be easy to
- remotely identify the guard node used by such a hidden service.
- See ticket for more information.) Fixes ticket 14917.
-
o Major bugfixes (client-side privacy, also in 0.2.6.9):
- Properly separate out each SOCKSPort when applying stream
isolation. The error occurred because each port's session group
@@ -168,7 +167,7 @@ Changes in version 0.2.7.5- 2015-11-??
service while a NEWNYM is in progress. Fixes bug 16013; bugfix
on 0.1.0.1-rc.
- o Minor features (client):
+ o Minor features (client, SOCKS):
- Add GroupWritable and WorldWritable options to unix-socket based
SocksPort and ControlPort options. These options apply to a single
socket, and override {Control,Socks}SocketsGroupWritable. Closes
@@ -206,6 +205,9 @@ Changes in version 0.2.7.5- 2015-11-??
o Minor features (compilation):
- Give a warning as early as possible when trying to build with an
unsupported OpenSSL version. Closes ticket 16901.
+ - Use C99 variadic macros when the compiler is not GCC. This avoids
+ failing compilations on MSVC, and fixes a log-file-based race
+ condition in our old workarounds. Original patch from Gisle Vanem.
o Minor features (control protocol):
- Support network-liveness GETINFO key and NETWORK_LIVENESS event in
@@ -242,18 +244,9 @@ Changes in version 0.2.7.5- 2015-11-??
introductions, by blocking multiple introduction requests on the
same circuit. Resolves ticket 15515.
- o Minor features (geoIP):
+ o Minor features (geoip):
- Update geoip and geoip6 to the October 9 2015 Maxmind GeoLite2
Country database.
- - Update geoip and geoip6 to the September 3 2015 Maxmind GeoLite2
- Country database.
- - Update geoip to the April 8 2015 Maxmind GeoLite2 Country database.
- - Update geoip6 to the April 8 2015 Maxmind GeoLite2
- Country database.
-
- o Minor features (geoip, also in 0.2.6.10):
- - Update geoip to the June 3 2015 Maxmind GeoLite2 Country database.
- - Update geoip6 to the June 3 2015 Maxmind GeoLite2 Country database.
o Minor features (hidden services):
- Add the new options "HiddenServiceMaxStreams" and
@@ -274,8 +267,6 @@ Changes in version 0.2.7.5- 2015-11-??
track only of the fraction of traffic used by hidden services, and
the total number of hidden services in existence.) Closes
ticket 15254.
-
- o Minor features (HS popularity countermeasure):
- To avoid leaking HS popularity, don't cycle the introduction point
when we've handled a fixed number of INTRODUCE2 cells but instead
cycle it when a random number of introductions is reached, thus
@@ -299,34 +290,6 @@ Changes in version 0.2.7.5- 2015-11-??
can be used by implementations to detect this new behavior.
Resolves ticket 15435.
- o Minor features (portability):
- - Use C99 variadic macros when the compiler is not GCC. This avoids
- failing compilations on MSVC, and fixes a log-file-based race
- condition in our old workarounds. Original patch from Gisle Vanem.
-
- o Minor features (testing):
- - Add a test to verify that the compiler does not eliminate our
- memwipe() implementation. Closes ticket 15377.
- - Add make rule `check-changes` to verify the format of changes
- files. Closes ticket 15180.
- - Add unit tests for control_event_is_interesting(). Add a compile-
- time check that the number of events doesn't exceed the capacity
- of control_event_t.event_mask. Closes ticket 15431, checks for
- bugs similar to 13085. Patch by "teor".
- - Command-line argument tests moved to Stem. Resolves ticket 14806.
- - Integrate the ntor, backtrace, and zero-length keys tests into the
- automake test suite. Closes ticket 15344.
- - Remove assertions during builds to determine Tor's test coverage.
- We don't want to trigger these even in assertions, so including
- them artificially makes our branch coverage look worse than it is.
- This patch provides the new test-stem-full and coverage-html-full
- configure options. Implements ticket 15400.
-
- o Minor features (testing, authorities, documentation):
- - New TestingDirAuthVote{Exit,Guard,HSDir}IsStrict flags to
- explicitly manage consensus flags in testing networks. Patch by
- "robgjansen", modified by "teor". Implements part of ticket 14882.
-
o Minor bugfixes (torrc exit policies):
- In each instance above, usage advice is provided to avoid the
message. Resolves ticket 16069. Patch by "teor". Fixes part of bug
@@ -351,6 +314,10 @@ Changes in version 0.2.7.5- 2015-11-??
on 0.2.3.3-alpha.
- When complaining about bad arguments to "--dump-config", use
stderr, not stdout.
+ - Print usage information for --dump-config when it is used without
+ an argument. Also, fix the error message to use different wording
+ and add newline at the end. Fixes bug 15541; bugfix
+ on 0.2.5.1-alpha.
o Minor bugfixes (compilation):
- Fix compilation of sandbox.c with musl-libc. Fixes bug 17347;
@@ -397,19 +364,6 @@ Changes in version 0.2.7.5- 2015-11-??
its own PRNG. Fixes bug 16360; bugfix on 0.2.5.2-alpha, introduced
when implementing ticket 4900. Patch by "teor".
- o Minor bugfixes (documentation):
- - Advise users on how to configure separate IPv4 and IPv6 exit
- policies in the manpage and sample torrcs. Related to ticket 16069.
- - Fix an error in the manual page and comments for
- TestingDirAuthVoteHSDir[IsStrict], which suggested that a HSDir
- required "ORPort connectivity". While this is true, it is in no
- way unique to the HSDir flag. Of all the flags, only HSDirs need a
- DirPort configured in order for the authorities to assign that
- particular flag. Patch by "teor". Fixed as part of 14882; bugfix
- on 0.2.6.3-alpha.
- - Fix the usage message of tor-resolve(1) so that it no longer lists
- the removed -F option. Fixes bug 16913; bugfix on 0.2.2.28-beta.
-
o Minor bugfixes (hidden service):
- Fix an out-of-bounds read when parsing invalid INTRODUCE2 cells on
a client authorized hidden service. Fixes bug 15823; bugfix
@@ -417,17 +371,14 @@ Changes in version 0.2.7.5- 2015-11-??
- Remove an extraneous newline character from the end of hidden
service descriptors. Fixes bug 15296; bugfix on 0.2.0.10-alpha.
- o Minor bugfixes (interface):
- - Print usage information for --dump-config when it is used without
- an argument. Also, fix the error message to use different wording
- and add newline at the end. Fixes bug 15541; bugfix
- on 0.2.5.1-alpha.
-
o Minor bugfixes (Linux seccomp2 sandbox):
- Use the sandbox in tor_open_cloexec whether or not O_CLOEXEC is
defined. Patch by "teor". Fixes bug 16515; bugfix on 0.2.3.1-alpha.
- Allow bridge authorities to run correctly under the seccomp2
sandbox. Fixes bug 16964; bugfix on 0.2.5.1-alpha.
+ - Add the "hidserv-stats" filename to our sandbox filter for the
+ HiddenServiceStatistics option to work properly. Fixes bug 17354;
+ bugfix on tor-0.2.6.2-alpha. Patch from David Goulet.
o Minor bugfixes (Linux seccomp2 sandbox, also in 0.2.6.10):
- Allow pipe() and pipe2() syscalls in the seccomp2 sandbox: we need
@@ -443,7 +394,7 @@ Changes in version 0.2.7.5- 2015-11-??
syscalls. Fixes bug 16244; bugfix on 0.2.6.1-alpha. Patch by
Peter Palfrader.
- o Minor bugfixes (logs):
+ o Minor bugfixes (logging):
- When building Tor under Clang, do not include an extra set of
parentheses in log messages that include function names. Fixes bug
15269; bugfix on every released version of Tor when compiled with
@@ -481,11 +432,6 @@ Changes in version 0.2.7.5- 2015-11-??
predictable scheduling behavior. Fixes bug 16644; bugfix
on 0.2.6.3-alpha.
- o Minor bugfixes (sandbox):
- - Add the "hidserv-stats" filename to our sandbox filter for the
- HiddenServiceStatistics option to work properly. Fixes bug 17354;
- bugfix on tor-0.2.6.2-alpha. Patch from David Goulet.
-
o Minor bugfixes (security, exit policies):
- ExitPolicyRejectPrivate now also rejects the relay's published
IPv6 address (if any), and any publicly routable IPv4 or IPv6
@@ -513,16 +459,6 @@ Changes in version 0.2.7.5- 2015-11-??
not. Fixes bug 15771; bugfix on 0.2.6.1-alpha. Patch by "teor",
issue discovered by CJ Ess.
- o Minor bugfixes (testing):
- - Check for matching value in server response in ntor_ref.py. Fixes
- bug 15591; bugfix on 0.2.4.8-alpha. Reported and fixed
- by "joelanders".
- - Set the severity correctly when testing
- get_interface_addresses_ifaddrs() and
- get_interface_addresses_win32(), so that the tests fail gracefully
- instead of triggering an assertion. Fixes bug 15759; bugfix on
- 0.2.6.3-alpha. Reported by Nicolas Derive.
-
o Minor bugfixes (tests, also in 0.2.6.9):
- Fix a crash in the unit tests when built with MSVC2013. Fixes bug
16030; bugfix on 0.2.6.2-alpha. Patch from "NewEraCracker".
@@ -594,11 +530,17 @@ Changes in version 0.2.7.5- 2015-11-??
- Standardize on the term "server descriptor" in the manual page.
Previously, we had used "router descriptor", "server descriptor",
and "relay descriptor" interchangeably. Part of ticket 14987.
-
- o New system requirements:
- - Tor no longer includes workarounds to support Libevent versions
- before 1.3e. Libevent 2.0 or later is recommended. Closes
- ticket 15248.
+ - Advise users on how to configure separate IPv4 and IPv6 exit
+ policies in the manpage and sample torrcs. Related to ticket 16069.
+ - Fix an error in the manual page and comments for
+ TestingDirAuthVoteHSDir[IsStrict], which suggested that a HSDir
+ required "ORPort connectivity". While this is true, it is in no
+ way unique to the HSDir flag. Of all the flags, only HSDirs need a
+ DirPort configured in order for the authorities to assign that
+ particular flag. Patch by "teor". Fixed as part of 14882; bugfix
+ on 0.2.6.3-alpha.
+ - Fix the usage message of tor-resolve(1) so that it no longer lists
+ the removed -F option. Fixes bug 16913; bugfix on 0.2.2.28-beta.
o Removed code:
- Remove `USE_OPENSSL_BASE64` and the corresponding fallback code
@@ -636,21 +578,11 @@ Changes in version 0.2.7.5- 2015-11-??
that didn't know about microdescriptors.
- Tor no longer contains workarounds for stat files generated by
super-old versions of Tor that didn't choose guards sensibly.
- - Tor no longer supports copies of OpenSSL that are missing support
- for Elliptic Curve Cryptography. (We began using ECC when
- available in 0.2.4.8-alpha, for more safe and efficient key
- negotiation.) In particular, support for at least one of P256 or
- P224 is now required, with manual configuration needed if only
- P224 is available. Resolves ticket 16140.
- - Tor no longer supports versions of OpenSSL before 1.0. (If you are
- on an operating system that has not upgraded to OpenSSL 1.0 or
- later, and you compile Tor from source, you will need to install a
- more recent OpenSSL to link Tor against.) These versions of
- OpenSSL are still supported by the OpenSSL, but the numerous
- cryptographic improvements in later OpenSSL releases makes them a
- clear choice. Resolves ticket 16034.
o Testing:
+ - The test-network.sh script now supports performance testing.
+ Requires corresponding chutney performance testing changes. Patch
+ by "teor". Closes ticket 14175.
- Add a new set of callgraph analysis scripts that use clang to
produce a list of which Tor functions are reachable from which
other Tor functions. We're planning to use these to help simplify
@@ -693,8 +625,33 @@ Changes in version 0.2.7.5- 2015-11-??
(if any) using the 'tor-cov' coverage binary.
- When running test-network or test-stem, check for the absence of
stem/chutney before doing any build operations.
-
-
+ - Add a test to verify that the compiler does not eliminate our
+ memwipe() implementation. Closes ticket 15377.
+ - Add make rule `check-changes` to verify the format of changes
+ files. Closes ticket 15180.
+ - Add unit tests for control_event_is_interesting(). Add a compile-
+ time check that the number of events doesn't exceed the capacity
+ of control_event_t.event_mask. Closes ticket 15431, checks for
+ bugs similar to 13085. Patch by "teor".
+ - Command-line argument tests moved to Stem. Resolves ticket 14806.
+ - Integrate the ntor, backtrace, and zero-length keys tests into the
+ automake test suite. Closes ticket 15344.
+ - Remove assertions during builds to determine Tor's test coverage.
+ We don't want to trigger these even in assertions, so including
+ them artificially makes our branch coverage look worse than it is.
+ This patch provides the new test-stem-full and coverage-html-full
+ configure options. Implements ticket 15400.
+ - New TestingDirAuthVote{Exit,Guard,HSDir}IsStrict flags to
+ explicitly manage consensus flags in testing networks. Patch by
+ "robgjansen", modified by "teor". Implements part of ticket 14882.
+ - Check for matching value in server response in ntor_ref.py. Fixes
+ bug 15591; bugfix on 0.2.4.8-alpha. Reported and fixed
+ by "joelanders".
+ - Set the severity correctly when testing
+ get_interface_addresses_ifaddrs() and
+ get_interface_addresses_win32(), so that the tests fail gracefully
+ instead of triggering an assertion. Fixes bug 15759; bugfix on
+ 0.2.6.3-alpha. Reported by Nicolas Derive.
Changes in version 0.2.6.10 - 2015-07-12
1
0
commit 617e0f8d26449a4c51479666ce29039b901187ba
Author: tom lurge <tomlurge(a)gmail.com>
Date: Thu Nov 5 09:13:53 2015 -0500
added some markdown formatting
---
doc/HACKING/CodingStandards.md | 129 ++++++++++++++-------------
doc/HACKING/GettingStarted.md | 77 ++++++++--------
doc/HACKING/HelpfulTools.md | 185 ++++++++++++++++++--------------------
doc/HACKING/HowToReview.md | 60 ++++++-------
doc/HACKING/README.1st.md | 28 +++---
doc/HACKING/ReleasingTor.md | 184 +++++++++++++++++++-------------------
doc/HACKING/WritingTests.md | 192 ++++++++++++++++++++--------------------
7 files changed, 430 insertions(+), 425 deletions(-)
diff --git a/doc/HACKING/CodingStandards.md b/doc/HACKING/CodingStandards.md
index ff602bd..f7541d7 100644
--- a/doc/HACKING/CodingStandards.md
+++ b/doc/HACKING/CodingStandards.md
@@ -1,16 +1,16 @@
Coding conventions for Tor
---------------------------
+==========================
tl;dr:
- * Run configure with '--enable-gcc-warnings'
- * Run 'make check-spaces' to catch whitespace errors
- * Document your functions
- * Write unit tests
- * Add a file in 'changes' for your branch.
+ - Run configure with `--enable-gcc-warnings`
+ - Run `make check-spaces` to catch whitespace errors
+ - Document your functions
+ - Write unit tests
+ - Add a file in `changes` for your branch.
Patch checklist
-~~~~~~~~~~~~~~~
+---------------
If possible, send your patch as one of these (in descending order of
preference)
@@ -21,16 +21,16 @@ preference)
Did you remember...
- - To build your code while configured with --enable-gcc-warnings?
- - To run "make check-spaces" on your code?
- - To run "make check-docs" to see whether all new options are on
+ - To build your code while configured with `--enable-gcc-warnings`?
+ - To run `make check-spaces` on your code?
+ - To run `make check-docs` to see whether all new options are on
the manpage?
- To write unit tests, as possible?
- To base your code on the appropriate branch?
- - To include a file in the "changes" directory as appropriate?
+ - To include a file in the `changes` directory as appropriate?
How we use Git branches
------------------------
+=======================
Each main development series (like 0.2.1, 0.2.2, etc) has its main work
applied to a single branch. At most one series can be the development series
@@ -54,13 +54,13 @@ you're working on a new feature, base it on the master branch.
How we log changes
-------------------
+==================
When you do a commit that needs a ChangeLog entry, add a new file to
-the "changes" toplevel subdirectory. It should have the format of a
+the `changes` toplevel subdirectory. It should have the format of a
one-entry changelog section from the current ChangeLog file, as in
- o Major bugfixes:
+- Major bugfixes:
- Fix a potential buffer overflow. Fixes bug 99999; bugfix on
0.3.1.4-beta.
@@ -69,110 +69,115 @@ are: Minor bugfixes, Major bugfixes, Minor features, Major features, Code
simplifications and refactoring. Then say what the change does. If
it's a bugfix, mention what bug it fixes and when the bug was
introduced. To find out which Git tag the change was introduced in,
-you can use "git describe --contains <sha1 of commit>".
+you can use `git describe --contains <sha1 of commit>`.
If at all possible, try to create this file in the same commit where you are
making the change. Please give it a distinctive name that no other branch will
use for the lifetime of your change. To verify the format of the changes file,
-you can use "make check-changes".
+you can use `make check-changes`.
When we go to make a release, we will concatenate all the entries
in changes to make a draft changelog, and clear the directory. We'll
then edit the draft changelog into a nice readable format.
-What needs a changes file?::
- A not-exhaustive list: Anything that might change user-visible
+What needs a changes file?
+
+ * A not-exhaustive list: Anything that might change user-visible
behavior. Anything that changes internals, documentation, or the build
system enough that somebody could notice. Big or interesting code
rewrites. Anything about which somebody might plausibly wonder "when
did that happen, and/or why did we do that" 6 months down the line.
-Why use changes files instead of Git commit messages?::
- Git commit messages are written for developers, not users, and they
+Why use changes files instead of Git commit messages?
+
+ * Git commit messages are written for developers, not users, and they
are nigh-impossible to revise after the fact.
-Why use changes files instead of entries in the ChangeLog?::
- Having every single commit touch the ChangeLog file tended to create
+Why use changes files instead of entries in the ChangeLog?
+
+ * Having every single commit touch the ChangeLog file tended to create
zillions of merge conflicts.
Whitespace and C conformance
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
-Invoke "make check-spaces" from time to time, so it can tell you about
+Invoke `make check-spaces` from time to time, so it can tell you about
deviations from our C whitespace style. Generally, we use:
- - Unix-style line endings
- - K&R-style indentation
- - No space before newlines
- - A blank line at the end of each file
- - Never more than one blank line in a row
- - Always spaces, never tabs
- - No more than 79-columns per line.
- - Two spaces per indent.
- - A space between control keywords and their corresponding paren
- "if (x)", "while (x)", and "switch (x)", never "if(x)", "while(x)", or
- "switch(x)".
- - A space between anything and an open brace.
- - No space between a function name and an opening paren. "puts(x)", not
- "puts (x)".
- - Function declarations at the start of the line.
+ - Unix-style line endings
+ - K&R-style indentation
+ - No space before newlines
+ - A blank line at the end of each file
+ - Never more than one blank line in a row
+ - Always spaces, never tabs
+ - No more than 79-columns per line.
+ - Two spaces per indent.
+ - A space between control keywords and their corresponding paren
+ `if (x)`, `while (x)`, and `switch (x)`, never `if(x)`, `while(x)`, or
+ `switch(x)`.
+ - A space between anything and an open brace.
+ - No space between a function name and an opening paren. `puts(x)`, not
+ `puts (x)`.
+ - Function declarations at the start of the line.
We try hard to build without warnings everywhere. In particular, if you're
using gcc, you should invoke the configure script with the option
-"--enable-gcc-warnings". This will give a bunch of extra warning flags to
+`--enable-gcc-warnings`. This will give a bunch of extra warning flags to
the compiler, and help us find divergences from our preferred C style.
Functions to use; functions not to use
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------
-We have some wrapper functions like tor_malloc, tor_free, tor_strdup, and
-tor_gettimeofday; use them instead of their generic equivalents. (They
+We have some wrapper functions like `tor_malloc`, `tor_free`, `tor_strdup`, and
+`tor_gettimeofday;` use them instead of their generic equivalents. (They
always succeed or exit.)
You can get a full list of the compatibility functions that Tor provides by
-looking through src/common/util*.h and src/common/compat*.h. You can see the
-available containers in src/common/containers*.h. You should probably
+looking through `src/common/util*.h` and `src/common/compat*.h`. You can see the
+available containers in `src/common/containers*.h`. You should probably
familiarize yourself with these modules before you write too much code, or
else you'll wind up reinventing the wheel.
-Use 'INLINE' instead of 'inline' -- it's a vestige of an old hack to make
+Use `INLINE` instead of `inline` -- it's a vestige of an old hack to make
sure that we worked on MSVC6.
-We don't use strcat or strcpy or sprintf of any of those notoriously broken
-old C functions. Use strlcat, strlcpy, or tor_snprintf/tor_asprintf instead.
+We don't use `strcat` or `strcpy` or `sprintf` of any of those notoriously broken
+old C functions. Use `strlcat`, `strlcpy`, or `tor_snprintf/tor_asprintf` instead.
-We don't call memcmp() directly. Use fast_memeq(), fast_memneq(),
-tor_memeq(), or tor_memneq() for most purposes.
+We don't call `memcmp()` directly. Use `fast_memeq()`, `fast_memneq()`,
+`tor_memeq()`, or `tor_memneq()` for most purposes.
Functions not to write
-~~~~~~~~~~~~~~~~~~~~~~
+----------------------
Try to never hand-write new code to parse or generate binary
-formats. Instead, use trunnel if at all possible. See
+formats. Instead, use trunnel if at all possible. See
+
https://gitweb.torproject.org/trunnel.git/tree
+
for more information about trunnel.
For information on adding new trunnel code to Tor, see src/trunnel/README
Calling and naming conventions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
Whenever possible, functions should return -1 on error and 0 on success.
For multi-word identifiers, use lowercase words combined with
-underscores. (e.g., "multi_word_identifier"). Use ALL_CAPS for macros and
+underscores. (e.g., `multi_word_identifier`). Use ALL_CAPS for macros and
constants.
-Typenames should end with "_t".
+Typenames should end with `_t`.
Function names should be prefixed with a module name or object name. (In
general, code to manipulate an object should be a module with the same name
as the object, so it's hard to tell which convention is used.)
Functions that do things should have imperative-verb names
-(e.g. buffer_clear, buffer_resize); functions that return booleans should
-have predicate names (e.g. buffer_is_empty, buffer_needs_resizing).
+(e.g. `buffer_clear`, `buffer_resize`); functions that return booleans should
+have predicate names (e.g. `buffer_is_empty`, `buffer_needs_resizing`).
If you find that you have four or more possible return code values, it's
probably time to create an enum. If you find that you are passing three or
@@ -180,16 +185,16 @@ more flags to a function, it's probably time to create a flags argument that
takes a bitfield.
What To Optimize
-~~~~~~~~~~~~~~~~
+----------------
Don't optimize anything if it's not in the critical path. Right now, the
critical path seems to be AES, logging, and the network itself. Feel free to
do your own profiling to determine otherwise.
Log conventions
-~~~~~~~~~~~~~~~
+---------------
-https://www.torproject.org/docs/faq#LogLevel
+`https://www.torproject.org/docs/faq#LogLevel`
No error or warning messages should be expected during normal OR or OP
operation.
@@ -206,7 +211,7 @@ option (B).
Doxygen comment conventions
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+---------------------------
Say what functions do as a series of one or more imperative sentences, as
though you were telling somebody how to be the function. In other words, DO
diff --git a/doc/HACKING/GettingStarted.md b/doc/HACKING/GettingStarted.md
index ee024fe..4ab26b7 100644
--- a/doc/HACKING/GettingStarted.md
+++ b/doc/HACKING/GettingStarted.md
@@ -37,10 +37,11 @@ Getting your first patch into Tor
Once you've reached this point, here's what you need to know.
- 1) Get the source.
+ 1. Get the source.
We keep our source under version control in Git. To get the latest
- version, run
+ version, run
+
git clone https://git.torproject.org/git/tor
This will give you a checkout of the master branch. If you're
@@ -49,10 +50,11 @@ Once you've reached this point, here's what you need to know.
git checkout maint-0.2.7
- 2) Find your way around the source
+ 2. Find your way around the source
Our overall code structure is explained in the "torguts" documents,
currently at
+
git clone https://git.torproject.org/user/nickm/torguts.git
Find a part of the code that looks interesting to you, and start
@@ -64,14 +66,14 @@ Once you've reached this point, here's what you need to know.
If you see something that doesn't make sense, we love to get
questions!
- 3) Find something cool to hack on.
+ 3. Find something cool to hack on.
You may already have a good idea of what you'd like to work on, or
you might be looking for a way to contribute.
Many people have gotten started by looking for an area where they
personally felt Tor was underperforming, and investigating ways to
- fix it. If you're looking for ideas, you can head to our bug
+ fix it. If you're looking for ideas, you can head to our bug
tracker at trac.torproject.org and look for tickets that have
received the "easy" tag: these are ones that developers think would
be pretty simple for a new person to work on. For a bigger
@@ -86,11 +88,12 @@ Once you've reached this point, here's what you need to know.
For your first patch, it is probably NOT a good idea to make
something huge or invasive. In particular, you should probably
avoid:
- * Major changes spread across many parts of the codebase.
- * Major changes to programming practice or coding style.
- * Huge new features or protocol changes.
+
+ * Major changes spread across many parts of the codebase.
+ * Major changes to programming practice or coding style.
+ * Huge new features or protocol changes.
- 4) Meet the developers!
+ 4. Meet the developers!
We discuss stuff on the tor-dev mailing list and on the #tor-dev
IRC channel on OFTC. We're generally friendly and approachable,
@@ -103,7 +106,7 @@ Once you've reached this point, here's what you need to know.
better. The time might change in the future, but generally,
there's no bad time to talk, and ask us about patch ideas.
- 5) Do you need to write a design proposal?
+ 5. Do you need to write a design proposal?
If your idea is very large, or it will require a change to Tor's
protocols, there needs to be a written design proposal before it
@@ -116,7 +119,7 @@ Once you've reached this point, here's what you need to know.
You might also like to look around the rest of that directory, to
see more about open and past proposed changes to Tor's behavior.
- 6) Writing your patch
+ 6. Writing your patch
As you write your code, you'll probably want it to fit in with the
standards of the rest of the Tor codebase so it will be easy for us
@@ -127,7 +130,7 @@ Once you've reached this point, here's what you need to know.
components, remember to divide it into a series of Git commits. A
series of small changes is much easier to review than one big lump.
- 7) Testing your patch
+ 7. Testing your patch
We prefer that all new or modified code have unit tests for it to
ensure that it runs correctly. Also, all code should actually be
@@ -137,7 +140,7 @@ Once you've reached this point, here's what you need to know.
in Tor. If you'd like any help writing tests, just ask! We're
glad to help out.
- 8) Submitting your patch
+ 8. Submitting your patch
We review patches through tickets on our bugtracker at
trac.torproject.org. You can either upload your patches there, or
@@ -149,7 +152,7 @@ Once you've reached this point, here's what you need to know.
you've done on trac, and then change the status of the ticket to
needs_review.
- 9) Review, Revision, and Merge
+ 9. Review, Revision, and Merge
With any luck, somebody will review your patch soon! If not, you
can ask on the IRC channel; sometimes we get really busy and take
@@ -159,29 +162,29 @@ Once you've reached this point, here's what you need to know.
When your patch is reviewed, one of these things will happen:
- * The reviewer will say "looks good to me" and your
- patch will get merged right into Tor. [Assuming we're not
- in the middle of a code-freeze window. If the codebase is
- frozen, your patch will go into the next release series.]
-
- * OR the reviewer will say "looks good, just needs some small
- changes!" And then the reviewer will make those changes,
- and merge the modified patch into Tor.
-
- * OR the reviewer will say "Here are some questions and
- comments," followed by a bunch of stuff that the reviewer
- thinks should change in your code, or questions that the
- reviewer has.
-
- At this point, you might want to make the requested changes
- yourself, and comment on the trac ticket once you have done
- so. Or if you disagree with any of the comments, you should
- say so! And if you won't have time to make some of the
- changes, you should say that too, so that other developers
- will be able to pick up the unfinished portion
-
- Congratulations! You have now written your first patch, and gotten
- it integrated into mainline Tor.
+ * The reviewer will say "looks good to me" and your
+ patch will get merged right into Tor. [Assuming we're not
+ in the middle of a code-freeze window. If the codebase is
+ frozen, your patch will go into the next release series.]
+
+ * OR the reviewer will say "looks good, just needs some small
+ changes!" And then the reviewer will make those changes,
+ and merge the modified patch into Tor.
+
+ * OR the reviewer will say "Here are some questions and
+ comments," followed by a bunch of stuff that the reviewer
+ thinks should change in your code, or questions that the
+ reviewer has.
+
+ At this point, you might want to make the requested changes
+ yourself, and comment on the trac ticket once you have done
+ so. Or if you disagree with any of the comments, you should
+ say so! And if you won't have time to make some of the
+ changes, you should say that too, so that other developers
+ will be able to pick up the unfinished portion.
+
+ Congratulations! You have now written your first patch, and gotten
+ it integrated into mainline Tor.
diff --git a/doc/HACKING/HelpfulTools.md b/doc/HACKING/HelpfulTools.md
index cf74063..810519c 100644
--- a/doc/HACKING/HelpfulTools.md
+++ b/doc/HACKING/HelpfulTools.md
@@ -1,159 +1,149 @@
Useful tools
-------------
+============
These aren't strictly necessary for hacking on Tor, but they can help track
down bugs.
Jenkins
-~~~~~~~
+-------
-https://jenkins.torproject.org
+ https://jenkins.torproject.org
Dmalloc
-~~~~~~~
+-------
The dmalloc library will keep track of memory allocation, so you can find out
if we're leaking memory, doing any double-frees, or so on.
- dmalloc -l ~/dmalloc.log
- (run the commands it tells you)
- ./configure --with-dmalloc
+ dmalloc -l -/dmalloc.log
+ (run the commands it tells you)
+ ./configure --with-dmalloc
Valgrind
-~~~~~~~~
+--------
-valgrind --leak-check=yes --error-limit=no --show-reachable=yes src/or/tor
+ valgrind --leak-check=yes --error-limit=no --show-reachable=yes src/or/tor
(Note that if you get a zillion openssl warnings, you will also need to
-pass --undef-value-errors=no to valgrind, or rebuild your openssl
-with -DPURIFY.)
+pass `--undef-value-errors=no` to valgrind, or rebuild your openssl
+with `-DPURIFY`.)
Coverity
-~~~~~~~~
+--------
Nick regularly runs the coverity static analyzer on the Tor codebase.
-The preprocessor define __COVERITY__ is used to work around instances
+The preprocessor define `__COVERITY__` is used to work around instances
where coverity picks up behavior that we wish to permit.
clang Static Analyzer
-~~~~~~~~~~~~~~~~~~~~~
+---------------------
The clang static analyzer can be run on the Tor codebase using Xcode (WIP)
or a command-line build.
-The preprocessor define __clang_analyzer__ is used to work around instances
+The preprocessor define `__clang_analyzer__` is used to work around instances
where clang picks up behavior that we wish to permit.
clang Runtime Sanitizers
-~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------
To build the Tor codebase with the clang Address and Undefined Behavior
-sanitizers, see the file contrib/clang/sanitize_blacklist.txt.
+sanitizers, see the file `contrib/clang/sanitize_blacklist.txt`.
Preprocessor workarounds for instances where clang picks up behavior that
we wish to permit are also documented in the blacklist file.
Running lcov for unit test coverage
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------
Lcov is a utility that generates pretty HTML reports of test code coverage.
To generate such a report:
------
- ./configure --enable-coverage
- make
- make coverage-html
- $BROWSER ./coverage_html/index.html
------
+ ./configure --enable-coverage
+ make
+ make coverage-html
+ $BROWSER ./coverage_html/index.html
This will run the tor unit test suite `./src/test/test` and generate the HTML
-coverage code report under the directory ./coverage_html/. To change the
+coverage code report under the directory `./coverage_html/`. To change the
output directory, use `make coverage-html HTML_COVER_DIR=./funky_new_cov_dir`.
Coverage diffs using lcov are not currently implemented, but are being
investigated (as of July 2014).
Running the unit tests
-~~~~~~~~~~~~~~~~~~~~~~
+----------------------
To quickly run all the tests distributed with Tor:
------
- make check
------
+
+ make check
To run the fast unit tests only:
------
- make test
------
+
+ make test
To selectively run just some tests (the following can be combined
arbitrarily):
------
- ./src/test/test <name_of_test> [<name of test 2>] ...
- ./src/test/test <prefix_of_name_of_test>.. [<prefix_of_name_of_test2>..] ...
- ./src/test/test :<name_of_excluded_test> [:<name_of_excluded_test2]...
------
+
+ ./src/test/test <name_of_test> [<name of test 2>] ...
+ ./src/test/test <prefix_of_name_of_test>.. [<prefix_of_name_of_test2>..] ...
+ ./src/test/test :<name_of_excluded_test> [:<name_of_excluded_test2]...
To run all tests, including those based on Stem or Chutney:
------
- make test-full
------
+
+ make test-full
To run all tests, including those based on Stem or Chutney that require a
working connection to the internet:
------
- make test-full-online
------
-Running gcov for unit test coverage
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
------
- ./configure --enable-coverage
- make
- make check
- # or--- make test-full ? make test-full-online?
- mkdir coverage-output
- ./scripts/test/coverage coverage-output
------
+ make test-full-online
-(On OSX, you'll need to start with "--enable-coverage CC=clang".)
-
-Then, look at the .gcov files in coverage-output. '-' before a line means
+Running gcov for unit test coverage
+-----------------------------------
+
+ ./configure --enable-coverage
+ make
+ make check
+ # or--- make test-full ? make test-full-online?
+ mkdir coverage-output
+ ./scripts/test/coverage coverage-output
+
+(On OSX, you'll need to start with `--enable-coverage CC=clang`.)
+
+Then, look at the .gcov files in `coverage-output`. '-' before a line means
that the compiler generated no code for that line. '######' means that the
line was never reached. Lines with numbers were called that number of times.
If that doesn't work:
- * Try configuring Tor with --disable-gcc-hardening
- * You might need to run 'make clean' after you run './configure'.
+
+ * Try configuring Tor with `--disable-gcc-hardening`
+ * You might need to run `make clean` after you run `./configure`.
If you make changes to Tor and want to get another set of coverage results,
-you can run "make reset-gcov" to clear the intermediary gcov output.
+you can run `make reset-gcov` to clear the intermediary gcov output.
-If you have two different "coverage-output" directories, and you want to see
+If you have two different `coverage-output` directories, and you want to see
a meaningful diff between them, you can run:
------
- ./scripts/test/cov-diff coverage-output1 coverage-output2 | less
------
+ ./scripts/test/cov-diff coverage-output1 coverage-output2 | less
In this diff, any lines that were visited at least once will have coverage
"1". This lets you inspect what you (probably) really want to know: which
untested lines were changed? Are there any new untested lines?
Running integration tests
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
We have the beginnings of a set of scripts to run integration tests using
Chutney. To try them, set CHUTNEY_PATH to your chutney source directory, and
-run "make test-network".
+run `make test-network`.
We also have scripts to run integration tests using Stem. To try them, set
-STEM_SOURCE_DIR to your Stem source directory, and run "test-stem".
+`STEM_SOURCE_DIR` to your Stem source directory, and run `test-stem`.
Profiling Tor with oprofile
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
The oprofile tool runs (on Linux only!) to tell you what functions Tor is
spending its CPU time in, so we can identify performance bottlenecks.
@@ -165,30 +155,30 @@ Here are some basic instructions
- Build all the libraries you care about with debugging symbols
(probably you only care about libssl, maybe zlib and Libevent).
- Copy this tor to a new directory
- - Copy all the libraries it uses to that dir too (ldd ./tor will
+ - Copy all the libraries it uses to that dir too (`ldd ./tor` will
tell you)
- - Set LD_LIBRARY_PATH to include that dir. ldd ./tor should now
+ - Set LD_LIBRARY_PATH to include that dir. `ldd ./tor` should now
show you it's using the libs in that dir
- Run that tor
- Reset oprofiles counters/start it
- * "opcontrol --reset; opcontrol --start", if Nick remembers right.
+ * `opcontrol --reset; opcontrol --start`, if Nick remembers right.
- After a while, have it dump the stats on tor and all the libs
in that dir you created.
- * "opcontrol --dump;"
- * "opreport -l that_dir/*"
+ * `opcontrol --dump;`
+ * `opreport -l that_dir/*`
- Profit
Generating and analyzing a callgraph
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------
-1. Run ./scripts/maint/generate_callgraph.sh . This will generate a
+1. Run `./scripts/maint/generate_callgraph.sh`. This will generate a
bunch of files in a new ./callgraph directory.
-2. Run ./scripts/maint/analyze_callgraph.py callgraph/src/*/* . This
+2. Run `./scripts/maint/analyze_callgraph.py callgraph/src/*/*`. This
will do a lot of graph operations and then dump out a new
- "callgraph.pkl" file, containing data in Python's "pickle" format.
+ `callgraph.pkl` file, containing data in Python's 'pickle' format.
-3. Run ./scripts/maint/display_callgraph.py . It will display:
+3. Run `./scripts/maint/display_callgraph.py`. It will display:
- the number of functions reachable from each function.
- all strongly-connnected components in the Tor callgraph
- the largest bottlenecks in the largest SCC in the Tor callgraph.
@@ -197,11 +187,11 @@ Note that currently the callgraph generator can't detect calls that pass
through function pointers.
Getting emacs to edit Tor source properly
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-----------------------------------------
Nick likes to put the following snippet in his .emacs file:
------
+
(add-hook 'c-mode-hook
(lambda ()
(font-lock-mode 1)
@@ -221,9 +211,9 @@ Nick likes to put the following snippet in his .emacs file:
(set-variable 'c-basic-offset 8)
(set-variable 'tab-width 8))
))))
------
-You'll note that it defaults to showing all trailing whitespace. The "cond"
+
+You'll note that it defaults to showing all trailing whitespace. The `cond`
test detects whether the file is one of a few C free software projects that I
often edit, and sets up the indentation level and tab preferences to match
what they want.
@@ -233,26 +223,27 @@ patterns to match where you keep your Tor files.
If you use emacs for editing Tor and nothing else, you could always just say:
------
- (add-hook 'c-mode-hook
- (lambda ()
+
+ (add-hook 'c-mode-hook
+ (lambda ()
(font-lock-mode 1)
(set-variable 'show-trailing-whitespace t)
(set-variable 'indent-tabs-mode nil)
(set-variable 'c-basic-offset 2)))
------
+
There is probably a better way to do this. No, we are probably not going
to clutter the files with emacs stuff.
Doxygen
-~~~~~~~
+-------
We use the 'doxygen' utility to generate documentation from our
source code. Here's how to use it:
1. Begin every file that should be documented with
+
/**
* \file filename.c
* \brief Short description of the file.
@@ -279,24 +270,24 @@ source code. Here's how to use it:
* \endcode
*/
- 3. Make sure to escape the characters "<", ">", "\", "%" and "#" as "\<",
- "\>", "\\", "\%", and "\#".
+ 3. Make sure to escape the characters `<`, `>`, `\`, `%` and `#` as `\<`,
+ `\>`, `\\`, `\%` and `\#`.
4. To document structure members, you can use two forms:
- struct foo {
- /** You can put the comment before an element; */
- int a;
- int b; /**< Or use the less-than symbol to put the comment
+ struct foo {
+ /** You can put the comment before an element; */
+ int a;
+ int b; /**< Or use the less-than symbol to put the comment
* after the element. */
- };
+ };
5. To generate documentation from the Tor source code, type:
- $ doxygen -g
+ $ doxygen -g
- To generate a file called 'Doxyfile'. Edit that file and run
- 'doxygen' to generate the API documentation.
+ to generate a file called `Doxyfile`. Edit that file and run
+ `doxygen` to generate the API documentation.
6. See the Doxygen manual for more information; this summary just
scratches the surface.
diff --git a/doc/HACKING/HowToReview.md b/doc/HACKING/HowToReview.md
index d6b40db..de7891c 100644
--- a/doc/HACKING/HowToReview.md
+++ b/doc/HACKING/HowToReview.md
@@ -15,71 +15,71 @@ Top-level smell-checks
(Difficulty: easy)
-Does it compile with --enable-gcc-warnings?
+- Does it compile with `--enable-gcc-warnings`?
-Does 'make check-spaces' pass?
+- Does `make check-spaces` pass?
-Does it have a reasonable amount of tests? Do they pass? Do they leak
-memory?
+- Does it have a reasonable amount of tests? Do they pass? Do they leak
+ memory?
-Do all the new functions, global variables, types, and structure members have
-documentation?
+- Do all the new functions, global variables, types, and structure members have
+ documentation?
-Do all the functions, global variables, types, and structure members with
-modified behavior have modified documentation?
+- Do all the functions, global variables, types, and structure members with
+ modified behavior have modified documentation?
-Do all the new torrc options have documentation?
+- Do all the new torrc options have documentation?
-If this changes Tor's behavior on the wire, is there a design proposal?
+- If this changes Tor's behavior on the wire, is there a design proposal?
Let's look at the code!
-----------------------
-Does the code conform to CodingStandards.txt?
+- Does the code conform to CodingStandards.txt?
-Does the code leak memory?
+- Does the code leak memory?
-If two or more pointers ever point to the same object, is it clear which
-pointer "owns" the object?
+- If two or more pointers ever point to the same object, is it clear which
+ pointer "owns" the object?
-Are all allocated resources freed?
+- Are all allocated resources freed?
-Are all pointers that should be const, const?
+- Are all pointers that should be const, const?
-Are #defines used for 'magic' numbers?
+- Are `#defines` used for 'magic' numbers?
-Can you understand what the code is trying to do?
+- Can you understand what the code is trying to do?
-Can you convince yourself that the code really does that?
+- Can you convince yourself that the code really does that?
-Is there duplicated code that could be turned into a function?
+- Is there duplicated code that could be turned into a function?
Let's look at the documentation!
--------------------------------
-Does the documentation confirm to CodingStandards.txt?
+- Does the documentation confirm to CodingStandards.txt?
-Does it make sense?
+- Does it make sense?
-Can you predict what the function will do from its documentation?
+- Can you predict what the function will do from its documentation?
Let's think about security!
---------------------------
-If there are any arrays, buffers, are you 100% sure that they cannot
-overflow?
+- If there are any arrays, buffers, are you 100% sure that they cannot
+ overflow?
-If there is any integer math, can it overflow or underflow?
+- If there is any integer math, can it overflow or underflow?
-If there are any allocations, are you sure there are corresponding
-deallocations?
+- If there are any allocations, are you sure there are corresponding
+ deallocations?
-Is there a safer pattern that could be used in any case?
+- Is there a safer pattern that could be used in any case?
-Have they used one of the Forbidden Functions?
+- Have they used one of the Forbidden Functions?
(Also see your favorite secure C programming guides.)
diff --git a/doc/HACKING/README.1st.md b/doc/HACKING/README.1st.md
index a9479de..8299fe6 100644
--- a/doc/HACKING/README.1st.md
+++ b/doc/HACKING/README.1st.md
@@ -5,46 +5,48 @@ In this directory
This directory has helpful information about what you need to know to
hack on Tor!
-First, read 'GettingStarted.md' to learn how to get a start in Tor
+First, read `GettingStarted.md` to learn how to get a start in Tor
development.
-If you've decided to write a patch, 'CodingStandards.txt' will give
+If you've decided to write a patch, `CodingStandards.txt` will give
you a bunch of information about how we structure our code.
-It's important to get code right! Reading 'WritingTests.md' will
+It's important to get code right! Reading `WritingTests.md` will
tell you how to write and run tests in the Tor codebase.
There are a bunch of other programs we use to help maintain and
-develop the codebase: 'HelpfulTools.md' can tell you how to use them
+develop the codebase: `HelpfulTools.md` can tell you how to use them
with Tor.
-If it's your job to put out Tor releases, see 'ReleasingTor.md' so
+If it's your job to put out Tor releases, see `ReleasingTor.md` so
that you don't miss any steps!
-
-----------------------
For full information on how Tor is supposed to work, look at the files in
-https://gitweb.torproject.org/torspec.git/tree
+`https://gitweb.torproject.org/torspec.git/tree`.
For an explanation of how to change Tor's design to work differently, look at
-https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/001-process.txt
+`https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/001-process.txt`.
For the latest version of the code, get a copy of git, and
- git clone https://git.torproject.org/git/tor
+ git clone https://git.torproject.org/git/tor
-We talk about Tor on the tor-talk mailing list. Design proposals and
-discussion belong on the tor-dev mailing list. We hang around on
+We talk about Tor on the `tor-talk` mailing list. Design proposals and
+discussion belong on the `tor-dev` mailing list. We hang around on
irc.oftc.net, with general discussion happening on #tor and development
-happening on #tor-dev.
+happening on `#tor-dev`.
-The other files in this "HACKING" directory may also be useful as you
+The other files in this `HACKING` directory may also be useful as you
get started working with Tor.
Happy hacking!
+
+-----------------------
+
XXXXX also describe
doc/HACKING/WritingTests.md
diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md
index dcf551b..12a0765 100644
--- a/doc/HACKING/ReleasingTor.md
+++ b/doc/HACKING/ReleasingTor.md
@@ -4,122 +4,126 @@ Putting out a new release
Here are the steps Roger takes when putting out a new Tor release:
-1) Use it for a while, as a client, as a relay, as a hidden service,
-and as a directory authority. See if it has any obvious bugs, and
-resolve those.
+1. Use it for a while, as a client, as a relay, as a hidden service,
+ and as a directory authority. See if it has any obvious bugs, and
+ resolve those.
+
+ As applicable, merge the `maint-X` branch into the `release-X` branch.
-1.5) As applicable, merge the maint-X branch into the release-X branch.
+2. Gather the `changes/*` files into a changelog entry, rewriting many
+ of them and reordering to focus on what users and funders would find
+ interesting and understandable.
-2) Gather the changes/* files into a changelog entry, rewriting many
-of them and reordering to focus on what users and funders would find
-interesting and understandable.
+ 1. Make sure that everything that wants a bug number has one.
+ Make sure that everything which is a bugfix says what version
+ it was a bugfix on.
+
+ 2. Concatenate them.
+
+ 3. Sort them by section. Within each section, sort by "version it's
+ a bugfix on", else by numerical ticket order.
- 2.1) Make sure that everything that wants a bug number has one.
- Make sure that everything which is a bugfix says what version
- it was a bugfix on.
- 2.2) Concatenate them.
- 2.3) Sort them by section. Within each section, sort by "version it's
- a bugfix on", else by numerical ticket order.
+ 4. Clean them up:
- 2.4) Clean them up:
+ Standard idioms:
+ `Fixes bug 9999; bugfix on 0.3.3.3-alpha.`
- Standard idioms:
- "Fixes bug 9999; bugfix on 0.3.3.3-alpha."
+ One space after a period.
- One space after a period.
+ Make stuff very terse
- Make stuff very terse
+ Make sure each section name ends with a colon
- Make sure each section name ends with a colon
+ Describe the user-visible problem right away
- Describe the user-visible problem right away
+ Mention relevant config options by name. If they're rare or unusual,
+ remind people what they're for
- Mention relevant config options by name. If they're rare or unusual,
- remind people what they're for
+ Avoid starting lines with open-paren
- Avoid starting lines with open-paren
+ Present and imperative tense: not past.
- Present and imperative tense: not past.
+ 'Relays', not 'servers' or 'nodes' or 'Tor relays'.
- 'Relays', not 'servers' or 'nodes' or 'Tor relays'.
+ "Stop FOOing", not "Fix a bug where we would FOO".
- "Stop FOOing", not "Fix a bug where we would FOO".
+ Try not to let any given section be longer than about a page. Break up
+ long sections into subsections by some sort of common subtopic. This
+ guideline is especially important when organizing Release Notes for
+ new stable releases.
- Try not to let any given section be longer than about a page. Break up
- long sections into subsections by some sort of common subtopic. This
- guideline is especially important when organizing Release Notes for
- new stable releases.
+ If a given changes stanza showed up in a different release (e.g.
+ maint-0.2.1), be sure to make the stanzas identical (so people can
+ distinguish if these are the same change).
+
+ 5. Merge them in.
- If a given changes stanza showed up in a different release (e.g.
- maint-0.2.1), be sure to make the stanzas identical (so people can
- distinguish if these are the same change).
+ 6. Clean everything one last time.
- 2.5) Merge them in.
+ 7. Run `./scripts/maint/format_changelog.py` to make it prettier.
- 2.6) Clean everything one last time.
+3. Compose a short release blurb to highlight the user-facing
+ changes. Insert said release blurb into the ChangeLog stanza. If it's
+ a stable release, add it to the ReleaseNotes file too. If we're adding
+ to a release-0.2.x branch, manually commit the changelogs to the later
+ git branches too.
- 2.7) Run ./scripts/maint/format_changelog.py to make it prettier.
+4. In `maint-0.2.x`, bump the version number in `configure.ac` and run
+ `scripts/maint/updateVersions.pl` to update version numbers in other
+ places, and commit. Then merge `maint-0.2.x` into `release-0.2.x`.
-3) Compose a short release blurb to highlight the user-facing
-changes. Insert said release blurb into the ChangeLog stanza. If it's
-a stable release, add it to the ReleaseNotes file too. If we're adding
-to a release-0.2.x branch, manually commit the changelogs to the later
-git branches too.
-
-4) In maint-0.2.x, bump the version number in configure.ac and run
- scripts/maint/updateVersions.pl to update version numbers in other
- places, and commit. Then merge maint-0.2.x into release-0.2.x.
-
- (NOTE: To bump the version number, edit configure.ac, and then run
- either make, or 'perl scripts/maint/updateVersions.pl', depending on
+ (NOTE: To bump the version number, edit `configure.ac`, and then run
+ either `make`, or `perl scripts/maint/updateVersions.pl`, depending on
your version.)
-5) Make dist, put the tarball up somewhere, and tell #tor about it. Wait
-a while to see if anybody has problems building it. Try to get Sebastian
-or somebody to try building it on Windows.
-
-6) Get at least two of weasel/arma/Sebastian to put the new version number
-in their approved versions list.
+5. Make dist, put the tarball up somewhere, and tell `#tor` about it. Wait
+ a while to see if anybody has problems building it. Try to get Sebastian
+ or somebody to try building it on Windows.
-7) Sign the tarball, then sign and push the git tag:
- gpg -ba <the_tarball>
- git tag -u <keyid> tor-0.2.x.y-status
- git push origin tag tor-0.2.x.y-status
+6. Get at least two of weasel/arma/Sebastian to put the new version number
+ in their approved versions list.
-8a) scp the tarball and its sig to the dist website, i.e.
-/srv/dist-master.torproject.org/htdocs/ on dist-master. When you want
-it to go live, you run "static-update-component dist.torproject.org"
-on dist-master.
+7. Sign the tarball, then sign and push the git tag:
+
+ gpg -ba <the_tarball>
+ git tag -u <keyid> tor-0.2.x.y-status
+ git push origin tag tor-0.2.x.y-status
-8b) Edit "include/versions.wmi" and "Makefile" to note the new version.
+8. scp the tarball and its sig to the dist website, i.e.
+ `/srv/dist-master.torproject.org/htdocs/` on dist-master. When you want
+ it to go live, you run "static-update-component dist.torproject.org"
+ on dist-master.
+
+ Edit `include/versions.wmi` and `Makefile` to note the new version.
-9) Email the packagers (cc'ing tor-assistants) that a new tarball is up.
+9. Email the packagers (cc'ing tor-assistants) that a new tarball is up.
The current list of packagers is:
- {weasel,gk,mikeperry} at torproject dot org
- {blueness} at gentoo dot org
- {paul} at invizbox dot io
- {ondrej.mikle} at gmail dot com
- {lfleischer} at archlinux dot org
- {tails-dev} at doum dot org
-
-10) Add the version number to Trac. To do this, go to Trac, log in,
-select "Admin" near the top of the screen, then select "Versions" from
-the menu on the left. At the right, there will be an "Add version"
-box. By convention, we enter the version in the form "Tor:
-0.2.2.23-alpha" (or whatever the version is), and we select the date as
-the date in the ChangeLog.
-
-11) Forward-port the ChangeLog.
-
-12) Wait up to a day or two (for a development release), or until most
-packages are up (for a stable release), and mail the release blurb and
-changelog to tor-talk or tor-announce.
-
- (We might be moving to faster announcements, but don't announce until
- the website is at least updated.)
-
-13) If it's a stable release, bump the version number in the maint-x.y.z
- branch to "newversion-dev", and do a "merge -s ours" merge to avoid
- taking that change into master. Do a similar 'merge -s theirs'
+
+ - {weasel,gk,mikeperry} at torproject dot org
+ - {blueness} at gentoo dot org
+ - {paul} at invizbox dot io
+ - {ondrej.mikle} at gmail dot com
+ - {lfleischer} at archlinux dot org
+ - {tails-dev} at doum dot org
+
+10. Add the version number to Trac. To do this, go to Trac, log in,
+ select "Admin" near the top of the screen, then select "Versions" from
+ the menu on the left. At the right, there will be an "Add version"
+ box. By convention, we enter the version in the form "Tor:
+ 0.2.2.23-alpha" (or whatever the version is), and we select the date as
+ the date in the ChangeLog.
+
+11. Forward-port the ChangeLog.
+
+12. Wait up to a day or two (for a development release), or until most
+ packages are up (for a stable release), and mail the release blurb and
+ changelog to tor-talk or tor-announce.
+
+ (We might be moving to faster announcements, but don't announce until
+ the website is at least updated.)
+
+13. If it's a stable release, bump the version number in the `maint-x.y.z`
+ branch to "newversion-dev", and do a `merge -s ours` merge to avoid
+ taking that change into master. Do a similar `merge -s theirs`
merge to get the change (and only that change) into release. (Some
of the build scripts require that maint merge cleanly into release.)
diff --git a/doc/HACKING/WritingTests.md b/doc/HACKING/WritingTests.md
index 2f59c9a..42fba2d 100644
--- a/doc/HACKING/WritingTests.md
+++ b/doc/HACKING/WritingTests.md
@@ -22,92 +22,92 @@ keep from introducing bugs. The major ones are:
How to run these tests
----------------------
-=== The easy version
+### The easy version
-To run all the tests that come bundled with Tor, run "make check"
+To run all the tests that come bundled with Tor, run `make check`.
To run the Stem tests as well, fetch stem from the git repository,
-set STEM_SOURCE_DIR to the checkout, and run "make test-stem".
+set `STEM_SOURCE_DIR` to the checkout, and run `make test-stem`.
To run the Chutney tests as well, fetch chutney from the git repository,
-set CHUTNEY_PATH to the checkout, and run "make test-network".
+set `CHUTNEY_PATH` to the checkout, and run `make test-network`.
-To run all of the above, run "make test-full".
+To run all of the above, run `make test-full`.
To run all of the above, plus tests that require a working connection to the
-internet, run "make test-full-online".
+internet, run `make test-full-online`.
-=== Running particular subtests
+### Running particular subtests
The Tor unit tests are divided into separate programs and a couple of
bundled unit test programs.
Separate programs are easy. For example, to run the memwipe tests in
-isolation, you just run ./src/test/test-memwipe .
+isolation, you just run `./src/test/test-memwipe`.
To run tests within the unit test programs, you can specify the name
of the test. The string ".." can be used as a wildcard at the end of the
test name. For example, to run all the cell format tests, enter
-"./src/test/test cellfmt/..". To run
+`./src/test/test cellfmt/..`. To run
Many tests that need to mess with global state run in forked subprocesses in
order to keep from contaminating one another. But when debugging a failing test,
you might want to run it without forking a subprocess. To do so, use the
-"--no-fork" option with a single test. (If you specify it along with
+`--no-fork` option with a single test. (If you specify it along with
multiple tests, they might interfere.)
-You can turn on logging in the unit tests by passing one of "--debug",
-"--info", "--notice", or "--warn". By default only errors are displayed.
+You can turn on logging in the unit tests by passing one of `--debug`,
+`--info`, `--notice`, or `--warn`. By default only errors are displayed.
-Unit tests are divided into "./src/test/test" and "./src/test/test-slow".
+Unit tests are divided into `./src/test/test` and `./src/test/test-slow`.
The former are those that should finish in a few seconds; the latter tend to
take more time, and may include CPU-intensive operations, deliberate delays,
and stuff like that.
-=== Finding test coverage
+### Finding test coverage
Test coverage is a measurement of which lines your tests actually visit.
-When you configure Tor with the --enable-coverage option, it should
+When you configure Tor with the `--enable-coverage` option, it should
build with support for coverage in the unit tests, and in a special
-"tor-cov" binary.
+`tor-cov` binary.
Then, run the tests you'd like to see coverage from. If you have old
-coverage output, you may need to run "reset-gcov" first.
+coverage output, you may need to run `reset-gcov` first.
Now you've got a bunch of files scattered around your build directories
-called "*.gcda". In order to extract the coverage output from them, make a
-temporary directory for them and run "./scripts/test/coverage ${TMPDIR}",
-where ${TMPDIR} is the temporary directory you made. This will create a
-".gcov" file for each source file under tests, containing that file's source
+called `*.gcda`. In order to extract the coverage output from them, make a
+temporary directory for them and run `./scripts/test/coverage ${TMPDIR}`,
+where `${TMPDIR}` is the temporary directory you made. This will create a
+`.gcov` file for each source file under tests, containing that file's source
annotated with the number of times the tests hit each line. (You'll need to
have gcov installed.)
You can get a summary of the test coverage for each file by running
-"./scripts/test/cov-display ${TMPDIR}/*" . Each line lists the file's name,
+`./scripts/test/cov-display ${TMPDIR}/*` . Each line lists the file's name,
the number of uncovered lines, the number of uncovered lines, and the
coverage percentage.
For a summary of the test coverage for each _function_, run
-"./scripts/test/cov-display -f ${TMPDIR}/*" .
+`./scripts/test/cov-display -f ${TMPDIR}/*`.
-=== Comparing test coverage
+### Comparing test coverage
Sometimes it's useful to compare test coverage for a branch you're writing to
coverage from another branch (such as git master, for example). But you
-can't run "diff" on the two coverage outputs directly, since the actual
+can't run `diff` on the two coverage outputs directly, since the actual
number of times each line is executed aren't so important, and aren't wholly
deterministic.
Instead, follow the instructions above for each branch, creating a separate
-temporary directory for each. Then, run "./scripts/test/cov-diff ${D1}
-${D2}", where D1 and D2 are the directories you want to compare. This will
+temporary directory for each. Then, run `./scripts/test/cov-diff ${D1}
+${D2}`, where D1 and D2 are the directories you want to compare. This will
produce a diff of the two directories, with all lines normalized to be either
covered or uncovered.
To count new or modified uncovered lines in D2, you can run:
- "./scripts/test/cov-diff ${D1} ${D2}" | grep '^+ *\#' |wc -l
+ ./scripts/test/cov-diff ${D1} ${D2}" | grep '^+ *\#' | wc -l
What kinds of test should I write?
@@ -132,18 +132,18 @@ Unit and regression tests: Does this function do what it's supposed to?
Most of Tor's unit tests are made using the "tinytest" testing framework.
You can see a guide to using it in the tinytest manual at
- https://github.com/nmathewson/tinytest/blob/master/tinytest-manual.md
+ https://github.com/nmathewson/tinytest/blob/master/tinytest-manual.md
-To add a new test of this kind, either edit an existing C file in src/test/,
+To add a new test of this kind, either edit an existing C file in `src/test/`,
or create a new C file there. Each test is a single function that must
be indexed in the table at the end of the file. We use the label "done:" as
a cleanup point for all test functions.
-(Make sure you read tinytest-manual.md before proceeding.)
+(Make sure you read `tinytest-manual.md` before proceeding.)
I use the term "unit test" and "regression tests" very sloppily here.
-=== A simple example
+### A simple example
Here's an example of a test function for a simple function in util.c:
@@ -172,20 +172,20 @@ Here's an example of a test function for a simple function in util.c:
This should look pretty familiar to you if you've read the tinytest
manual. One thing to note here is that we use the testing-specific
-function "get_fname" to generate a file with respect to a temporary
+function `get_fname` to generate a file with respect to a temporary
directory that the tests use. You don't need to delete the file;
it will get removed when the tests are done.
-Also note our use of OP_EQ instead of == in the tt_int_op() calls.
-We define OP_* macros to use instead of the binary comparison
+Also note our use of `OP_EQ` instead of `==` in the `tt_int_op()` calls.
+We define `OP_*` macros to use instead of the binary comparison
operators so that analysis tools can more easily parse our code.
-(Coccinelle really hates to see == used as a macro argument.)
+(Coccinelle really hates to see `==` used as a macro argument.)
-Finally, remember that by convention, all *_free() functions that
+Finally, remember that by convention, all `*_free()` functions that
Tor defines are defined to accept NULL harmlessly. Thus, you don't
-need to say "if (contents)" in the cleanup block.
+need to say `if (contents)` in the cleanup block.
-=== Exposing static functions for testing
+### Exposing static functions for testing
Sometimes you need to test a function, but you don't want to expose
it outside its usual module.
@@ -193,20 +193,20 @@ it outside its usual module.
To support this, Tor's build system compiles a testing version of
each module, with extra identifiers exposed. If you want to
declare a function as static but available for testing, use the
-macro "STATIC" instead of "static". Then, make sure there's a
+macro `STATIC` instead of `static`. Then, make sure there's a
macro-protected declaration of the function in the module's header.
-For example, crypto_curve25519.h contains:
+For example, `crypto_curve25519.h` contains:
-#ifdef CRYPTO_CURVE25519_PRIVATE
-STATIC int curve25519_impl(uint8_t *output, const uint8_t *secret,
+ #ifdef CRYPTO_CURVE25519_PRIVATE
+ STATIC int curve25519_impl(uint8_t *output, const uint8_t *secret,
const uint8_t *basepoint);
-#endif
+ #endif
-The crypto_curve25519.c file and the test_crypto.c file both define
-CRYPTO_CURVE25519_PRIVATE, so they can see this declaration.
+The `crypto_curve25519.c` file and the `test_crypto.c` file both define
+`CRYPTO_CURVE25519_PRIVATE`, so they can see this declaration.
-=== Mock functions for testing in isolation
+### Mock functions for testing in isolation
Often we want to test that a function works right, but the function to
be tested depends on other functions whose behavior is hard to observe,
@@ -216,7 +216,7 @@ To write tests for this case, you can replace the underlying functions
with testing stubs while your unit test is running. You need to declare
the underlying function as 'mockable', as follows:
- MOCK_DECL(returntype, functionname, (argument list));
+ MOCK_DECL(returntype, functionname, (argument list));
and then later implement it as:
@@ -229,7 +229,7 @@ For example, if you had a 'connect to remote server' function, you could
declare it as:
- MOCK_DECL(int, connect_to_remote, (const char *name, status_t *status));
+ MOCK_DECL(int, connect_to_remote, (const char *name, status_t *status));
When you declare a function this way, it will be declared as normal in
regular builds, but when the module is built for testing, it is declared
@@ -238,16 +238,16 @@ as a function pointer initialized to the actual implementation.
In your tests, if you want to override the function with a temporary
replacement, you say:
- MOCK(functionname, replacement_function_name);
+ MOCK(functionname, replacement_function_name);
And later, you can restore the original function with:
- UNMOCK(functionname);
+ UNMOCK(functionname);
For more information, see the definitions of this mocking logic in
-testsupport.h.
+`testsupport.h`.
-=== Okay but what should my tests actually do?
+### Okay but what should my tests actually do?
We talk above about "test coverage" -- making sure that your tests visit
every line of code, or every branch of code. But visiting the code isn't
@@ -267,11 +267,11 @@ cases and failure csaes.
For example, consider testing this function:
- /** Remove all elements E from sl such that E==element. Preserve
- * the order of any elements before E, but elements after E can be
- * rearranged.
- */
- void smartlist_remove(smartlist_t *sl, const void *element);
+ /** Remove all elements E from sl such that E==element. Preserve
+ * the order of any elements before E, but elements after E can be
+ * rearranged.
+ */
+ void smartlist_remove(smartlist_t *sl, const void *element);
In order to test it well, you should write tests for at least all of the
following cases. (These would be black-box tests, since we're only looking
@@ -298,19 +298,19 @@ When you consider edge cases, you might try:
Now let's look at the implementation:
- void
- smartlist_remove(smartlist_t *sl, const void *element)
- {
- int i;
- if (element == NULL)
- return;
- for (i=0; i < sl->num_used; i++)
- if (sl->list[i] == element) {
- sl->list[i] = sl->list[--sl->num_used]; /* swap with the end */
- i--; /* so we process the new i'th element */
- sl->list[sl->num_used] = NULL;
- }
- }
+ void
+ smartlist_remove(smartlist_t *sl, const void *element)
+ {
+ int i;
+ if (element == NULL)
+ return;
+ for (i=0; i < sl->num_used; i++)
+ if (sl->list[i] == element) {
+ sl->list[i] = sl->list[--sl->num_used]; /* swap with the end */
+ i--; /* so we process the new i'th element */
+ sl->list[sl->num_used] = NULL;
+ }
+ }
Based on the implementation, we now see three more edge cases to test:
@@ -319,14 +319,14 @@ Based on the implementation, we now see three more edge cases to test:
* Removing an element from a position other than the end of the list.
-=== What should my tests NOT do?
+### What should my tests NOT do?
Tests shouldn't require a network connection.
Whenever possible, tests shouldn't take more than a second. Put the test
into test/slow if it genuinely needs to be run.
-Tests should not alter global state unless they run with TT_FORK: Tests
+Tests should not alter global state unless they run with `TT_FORK`: Tests
should not require other tests to be run before or after them.
Tests should not leak memory or other resources. To find out if your tests
@@ -338,16 +338,16 @@ the test should verify that the documented behavior is implemented, but
should not break if other permissible behavior is later implemented.
-=== Advanced techniques: Namespaces
+### Advanced techniques: Namespaces
Sometimes, when you're doing a lot of mocking at once, it's convenient to
isolate your identifiers within a single namespace. If this were C++, we'd
already have namespaces, but for C, we do the best we can with macros and
token-pasting.
-We have some macros defined for this purpose in src/test/test.h. To use
-them, you define NS_MODULE to a prefix to be used for your identifiers, and
-then use other macros in place of identifier names. See src/test/test.h for
+We have some macros defined for this purpose in `src/test/test.h`. To use
+them, you define `NS_MODULE` to a prefix to be used for your identifiers, and
+then use other macros in place of identifier names. See `src/test/test.h` for
more documentation.
@@ -357,19 +357,19 @@ Integration tests: Calling Tor from the outside
Some tests need to invoke Tor from the outside, and shouldn't run from the
same process as the Tor test program. Reasons for doing this might include:
- * Testing the actual behavior of Tor when run from the command line
- * Testing that a crash-handler correctly logs a stack trace
- * Verifying that violating a sandbox or capability requirement will
- actually crash the program.
- * Needing to run as root in order to test capability inheritance or
- user switching.
+ * Testing the actual behavior of Tor when run from the command line
+ * Testing that a crash-handler correctly logs a stack trace
+ * Verifying that violating a sandbox or capability requirement will
+ actually crash the program.
+ * Needing to run as root in order to test capability inheritance or
+ user switching.
-To add one of these, you generally want a new C program in src/test. Add it
-to TESTS and noinst_PROGRAMS if it can run on its own and return success or
+To add one of these, you generally want a new C program in `src/test`. Add it
+to `TESTS` and `noinst_PROGRAMS` if it can run on its own and return success or
failure. If it needs to be invoked multiple times, or it needs to be
-wrapped, add a new shell script to TESTS, and the new program to
-noinst_PROGRAMS. If you need access to any environment variable from the
-makefile (eg ${PYTHON} for a python interpreter), then make sure that the
+wrapped, add a new shell script to `TESTS`, and the new program to
+`noinst_PROGRAMS`. If you need access to any environment variable from the
+makefile (eg `${PYTHON}` for a python interpreter), then make sure that the
makefile exports them.
Writing integration tests with Stem
@@ -379,25 +379,25 @@ The 'stem' library includes extensive unit tests for the Tor controller
protocol.
For more information on writing new tests for stem, have a look around
-the test/* directory in stem, and find a good example to emulate. You
+the `test/*` directory in stem, and find a good example to emulate. You
might want to start with
-https://gitweb.torproject.org/stem.git/tree/test/integ/control/controller.py
+`https://gitweb.torproject.org/stem.git/tree/test/integ/control/controller.py`
to improve Tor's test coverage.
-You can run stem tests from tor with "make test-stem", or see
-https://stem.torproject.org/faq.html#how-do-i-run-the-tests .
+You can run stem tests from tor with `make test-stem`, or see
+`https://stem.torproject.org/faq.html#how-do-i-run-the-tests`.
System testing with Chutney
---------------------------
The 'chutney' program configures and launches a set of Tor relays,
-authorities, and clients on your local host. It has a 'test network'
+authorities, and clients on your local host. It has a `test network`
functionality to send traffic through them and verify that the traffic
arrives correctly.
-You can write new test networks by adding them to 'networks'. To add
-them to Tor's tests, add them to the test-network or test-network-all
-targets in Makefile.am.
+You can write new test networks by adding them to `networks`. To add
+them to Tor's tests, add them to the `test-network` or `test-network-all`
+targets in `Makefile.am`.
(Adding new kinds of program to chutney will still require hacking the
code.)
1
0
commit d9249e2e163af348f49a0405147aec3809ce2a4a
Author: Georg Koppen <gk(a)torproject.org>
Date: Thu Nov 5 11:32:19 2015 +0000
Deprecate old Tor Browser versions
---
projects/torbrowser/RecommendedTBBVersions | 8 --------
1 file changed, 8 deletions(-)
diff --git a/projects/torbrowser/RecommendedTBBVersions b/projects/torbrowser/RecommendedTBBVersions
index 13bd09d..87731c3 100644
--- a/projects/torbrowser/RecommendedTBBVersions
+++ b/projects/torbrowser/RecommendedTBBVersions
@@ -1,12 +1,4 @@
[
-"5.0.3",
-"5.0.3-Linux",
-"5.0.3-MacOS",
-"5.0.3-Windows",
-"5.5a3",
-"5.5a3-Linux",
-"5.5a3-MacOS",
-"5.5a3-Windows",
"5.0.4",
"5.0.4-Linux",
"5.0.4-MacOS",
1
0