[tor-commits] [torspec/main] Proposal 338: Use an 8-byte timestamp in NETINFO cells

2022-03-14 Thread nickm
commit 3b8a1436c962157ac31e926fc16d5ff7e01ccd52
Author: Nick Mathewson 
Date:   Mon Mar 14 12:27:36 2022 -0400

Proposal 338: Use an 8-byte timestamp in NETINFO cells
---
 proposals/000-index.txt|  2 ++
 proposals/338-netinfo-y2038.md | 79 ++
 proposals/BY_INDEX.md  |  1 +
 proposals/README.md|  1 +
 4 files changed, 83 insertions(+)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 40152dd..c078e13 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -258,6 +258,7 @@ Proposals by number:
 335  An authority-only design for MiddleOnly [CLOSED]
 336  Randomized schedule for guard retries [OPEN]
 337  A simpler way to decide, "Is this guard usable?" [OPEN]
+338  Use an 8-byte timestamp in NETINFO cells [OPEN]
 
 
 Proposals by status:
@@ -300,6 +301,7 @@ Proposals by status:
330  Modernizing authority contact entries
336  Randomized schedule for guard retries
337  A simpler way to decide, "Is this guard usable?"
+   338  Use an 8-byte timestamp in NETINFO cells
  ACCEPTED:
265  Load Balancing with Overhead Parameters [for 0.2.9.x]
275  Stop including meaningful "published" time in microdescriptor 
consensus [for 0.3.1.x-alpha]
diff --git a/proposals/338-netinfo-y2038.md b/proposals/338-netinfo-y2038.md
new file mode 100644
index 000..a1a0385
--- /dev/null
+++ b/proposals/338-netinfo-y2038.md
@@ -0,0 +1,79 @@
+```
+Filename: 338-netinfo-y2038.md
+Title: Use an 8-byte timestamp in NETINFO cells
+Author: Nick Mathewson
+Created: 2022-03-14
+Status: Open
+```
+
+# Introduction
+
+Currently Tor relays use a 4-byte timestamp (in seconds since the Unix
+epoch) in their NETINFO cells.  Notoriously, such a timestamp will
+overflow on 19 January 2038.
+
+Let's get ahead of the problem and squash this issue now, by expanding
+the timestamp to 8 bytes. (8 bytes worth of seconds will be long enough
+to outlast the Earth's sun.)
+
+# Proposed change
+
+I propose adding a new link protocol version.  (The next one in
+sequence, as of this writing, is version 6.)
+
+I propose that we change the text of tor-spec section 4.5 from:
+
+```
+  TIME   (Timestamp) [4 bytes]
+```
+
+to
+
+```
+ TIME   (Timestamp) [4 or 8 bytes *]
+```
+
+and specify that this field is 4 bytes wide on link protocols 1-5, but 8
+bytes wide on link protocols 6 and beyond.
+
+# Rejected alternatives
+
+Our protocol specifies that parties MUST ignore extra data at the end of
+cells. Therefore we _could_ add additional data at the end of the
+NETINFO cell, and use that to store the high 4 bytes of the timestamp
+without having to increase the link protocol version number.  I propose
+that we don't do that: it's ugly.
+
+As another alternative, we could declare that parties must interpret the
+timestamp such that its high 4 bytes place it as close as possible to
+their current time.  I'm rejecting this kludge because it would give
+confusing results in the too-common case where clients have their clocks
+mis-set to Jan 1, 1970.
+
+# Impacts on our implementations
+
+Arti won't be able to implement this change until it supports connection
+padding (as required by link protocol 5), which is currently planned for
+the next Arti milestone (1.0.0, scheduled for this fall).
+
+If we think that that's a problem, or if we want to have support for
+implementations without connection padding in the future, we should
+reconsider this plan so that connection padding support is independent
+from 8-byte timestamps.
+
+# Other timestamps in Tor
+
+I've done a cursory search of our protocols to see if we have any other
+instances of the Y2038 problem.
+
+There is a 4-byte timestamp in `cert-spec`, but that one is an unsigned
+integer counting _hours_ since the Unix epoch, which will keep it from
+wrapping around till 478756 C.E. (The rollover date of "10136 CE"
+reported in `cert-spec` is wrong, and seems to be based on the
+misapprehension that the counter is in *minutes*.)
+
+The v2 onion service protocol has 4-byte timestamps, but it is
+thoroughly deprecated and unsupported.
+
+I couldn't find any other 4-byte timestamps, but that is no guarantee:
+others should look for them too.
diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md
index e6bf782..484ad13 100644
--- a/proposals/BY_INDEX.md
+++ b/proposals/BY_INDEX.md
@@ -255,4 +255,5 @@ Below are a list of proposals sorted by their proposal 
number.  See
 * [`335-middle-only-redux.md`](/proposals/335-middle-only-redux.md): An 
authority-only design for MiddleOnly [CLOSED]
 * 
[`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): 
Randomized schedule for guard retries [OPEN]
 * 
[`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): 
A simpler way to decide, "Is this guard usable?" [OPEN]
+* [`338-netinfo-y2038.md`](/proposals/338-netinfo-y2038.md): Use an 8-byte 
timestamp in 

[tor-commits] [torspec/main] Merge remote-tracking branch 'tor-gitlab/mr/60'

2022-02-24 Thread nickm
commit 80e9d9e7dbbc3642a7e93946f48b5fa2fc568b3f
Merge: 71c326a fa940c0
Author: Nick Mathewson 
Date:   Thu Feb 24 10:54:05 2022 -0500

Merge remote-tracking branch 'tor-gitlab/mr/60'

 proposals/332-ntor-v3-with-extra-data.md | 28 +++-
 rend-spec-v3.txt | 27 ++-
 2 files changed, 45 insertions(+), 10 deletions(-)

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] ntor3, rend3: clarify extension field defaults.

2022-02-24 Thread nickm
commit 176c9001f962848751bedfff9bade4aa58319714
Author: Nick Mathewson 
Date:   Thu Feb 17 10:53:20 2022 -0500

ntor3, rend3: clarify extension field defaults.

These patch changes describe new default behaviors for extension
field lists, as appear in ntor3 and in many places throughout the
ntor3 protocol.  In general:

* Unrecognized extensions MUST be ignored.

Additionally, all the following rules apply _unless otherwise stated
in the documentation for an extension.

* Extensions are sent in sorted order.
* Extensions should only be sent once in a message
* If you receive multiple copies of an extension, only the first
  one counts.

This comes out of discussions on tor!525.
---
 proposals/332-ntor-v3-with-extra-data.md | 28 ++--
 rend-spec-v3.txt | 26 +-
 2 files changed, 43 insertions(+), 11 deletions(-)

diff --git a/proposals/332-ntor-v3-with-extra-data.md 
b/proposals/332-ntor-v3-with-extra-data.md
index 4e55713..8e6dedc 100644
--- a/proposals/332-ntor-v3-with-extra-data.md
+++ b/proposals/332-ntor-v3-with-extra-data.md
@@ -338,20 +338,28 @@ We use the following meta-encoding for the contents of 
client and
 server messages.
 
 [Any number of times]:
-   TYPE [one byte]
-   LEN  [one byte]
-   BODY [LEN bytes]
-
-We do not specify specific TYPE semantics here; we leave those for
-other proposals.
+EXTENSION
+   EXT_FIELD_TYPE [one byte]
+   EXT_FIELD_LEN  [one byte]
+   EXT_FIELD  [EXT_FIELD_LEN bytes]
 
 All parties MUST reject messages that are not well-formed per the
 rules above.
 
-To avoid partitioning, clients MUST reject messages with TYPEs that
-they do not recognize.  (Therefore, whenever we specify a new server
-message TYPE, we must say that it can only be included if the client
-signals that it understands it.)
+We do not specify specific TYPE semantics here; we leave those for
+other proposals and specifications.
+
+Parties MUST ignore extensions with `EXT_FIELD_TYPE` bodies they do not
+recognize.
+
+Unless otherwise specified in the documentation for an extension type:
+* Each extension type SHOULD be sent only once in a message.
+* Parties MUST ignore any occurrences all occurrences of an extension
+  with a given type after the first such occurrence.
+* Extensions SHOULD be sent in numerically ascending order by type.
+
+(The above extension sorting and multiplicity rules are only defaults;
+they may be overridden in the description of individual extensions.)
 
 # A.3 How much space is available?
 
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt
index 6a120eb..1a0b945 100644
--- a/rend-spec-v3.txt
+++ b/rend-spec-v3.txt
@@ -1548,9 +1548,17 @@ Table of contents:
authentication key.
 
The EXT_FIELD_TYPE, EXT_FIELD_LEN, EXT_FIELD entries are reserved for
-   future extensions to the introduction protocol. Extensions with
+   extensions to the introduction protocol. Extensions with
unrecognized EXT_FIELD_TYPE values must be ignored.
 
+   Unless otherwise specified in the documentation for an extension type:
+  * Each extension type SHOULD be sent only once in a message.
+  * Parties MUST ignore any occurrences all occurrences of an extension
+with a given type after the first such occurrence.
+  * Extensions SHOULD be sent in numerically ascending order by type.
+   (The above extension sorting and multiplicity rules are only defaults;
+   they may be overridden in the descriptions of individual extensions.)
+
The HANDSHAKE_AUTH field contains the MAC of all earlier fields in
the cell using as its key the shared per-circuit material ("KH")
generated during the circuit extension protocol; see tor-spec.txt
@@ -1685,6 +1693,10 @@ Table of contents:
Older versions of Tor send back an empty INTRO_ESTABLISHED cell instead.
Services must accept an empty INTRO_ESTABLISHED cell from a legacy relay.
 
+   The same rules for multiplicity, ordering, and handling unknown types
+   apply to the extension fields here as described [EST_INTRO] above.
+
+
 3.2. Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1]
 
In order to participate in the introduction protocol, a client must
@@ -1737,6 +1749,10 @@ Table of contents:
INTRODUCE2 cell with exactly the same contents to the service, and sends an
INTRODUCE_ACK response to the client.
 
+   The same rules for multiplicity, ordering, and handling unknown types
+   apply to the extension fields here as described [EST_INTRO] above.
+
+
 3.2.2. INTRODUCE_ACK cell format. [INTRO_ACK]
 
An INTRODUCE_ACK cell has the following fields:
@@ -1755,6 +1771,10 @@ Table of contents:
  [00 02] -- Bad message format
  [00 03] -- Can't relay cell to service
 
+   The same rules for multiplicity, ordering, and handling unknown types
+   apply to the extension fields here as 

[tor-commits] [torspec/main] Be explicit about EXT_FIELD_LEN=0

2022-02-24 Thread nickm
commit fa940c0d9e30d52b168d0ee64bec08c0a88f4edb
Author: Nick Mathewson 
Date:   Thu Feb 17 16:16:15 2022 -0500

Be explicit about EXT_FIELD_LEN=0
---
 proposals/332-ntor-v3-with-extra-data.md | 2 ++
 rend-spec-v3.txt | 1 +
 2 files changed, 3 insertions(+)

diff --git a/proposals/332-ntor-v3-with-extra-data.md 
b/proposals/332-ntor-v3-with-extra-data.md
index 8e6dedc..25ae0ba 100644
--- a/proposals/332-ntor-v3-with-extra-data.md
+++ b/proposals/332-ntor-v3-with-extra-data.md
@@ -343,6 +343,8 @@ server messages.
EXT_FIELD_LEN  [one byte]
EXT_FIELD  [EXT_FIELD_LEN bytes]
 
+(`EXT_FIELD_LEN` may be zero, in which case EXT_FIELD is absent.)
+
 All parties MUST reject messages that are not well-formed per the
 rules above.
 
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt
index 1a0b945..fac1395 100644
--- a/rend-spec-v3.txt
+++ b/rend-spec-v3.txt
@@ -1550,6 +1550,7 @@ Table of contents:
The EXT_FIELD_TYPE, EXT_FIELD_LEN, EXT_FIELD entries are reserved for
extensions to the introduction protocol. Extensions with
unrecognized EXT_FIELD_TYPE values must be ignored.
+   (`EXT_FIELD_LEN` may be zero, in which case EXT_FIELD is absent.)
 
Unless otherwise specified in the documentation for an extension type:
   * Each extension type SHOULD be sent only once in a message.



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Update unstable links to use Web Archive

2022-02-07 Thread nickm
commit 88a7482047f23aef9642d2977a051265df0c686d
Author: n_user <465f5d21-fbad-4466-a525-e21c6a62b...@aleeas.com>
Date:   Thu Feb 3 14:34:31 2022 +

Update unstable links to use Web Archive
---
 contrib/operator-tools/tor-exit-notice.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/operator-tools/tor-exit-notice.html 
b/contrib/operator-tools/tor-exit-notice.html
index ddcf4e952a..994f42d91b 100644
--- a/contrib/operator-tools/tor-exit-notice.html
+++ b/contrib/operator-tools/tor-exit-notice.html
@@ -261,9 +261,9 @@ href="https://support.torproject.org/abuse/;>abuse is 
quite low. This
 is largely because criminals and hackers have significantly better access to
 privacy and anonymity than do the regular users whom they prey upon. Criminals
 can and do https://voices.washingtonpost.com/securityfix/2008/08/web_fraud_20_tools.html;>build,
+href="https://web.archive.org/web/20211202194841/http://voices.washingtonpost.com/securityfix/2008/08/web_fraud_20_tools.html;>build,
 sell, and trade far larger and https://voices.washingtonpost.com/securityfix/2008/08/web_fraud_20_distributing_your.html;>more
+href="https://web.archive.org/web/20211202194839/https://voices.washingtonpost.com/securityfix/2008/08/web_fraud_20_distributing_your.html;>more
 powerful networks than Tor on a daily basis. Thus, in the mind of this
 operator, the social need for easily accessible censorship-resistant private,
 anonymous communication trumps the risk of unskilled bad actors, who are



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Add a changes file for exit notice redesign (40529)

2022-02-07 Thread nickm
commit 9e86491cf861ac1beb9b92bc231f049415b8ed69
Author: Nick Mathewson 
Date:   Mon Feb 7 11:37:50 2022 -0500

Add a changes file for exit notice redesign (40529)
---
 changes/ticket40529 | 5 +
 1 file changed, 5 insertions(+)

diff --git a/changes/ticket40529 b/changes/ticket40529
new file mode 100644
index 00..5b3a18a180
--- /dev/null
+++ b/changes/ticket40529
@@ -0,0 +1,5 @@
+  o Documentation:
+- Provide an improved version of the tor-exit-notice.html file for
+  exit relays to use as a landing page.  The text is unchanged,
+  but the page design and layout are significantly modernized, and
+  several links are fixed.  Patch from "n_user"; closes ticket 40529.

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Use more stable Web Archive links

2022-02-07 Thread nickm
commit 6ad5232ef57c85224d35baef2e7ef67d20aeb2e2
Author: n_user <465f5d21-fbad-4466-a525-e21c6a62b...@aleeas.com>
Date:   Sun Feb 6 21:20:22 2022 +

Use more stable Web Archive links
---
 contrib/operator-tools/tor-exit-notice.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/operator-tools/tor-exit-notice.html 
b/contrib/operator-tools/tor-exit-notice.html
index 994f42d91b..cedb3cb353 100644
--- a/contrib/operator-tools/tor-exit-notice.html
+++ b/contrib/operator-tools/tor-exit-notice.html
@@ -261,9 +261,9 @@ href="https://support.torproject.org/abuse/;>abuse is 
quite low. This
 is largely because criminals and hackers have significantly better access to
 privacy and anonymity than do the regular users whom they prey upon. Criminals
 can and do https://web.archive.org/web/20211202194841/http://voices.washingtonpost.com/securityfix/2008/08/web_fraud_20_tools.html;>build,
+href="https://web.archive.org/web/20200131013910/http://voices.washingtonpost.com/securityfix/2008/08/web_fraud_20_tools.html;>build,
 sell, and trade far larger and https://web.archive.org/web/20211202194839/https://voices.washingtonpost.com/securityfix/2008/08/web_fraud_20_distributing_your.html;>more
+href="https://web.archive.org/web/20200131013908/http://voices.washingtonpost.com/securityfix/2008/08/web_fraud_20_distributing_your.html;>more
 powerful networks than Tor on a daily basis. Thus, in the mind of this
 operator, the social need for easily accessible censorship-resistant private,
 anonymous communication trumps the risk of unskilled bad actors, who are



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Merge remote-tracking branch 'tor-gitlab/mr/522'

2022-02-07 Thread nickm
commit b79641fbe4208677249953c88d171a84dd5f9c2b
Merge: 4c1a9b335f 6ad5232ef5
Author: Nick Mathewson 
Date:   Mon Feb 7 11:35:12 2022 -0500

Merge remote-tracking branch 'tor-gitlab/mr/522'

 contrib/operator-tools/tor-exit-notice.html | 437 +++-
 1 file changed, 237 insertions(+), 200 deletions(-)



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Redesign tor-exit-notice

2022-02-07 Thread nickm
commit efecc36148e2d896cded5b29e20838e45381dcee
Author: n_user <465f5d21-fbad-4466-a525-e21c6a62b...@aleeas.com>
Date:   Wed Feb 2 00:33:22 2022 +

Redesign tor-exit-notice
---
 contrib/operator-tools/tor-exit-notice.html | 437 +++-
 1 file changed, 237 insertions(+), 200 deletions(-)

diff --git a/contrib/operator-tools/tor-exit-notice.html 
b/contrib/operator-tools/tor-exit-notice.html
index 278d3de502..ddcf4e952a 100644
--- a/contrib/operator-tools/tor-exit-notice.html
+++ b/contrib/operator-tools/tor-exit-notice.html
@@ -1,18 +1,17 @@
-
-http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
-http://www.w3.org/1999/xhtml;>
+
+
 
-
+
 This is a Tor Exit Router
-
+
+
 
+
+:root{
+--background-color: white;
+--text-color: rgb(33, 37, 41);
+--link-color: rgb(116, 42, 152);
+}
+@media (prefers-color-scheme: dark){
+:root{
+--background-color: rgb(34, 34, 34);
+--text-color: rgb(221, 221, 221);
+--link-color: rgb(219, 142, 255);
+}
+}
+*{
+font-family: Arial;
+box-sizing: border-box;
+}
+html{
+background: var(--background-color);
+}
+body{
+margin-left: auto;
+margin-right: auto;
+padding-left: 5vw;
+padding-right: 5vw;
+max-width: 1000px;
+}
+h1, p{
+color: var(--text-color);
+}
+h1{
+font-size: 55px;
+text-align: center;
+}
+p, a{
+font-size: 20px;
+}
+a{
+color: var(--link-color);
+text-decoration: none;
+}
+a:hover{
+filter: brightness(.8);
+text-decoration: underline;
+}
+.links{
+display: flex;
+flex-wrap: wrap;
+justify-content: space-evenly;
+}
+.links > a{
+margin: 10px;
+white-space: nowrap;
+}
+
 
 
 
-
-This is a
-Tor Exit Router
+
+This is a Tor Exit Router
+
+http://www.w3.org/2000/svg; width="500" viewBox="0 0 274.3 159.9" 
style="width:100%;max-width:500px">
+
+
+
+.a{fill:none}.b,.e{fill:#895ba5}.b{stroke:#895ba5}.j,.l,.m,.o,.b,.d{stroke-miterlimit:10}.l,.b{stroke-width:.75px}.k,.c,.f{fill:#24093b}.a,.c,.f{stroke:#24093b;stroke-linecap:round;stroke-linejoin:round}.m,.o,.c,.d{stroke-width:.5px}.i,.j,.d{fill:#6fc8b7}.j,.d{stroke:#6fc8b7}.l,.m,.g{fill:#fed916}.h{fill:#fff}.a{stroke-width:1.6px}.j{stroke-width:.68px}.l,.m{stroke:#fed916}.n,.o{fill:#cf63a6}.o{stroke:#cf63a6}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
-Most likely you are accessing this website because you had some issue with
+You are most likely accessing this website because you've had some issue with
 the traffic coming from this IP. This router is part of the https://www.torproject.org/;>Tor Anonymity Network, which is
-dedicated to https://www.torproject.org/about/overview;>providing
+dedicated to https://2019.www.torproject.org/about/overview;>providing
 privacy to people who need it most: average computer users. This
 router IP should be generating no other traffic, unless it has been
 compromised.
 
-
-https://www.torproject.org/about/overview;>
-
-
+
+Tor works by running user traffic through a random chain of encrypted
+servers, and then letting the traffic exit the Tor network through an
+exit node like this one. This design makes it very hard for a service to
+know which user is connecting to it, since it can only see the IP-address
+of the Tor exit node:
+
+
+http://www.w3.org/2000/svg; width="500" viewBox="0 0 490.28 
293.73" style="width:100%;max-width:600px">
+Illustration showing how a user might connect to a service through the 
Tor network. The user first sends their data through three daisy-chained 
encrypted Tor servers that exist on three different continents. Then the last 
Tor server in the chain connects to the target service over the normal 
internet.
+
+
+.t{
+fill: var(--text-color);
+stroke: var(--text-color);
+}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+The user
+This server
+Your service
+Tor encrypted link
+Unencrypted link
+
+
+
+
+
+
+
+
+
+https://2019.www.torproject.org/about/overview;>Read more about how 
Tor works.
 
 
-Tor sees use by https://www.torproject.org/about/torusers;>many
+Tor sees use by https://2019.www.torproject.org/about/torusers;>many
 important segments of the population, including whistle blowers,
 journalists, Chinese dissidents skirting the Great Firewall and oppressive
 censorship, abuse victims, stalker targets, the US military, and law
 enforcement, just to name a few.  While Tor is not designed for malicious
 computer users, it is true that they can use the network for malicious ends.
 In reality however, the actual amount of https://www.torproject.org/docs/faq-abuse;>abuse is quite low. This
+href="https://support.torproject.org/abuse/;>abuse is quite low. This
 is largely because criminals and hackers have significantly better access to
 privacy and anonymity than do the regular users whom they prey upon. Criminals
 can and do http://voices.washingtonpost.com/securityfix/2008/08/web_fraud_20_tools.html;>build,

[tor-commits] [tor/main] Resolve typedef conflict from congestion_control_t

2022-01-20 Thread nickm
commit 935d7b58031081835cee513ee8551a51ab6cf3c7
Author: Nick Mathewson 
Date:   Thu Jan 20 14:22:00 2022 -0500

Resolve typedef conflict from congestion_control_t

Resumes being able to build on old / esoteric gcc versions.

Fixes bug 40550; bugfix on 0.4.7.1-alpha.
---
 changes/bug40550| 3 +++
 src/core/or/congestion_control_st.h | 8 
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/changes/bug40550 b/changes/bug40550
new file mode 100644
index 00..3f829d3794
--- /dev/null
+++ b/changes/bug40550
@@ -0,0 +1,3 @@
+  o Minor bugfixes (compilation):
+- Resume being able to build on old / esoteric gcc versions. Fixes
+  bug 40550; bugfix on 0.4.7.1-alpha.
diff --git a/src/core/or/congestion_control_st.h 
b/src/core/or/congestion_control_st.h
index 251ebd82e3..6038072568 100644
--- a/src/core/or/congestion_control_st.h
+++ b/src/core/or/congestion_control_st.h
@@ -115,7 +115,7 @@ struct nola_params_t {
 };
 
 /** Fields common to all congestion control algorithms */
-typedef struct congestion_control_t {
+struct congestion_control_t {
   /**
* Smartlist of uint64_t monotime usec timestamps of when we sent a data
* cell that is pending a sendme. FIFO queue that is managed similar to
@@ -209,7 +209,7 @@ typedef struct congestion_control_t {
 struct vegas_params_t vegas_params;
 struct nola_params_t nola_params;
   };
-} congestion_control_t;
+};
 
 /**
  * Returns the number of sendme acks we will recieve before we update cwnd.
@@ -221,7 +221,7 @@ typedef struct congestion_control_t {
  * If this returns 0 due to high cwnd_inc_rate, the calling code will
  * update every sendme ack.
  */
-static inline uint64_t CWND_UPDATE_RATE(const congestion_control_t *cc)
+static inline uint64_t CWND_UPDATE_RATE(const struct congestion_control_t *cc)
 {
   /* We add cwnd_inc_rate*sendme_inc/2 to round to nearest integer number
* of acks */
@@ -241,7 +241,7 @@ static inline uint64_t CWND_UPDATE_RATE(const 
congestion_control_t *cc)
  * allows us to specify the percent of the current consensus window
  * to update by.
  */
-static inline uint64_t CWND_INC_SS(const congestion_control_t *cc)
+static inline uint64_t CWND_INC_SS(const struct congestion_control_t *cc)
 {
   return (cc->cwnd_inc_pct_ss*cc->cwnd/100);
 }



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Use an alternative solution to the warning in trace_probes_cc.c

2022-01-20 Thread nickm
commit 7a3d60d4712f9e8c5f2d39dce93ee31caf1d0a21
Author: Nick Mathewson 
Date:   Thu Jan 20 14:46:38 2022 -0500

Use an alternative solution to the warning in trace_probes_cc.c
---
 src/core/or/trace_probes_cc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/core/or/trace_probes_cc.c b/src/core/or/trace_probes_cc.c
index d52646da4f..b0ca23e208 100644
--- a/src/core/or/trace_probes_cc.c
+++ b/src/core/or/trace_probes_cc.c
@@ -19,6 +19,7 @@
 #include "core/or/channel.h"
 #include "core/or/circuit_st.h"
 #include "core/or/circuitlist.h"
+#include "core/or/congestion_control_common.h"
 #include "core/or/congestion_control_st.h"
 #include "core/or/connection_st.h"
 #include "core/or/edge_connection_st.h"

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] gitlab-ci: default branch is now main

2021-12-22 Thread nickm
commit bdb862ff7326c52e3f407811dd8af148f92d76aa
Author: Hans-Christoph Steiner 
Date:   Wed Dec 22 09:06:03 2021 +0100

gitlab-ci: default branch is now main
---
 .gitlab-ci.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index d40f0e1..6f56955 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -49,4 +49,4 @@ pages:
 paths:
 - public
   only:
-- master
+- main

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] fix syntax errors listed by cppcheck

2021-12-16 Thread nickm
commit a86918d524806d34cbcac9c42fc7616ddc4a5fd1
Author: Hans-Christoph Steiner 
Date:   Tue Dec 10 22:44:43 2019 +0100

fix syntax errors listed by cppcheck
---
 src/ext/ed25519/donna/test-ticks.h | 4 ++--
 src/feature/client/entrynodes.c| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/ext/ed25519/donna/test-ticks.h 
b/src/ext/ed25519/donna/test-ticks.h
index 0103e03dde..16cec9ba92 100644
--- a/src/ext/ed25519/donna/test-ticks.h
+++ b/src/ext/ed25519/donna/test-ticks.h
@@ -13,7 +13,7 @@ get_ticks(void) {
__asm__ __volatile__("rdtsc" : "=a" (lo), "=d" (hi));
return ((uint64_t)lo | ((uint64_t)hi << 32));
#else
-   need rdtsc for this compiler
+   #error need rdtsc for this compiler
#endif
 #elif defined(OS_SOLARIS)
return (uint64_t)gethrtime();
@@ -35,7 +35,7 @@ get_ticks(void) {
t = ((uint64_t)t2.tv_usec << 32) | (uint64_t)t2.tv_sec;
return t;
 #else
-   need ticks for this platform
+   #error need ticks for this platform
 #endif
 }
 
diff --git a/src/feature/client/entrynodes.c b/src/feature/client/entrynodes.c
index 32ecb4f705..15f29d1c3e 100644
--- a/src/feature/client/entrynodes.c
+++ b/src/feature/client/entrynodes.c
@@ -2743,7 +2743,7 @@ entry_guards_upgrade_waiting_circuits(guard_selection_t 
*gs,
   {NONPRIMARY_GUARD_CONNECT_TIMEOUT} seconds."
 */
 circuit_guard_state_t *state = origin_circuit_get_guard_state(circ);
-if BUG((state == NULL))
+if (BUG(state == NULL))
   continue;
 if (state->state != GUARD_CIRC_STATE_COMPLETE)
   continue;



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Merge remote-tracking branch 'tor-gitlab/mr/504'

2021-12-16 Thread nickm
commit 5591a3bcd6f80ab301e8750930de1c7bca78387c
Merge: ecffdb0b17 a86918d524
Author: Nick Mathewson 
Date:   Thu Dec 16 12:36:35 2021 -0500

Merge remote-tracking branch 'tor-gitlab/mr/504'

 src/ext/ed25519/donna/test-ticks.h | 4 ++--
 src/feature/client/entrynodes.c| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Merge remote-tracking branch 'tor-gitlab/mr/498'

2021-12-13 Thread nickm
commit b8e6eb62364eecfbaec5bcd14fe887ee64a1daef
Merge: b4c55f3a70 3f016bba12
Author: Nick Mathewson 
Date:   Mon Dec 13 10:47:39 2021 -0500

Merge remote-tracking branch 'tor-gitlab/mr/498'

 scripts/README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Fix scripts/README file

2021-12-13 Thread nickm
commit 3f016bba1239a8a0ac1c09e975e3d27da0057549
Author: skaluzka 
Date:   Tue Sep 28 22:07:59 2021 +0200

Fix scripts/README file

Use "update_versions.py" instead of "updateVersions.pl" as a tool
for updating version numbers.

Signed-off-by: skaluzka 
---
 scripts/README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/README b/scripts/README
index 9cd6e74ac7..7de0d003e4 100644
--- a/scripts/README
+++ b/scripts/README
@@ -23,7 +23,7 @@ maint/format_changelog.py -- Flow the changelog into the 
proper format.
 maint/redox.py -- Find places that should have DOCDOC comments to indicate a
 need for doxygen comments, and put those comments there.
 
-maint/updateVersions.pl -- Update the version number in the .nsi and windows
+maint/update_versions.py -- Update the version number in the .nsi and windows
 orconfig.h files.
 
 



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Clarify the behavior of some circuit timeout params.

2021-12-08 Thread nickm
commit 0911bbd0cdb5459dd0eb948694f98066712cd084
Author: Nick Mathewson 
Date:   Wed Dec 8 11:10:05 2021 -0500

Clarify the behavior of some circuit timeout params.

In particular, this commit clarifies that the ranges of some
parameters are such that choosing a very high value will, in effect,
disable parts of the circuit timeout inference code.
---
 path-spec.txt | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/path-spec.txt b/path-spec.txt
index 4422be4..33d50e5 100644
--- a/path-spec.txt
+++ b/path-spec.txt
@@ -633,8 +633,8 @@ Tables of Contents
 Default: 20
 Min: 3
 Max: 1000
-Effect: This is the number of circuit build times to keep track of
-for the following option.
+Effect: This is the number of circuit build outcomes (success vs
+timeout) to keep track of for the following option.
 
   cbtmaxtimeouts
 Default: 18
@@ -644,6 +644,10 @@ Tables of Contents
 circuit attempts, the client should discard all of its
 history and begin learning a fresh timeout value.
 
+Note that if this parameter's value is greater than the value
+of 'cbtrecentcount', then the history will never be
+discarded because of this feature.
+
   cbtmincircs
 Default: 100
 Min: 1
@@ -651,6 +655,12 @@ Tables of Contents
 Effect: This is the minimum number of circuits to build before
 computing a timeout.
 
+Note that if this parameter's value is higher than 1000 (the
+number of time observations that a client keeps in its
+circular buffer), circuit build timeout calculation is
+effectively disabled, and the default timeouts are used
+indefinitely.
+
   cbtquantile
 Default: 80
 Min: 10

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Don't kill managed proxy on method error

2021-11-23 Thread nickm
commit 809b636b6ec9039262c1feb874a9d167046bf515
Author: Cecylia Bocovich 
Date:   Fri Nov 19 14:50:36 2021 -0500

Don't kill managed proxy on method error

Some PT applications support more than one transport. For example,
obfs4proxy supports obfs4, obfs3, and meek. If one or more transports
specified in the torrc file are supported, we shouldn't kill the managed
proxy on a {C,S}METHOD-ERROR. Instead, we should log a warning.

We were already logging warnings on method errors. This change just
makes sure that the managed proxy isn't killed, and then if no
transports are configured for the managed proxy, bumps the log level up
from a notice to a warning.

Closes #7362
---
 src/feature/client/transports.c | 6 +++---
 src/test/test_pt.c  | 4 
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/feature/client/transports.c b/src/feature/client/transports.c
index 167beb96c6..5eda63ce8e 100644
--- a/src/feature/client/transports.c
+++ b/src/feature/client/transports.c
@@ -843,7 +843,7 @@ handle_methods_done(const managed_proxy_t *mp)
   tor_assert(mp->transports);
 
   if (smartlist_len(mp->transports) == 0)
-log_notice(LD_GENERAL, "Managed proxy '%s' was spawned successfully, "
+log_warn(LD_GENERAL, "Managed proxy '%s' was spawned successfully, "
"but it didn't launch any pluggable transport listeners!",
mp->argv[0]);
 
@@ -904,13 +904,13 @@ handle_proxy_line(const char *line, managed_proxy_t *mp)
   goto err;
 
 parse_client_method_error(line);
-goto err;
+return;
   } else if (!strcmpstart(line, PROTO_SMETHOD_ERROR)) {
 if (mp->conf_state != PT_PROTO_ACCEPTING_METHODS)
   goto err;
 
 parse_server_method_error(line);
-goto err;
+return;
   } else if (!strcmpstart(line, PROTO_CMETHOD)) {
 if (mp->conf_state != PT_PROTO_ACCEPTING_METHODS)
   goto err;
diff --git a/src/test/test_pt.c b/src/test/test_pt.c
index 27e74d5ebf..07c5032933 100644
--- a/src/test/test_pt.c
+++ b/src/test/test_pt.c
@@ -233,6 +233,10 @@ test_pt_protocol(void *arg)
   handle_proxy_line(line, mp);
   tt_assert(mp->conf_state == PT_PROTO_ACCEPTING_METHODS);
 
+  strlcpy(line,"CMETHOD-ERROR fakename not supported",sizeof(line));
+  handle_proxy_line(line, mp);
+  tt_assert(mp->conf_state == PT_PROTO_ACCEPTING_METHODS);
+
   strlcpy(line,"CMETHODS DONE",sizeof(line));
   handle_proxy_line(line, mp);
   tt_assert(mp->conf_state == PT_PROTO_CONFIGURED);



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] changes: Describe when bug 7362 began.

2021-11-23 Thread nickm
commit b4c55f3a700b9c071c7f8466499ed9cf5ef76fc7
Author: Nick Mathewson 
Date:   Tue Nov 23 11:28:30 2021 -0500

changes: Describe when bug 7362 began.
---
 changes/ticket7362 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/changes/ticket7362 b/changes/ticket7362
index fd64350465..4df58e048a 100644
--- a/changes/ticket7362
+++ b/changes/ticket7362
@@ -1,4 +1,4 @@
   o Minor bugfix (pluggable transport):
 - Do not kill a managed proxy if one of its transport configurations
   emits a method error. Instead log a warning and continue processing
-  method arguments. Closes ticket 7362.
+  method arguments. Fixes bug 7362; bugfix on 0.2.3.6-alpha.

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Add documentation on {C, S}METHOD parsing behaviour

2021-11-23 Thread nickm
commit 0d3894dbbcde9f45fbbf53c451c8b1c4d290280c
Author: Cecylia Bocovich 
Date:   Tue Nov 23 10:40:43 2021 -0500

Add documentation on {C,S}METHOD parsing behaviour
---
 changes/ticket7362  | 4 
 src/feature/client/transports.c | 8 
 2 files changed, 12 insertions(+)

diff --git a/changes/ticket7362 b/changes/ticket7362
new file mode 100644
index 00..fd64350465
--- /dev/null
+++ b/changes/ticket7362
@@ -0,0 +1,4 @@
+  o Minor bugfix (pluggable transport):
+- Do not kill a managed proxy if one of its transport configurations
+  emits a method error. Instead log a warning and continue processing
+  method arguments. Closes ticket 7362.
diff --git a/src/feature/client/transports.c b/src/feature/client/transports.c
index 5eda63ce8e..80903ac9e5 100644
--- a/src/feature/client/transports.c
+++ b/src/feature/client/transports.c
@@ -903,12 +903,20 @@ handle_proxy_line(const char *line, managed_proxy_t *mp)
 if (mp->conf_state != PT_PROTO_ACCEPTING_METHODS)
   goto err;
 
+/* Log the error but do not kill the managed proxy.
+ * A proxy may contain several transports and if one
+ * of them is misconfigured, we still want to use
+ * the other transports. A managed proxy with no usable
+ * transports will log a warning.
+ * See https://gitlab.torproject.org/tpo/core/tor/-/issues/7362
+ * */
 parse_client_method_error(line);
 return;
   } else if (!strcmpstart(line, PROTO_SMETHOD_ERROR)) {
 if (mp->conf_state != PT_PROTO_ACCEPTING_METHODS)
   goto err;
 
+/* Log the error but do not kill the managed proxy */
 parse_server_method_error(line);
 return;
   } else if (!strcmpstart(line, PROTO_CMETHOD)) {



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Update status for the two middle-only proposals.

2021-11-22 Thread nickm
commit 583d028d4a637e1c0eabeb331a3a8bf4d775d15d
Author: Nick Mathewson 
Date:   Mon Nov 22 10:08:59 2021 -0500

Update status for the two middle-only proposals.

334 is superseded by 335, which is Finished but not Closed.
---
 proposals/000-index.txt| 8 
 proposals/334-middle-only-flag.txt | 3 ++-
 proposals/335-middle-only-redux.md | 3 ++-
 proposals/BY_INDEX.md  | 4 ++--
 proposals/README.md| 4 ++--
 5 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 0f61f92..abd833a 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -254,8 +254,8 @@ Proposals by number:
 331  Res tokens: Anonymous Credentials for Onion Service DoS Resilience [DRAFT]
 332  Ntor protocol with extra data, version 3 [ACCEPTED]
 333  Vanguards lite [FINISHED]
-334  A Directory Authority Flag To Mark Relays As Middle-only [OPEN]
-335  An authority-only design for MiddleOnly [OPEN]
+334  A Directory Authority Flag To Mark Relays As Middle-only [SUPERSEDED]
+335  An authority-only design for MiddleOnly [FINISHED]
 336  Randomized schedule for guard retries [OPEN]
 337  A simpler way to decide, "Is this guard usable?" [OPEN]
 
@@ -298,8 +298,6 @@ Proposals by status:
325  Packed relay cells: saving space on small commands
326  The "tor-relay" Well-Known Resource Identifier
330  Modernizing authority contact entries
-   334  A Directory Authority Flag To Mark Relays As Middle-only
-   335  An authority-only design for MiddleOnly
336  Randomized schedule for guard retries
337  A simpler way to decide, "Is this guard usable?"
  ACCEPTED:
@@ -323,6 +321,7 @@ Proposals by status:
  FINISHED:
260  Rendezvous Single Onion Services [in 0.2.9.3-alpha]
333  Vanguards lite [in 0.4.7.1-alpha]
+   335  An authority-only design for MiddleOnly [in 0.4.7.2-alpha]
  CLOSED:
101  Voting on the Tor Directory System [in 0.2.0.x]
102  Dropping "opt" from the directory format [in 0.2.0.x]
@@ -449,6 +448,7 @@ Proposals by status:
266  Removing current obsolete clients from the Tor network
280  Privacy-Preserving Statistics with Privcount in Tor
299  Preferring IPv4 or IPv6 based on IP Version Failure Count
+   334  A Directory Authority Flag To Mark Relays As Middle-only
  DEAD:
100  Tor Unreliable Datagram Extension Proposal
115  Two Hop Paths
diff --git a/proposals/334-middle-only-flag.txt 
b/proposals/334-middle-only-flag.txt
index ed5de42..823e927 100644
--- a/proposals/334-middle-only-flag.txt
+++ b/proposals/334-middle-only-flag.txt
@@ -2,7 +2,8 @@ Filename: 334-middle-only-flag.txt
 Title: A Directory Authority Flag To Mark Relays As Middle-only
 Author: Neel Chauhan
 Created: 2021-09-07
-Status: Open
+Status: Superseded
+Superseded-by: 335-middle-only-redux.md
 
 1. Introduction
 
diff --git a/proposals/335-middle-only-redux.md 
b/proposals/335-middle-only-redux.md
index 3329afe..c87f37d 100644
--- a/proposals/335-middle-only-redux.md
+++ b/proposals/335-middle-only-redux.md
@@ -3,7 +3,8 @@ Filename: 335-middle-only-redux.md
 Title: An authority-only design for MiddleOnly
 Author: Nick Mathewson
 Created: 2021-10-08
-Status: Open
+Status: Finished
+Implemented-In: 0.4.7.2-alpha
 ```
 
 # Introduction
diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md
index b31fac4..da77281 100644
--- a/proposals/BY_INDEX.md
+++ b/proposals/BY_INDEX.md
@@ -251,8 +251,8 @@ Below are a list of proposals sorted by their proposal 
number.  See
 * 
[`331-res-tokens-for-anti-dos.md`](/proposals/331-res-tokens-for-anti-dos.md): 
Res tokens: Anonymous Credentials for Onion Service DoS Resilience [DRAFT]
 * 
[`332-ntor-v3-with-extra-data.md`](/proposals/332-ntor-v3-with-extra-data.md): 
Ntor protocol with extra data, version 3 [ACCEPTED]
 * [`333-vanguards-lite.md`](/proposals/333-vanguards-lite.md): Vanguards lite 
[FINISHED]
-* [`334-middle-only-flag.txt`](/proposals/334-middle-only-flag.txt): A 
Directory Authority Flag To Mark Relays As Middle-only [OPEN]
-* [`335-middle-only-redux.md`](/proposals/335-middle-only-redux.md): An 
authority-only design for MiddleOnly [OPEN]
+* [`334-middle-only-flag.txt`](/proposals/334-middle-only-flag.txt): A 
Directory Authority Flag To Mark Relays As Middle-only [SUPERSEDED]
+* [`335-middle-only-redux.md`](/proposals/335-middle-only-redux.md): An 
authority-only design for MiddleOnly [FINISHED]
 * 
[`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): 
Randomized schedule for guard retries [OPEN]
 * 
[`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): 
A simpler way to decide, "Is this guard usable?" [OPEN]
 
diff --git a/proposals/README.md b/proposals/README.md
index 218f018..e4011b3 100644
--- a/proposals/README.md
+++ b/proposals/README.md
@@ -40,8 +40,6 @@ for discussion.
 * [`325-packed-relay-cells.md`](/proposals/325-packed-relay-cells.md): Packed 
relay cells: saving space on 

[tor-commits] [torspec/main] Update proposal 321 based on discussions from @arma

2021-11-22 Thread nickm
commit 2b871d0a08828bfd596519c552b73b697fd18882
Author: Nick Mathewson 
Date:   Mon Nov 22 10:00:17 2021 -0500

Update proposal 321 based on discussions from @arma

See tor#40134
---
 proposals/321-happy-families.md | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/proposals/321-happy-families.md b/proposals/321-happy-families.md
index f9ac7b4..4d8f144 100644
--- a/proposals/321-happy-families.md
+++ b/proposals/321-happy-families.md
@@ -62,8 +62,10 @@ We add a new entry to microdescriptors: `family-keys`.
 
 This line contains one or more space-separated strings describing
 families to which the node belongs.  These strings MUST be sorted in
-lexicographic order.  Clients MUST NOT depend on any particular property
-of these strings.
+lexicographic order.  These strings MAY be base64-formated nonpadded
+ed25519 family keys, or may represent some future encoding.
+
+Clients SHOULD accept unrecognized key formats.
 
 ## Changes to voting algorithm
 
@@ -125,7 +127,9 @@ family if ANY of these is true:
   in its family line, and B's descriptor lists A in its family line.
 
 * Client A has descriptors for A and B, and they both contain the
-  same entry in their family-keys or family-cert.
+  same entry in their family-keys or family-cert.  (Note that a
+  family-cert key may match a base64-encoded entry in the family-keys
+  entry.)
 
 ## Migration
 

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Mark proposal 315 as implemented in 0.4.5.1-alpha.

2021-11-22 Thread nickm
commit f3e1d58f4e6f1399d0e5e4bd92dc35f8e8f6d3fb
Author: Nick Mathewson 
Date:   Mon Nov 22 09:56:14 2021 -0500

Mark proposal 315 as implemented in 0.4.5.1-alpha.
---
 proposals/000-index.txt  | 4 ++--
 proposals/315-update-dir-required-fields.txt | 8 +++-
 proposals/BY_INDEX.md| 2 +-
 proposals/README.md  | 2 +-
 4 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 8849a5a..0f61f92 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -235,7 +235,7 @@ Proposals by number:
 312  Tor Relay Automatic IPv6 Address Discovery [ACCEPTED]
 313  Tor Relay IPv6 Statistics [ACCEPTED]
 314  Allow Markdown for proposal format [CLOSED]
-315  Updating the list of fields required in directory documents [OPEN]
+315  Updating the list of fields required in directory documents [CLOSED]
 316  FlashFlow: A Secure Speed Test for Tor (Parent Proposal) [DRAFT]
 317  Improve security aspects of DNS name resolution [NEEDS-REVISION]
 318  Limit protover values to 0-63 [CLOSED]
@@ -290,7 +290,6 @@ Proposals by status:
306  A Tor Implementation of IPv6 Happy Eyeballs
308  Counter Galois Onion: A New Proposal for Forward-Secure Relay 
Cryptography
309  Optimistic SOCKS Data
-   315  Updating the list of fields required in directory documents
319  RELAY_FRAGMENT cells
321  Better performance and usability for the MyFamily option (v2)
322  Extending link specifiers to include the directory port
@@ -421,6 +420,7 @@ Proposals by status:
305  ESTABLISH_INTRO Cell DoS Defense Extension
310  Towards load-balancing in Prop 271
314  Allow Markdown for proposal format
+   315  Updating the list of fields required in directory documents [in 
0.4.5.1-alpha]
318  Limit protover values to 0-63 [in 0.4.5.1-alpha]
328  Make Relays Report When They Are Overloaded
  SUPERSEDED:
diff --git a/proposals/315-update-dir-required-fields.txt 
b/proposals/315-update-dir-required-fields.txt
index c22536c..1761a03 100644
--- a/proposals/315-update-dir-required-fields.txt
+++ b/proposals/315-update-dir-required-fields.txt
@@ -2,7 +2,13 @@ Filename: 315-update-dir-required-fields.txt
 Title: Updating the list of fields required in directory documents
 Author: Nick Mathewson
 Created: 23 April 2020
-Status: Open
+Status: Closed
+Implemented-In: 0.4.5.1-alpha
+
+Notes:
+
+   The "hidden-service-dir" field was not made assumed-present; all other
+fields were updated.
 
 1. Introduction
 
diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md
index 637ec8b..b31fac4 100644
--- a/proposals/BY_INDEX.md
+++ b/proposals/BY_INDEX.md
@@ -232,7 +232,7 @@ Below are a list of proposals sorted by their proposal 
number.  See
 * [`312-relay-auto-ipv6-addr.txt`](/proposals/312-relay-auto-ipv6-addr.txt): 
Tor Relay Automatic IPv6 Address Discovery [ACCEPTED]
 * [`313-relay-ipv6-stats.txt`](/proposals/313-relay-ipv6-stats.txt): Tor Relay 
IPv6 Statistics [ACCEPTED]
 * 
[`314-allow-markdown-proposals.md`](/proposals/314-allow-markdown-proposals.md):
 Allow Markdown for proposal format [CLOSED]
-* 
[`315-update-dir-required-fields.txt`](/proposals/315-update-dir-required-fields.txt):
 Updating the list of fields required in directory documents [OPEN]
+* 
[`315-update-dir-required-fields.txt`](/proposals/315-update-dir-required-fields.txt):
 Updating the list of fields required in directory documents [CLOSED]
 * [`316-flashflow.md`](/proposals/316-flashflow.md): FlashFlow: A Secure Speed 
Test for Tor (Parent Proposal) [DRAFT]
 * 
[`317-secure-dns-name-resolution.txt`](/proposals/317-secure-dns-name-resolution.txt):
 Improve security aspects of DNS name resolution [NEEDS-REVISION]
 * [`318-limit-protovers.md`](/proposals/318-limit-protovers.md): Limit 
protover values to 0-63 [CLOSED]
diff --git a/proposals/README.md b/proposals/README.md
index 49728d3..218f018 100644
--- a/proposals/README.md
+++ b/proposals/README.md
@@ -32,7 +32,6 @@ for discussion.
 * [`306-ipv6-happy-eyeballs.txt`](/proposals/306-ipv6-happy-eyeballs.txt): A 
Tor Implementation of IPv6 Happy Eyeballs
 * [`308-counter-galois-onion.txt`](/proposals/308-counter-galois-onion.txt): 
Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography
 * 
[`309-optimistic-socks-in-tor.txt`](/proposals/309-optimistic-socks-in-tor.txt):
 Optimistic SOCKS Data
-* 
[`315-update-dir-required-fields.txt`](/proposals/315-update-dir-required-fields.txt):
 Updating the list of fields required in directory documents
 * [`319-wide-everything.md`](/proposals/319-wide-everything.md): 
RELAY_FRAGMENT cells
 * [`321-happy-families.md`](/proposals/321-happy-families.md): Better 
performance and usability for the MyFamily option (v2)
 * [`322-dirport-linkspec.md`](/proposals/322-dirport-linkspec.md): Extending 
link specifiers to include the directory port
@@ -239,6 +238,7 @@ necessary.
 * 

[tor-commits] [torspec/main] Update proposal index based on recent reclassification.

2021-11-22 Thread nickm
commit d27f6daa15593108762c86724158a5c0a4695165
Author: Nick Mathewson 
Date:   Mon Nov 22 09:36:39 2021 -0500

Update proposal index based on recent reclassification.
---
 proposals/000-index.txt | 40 
 proposals/BY_INDEX.md   | 20 ++--
 proposals/README.md | 20 ++--
 3 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index f6e844b..8849a5a 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -80,7 +80,7 @@ Proposals by number:
 157  Make certificate downloads specific [CLOSED]
 158  Clients download consensus + microdescriptors [CLOSED]
 159  Exit Scanning [INFORMATIONAL]
-160  Authorities vote for bandwidth offsets in consensus [FINISHED]
+160  Authorities vote for bandwidth offsets in consensus [CLOSED]
 161  Computing Bandwidth Adjustments [CLOSED]
 162  Publish the consensus in multiple flavors [CLOSED]
 163  Detecting whether a connection comes from a client [SUPERSEDED]
@@ -152,7 +152,7 @@ Proposals by number:
 229  Further SOCKS5 extensions [REJECTED]
 230  How to change RSA1024 relay identity keys [OBSOLETE]
 231  Migrating authority RSA1024 identity keys [OBSOLETE]
-232  Pluggable Transport through SOCKS proxy [FINISHED]
+232  Pluggable Transport through SOCKS proxy [CLOSED]
 233  Making Tor2Web mode faster [REJECTED]
 234  Adding remittance field to directory specification [REJECTED]
 235  Stop assigning (and eventually supporting) the Named flag [CLOSED]
@@ -162,7 +162,7 @@ Proposals by number:
 239  Consensus Hash Chaining [OPEN]
 240  Early signing key revocation for directory authorities [OPEN]
 241  Resisting guard-turnover attacks [REJECTED]
-242  Better performance and usability for the MyFamily option [RESERVE]
+242  Better performance and usability for the MyFamily option [SUPERSEDED]
 243  Give out HSDir flag only to relays with Stable flag [CLOSED]
 244  Use RFC5705 Key Exporting in our AUTHENTICATE calls [CLOSED]
 245  Deprecating and removing the TAP circuit extension protocol 
[NEEDS-REVISION]
@@ -193,7 +193,7 @@ Proposals by number:
 270  RebelAlliance: A Post-Quantum Secure Hybrid Handshake Based on NewHope 
[OBSOLETE]
 271  Another algorithm for guard selection [CLOSED]
 272  Listed routers should be Valid, Running, and treated as such [CLOSED]
-273  Exit relay pinning for web services [DRAFT]
+273  Exit relay pinning for web services [RESERVE]
 274  Rotate onion keys less frequently [CLOSED]
 275  Stop including meaningful "published" time in microdescriptor consensus 
[ACCEPTED]
 276  Report bandwidth with lower granularity in consensus documents [DEAD]
@@ -202,13 +202,13 @@ Proposals by number:
 279  A Name System API for Tor Onion Services [NEEDS-REVISION]
 280  Privacy-Preserving Statistics with Privcount in Tor [SUPERSEDED]
 281  Downloading microdescriptors in bulk [RESERVE]
-282  Remove "Named" and "Unnamed" handling from consensus voting [FINISHED]
+282  Remove "Named" and "Unnamed" handling from consensus voting [ACCEPTED]
 283  Move IPv6 ORPorts from microdescriptors to the microdesc consensus 
[CLOSED]
 284  Hidden Service v3 Control Port [CLOSED]
 285  Directory documents should be standardized as UTF-8 [ACCEPTED]
 286  Controller APIs for hibernation access on mobile [REJECTED]
 287  Reduce circuit lifetime without overloading the network [OPEN]
-288  Privacy-Preserving Statistics with Privcount in Tor (Shamir version) 
[ACCEPTED]
+288  Privacy-Preserving Statistics with Privcount in Tor (Shamir version) 
[RESERVE]
 289  Authenticating sendme cells to mitigate bandwidth attacks [CLOSED]
 290  Continuously update consensus methods [META]
 291  The move to two guard nodes [NEEDS-REVISION]
@@ -221,7 +221,7 @@ Proposals by number:
 298  Putting family lines in canonical form [CLOSED]
 299  Preferring IPv4 or IPv6 based on IP Version Failure Count [SUPERSEDED]
 300  Walking Onions: Scaling and Saving Bandwidth [INFORMATIONAL]
-301  Don't include package fingerprints in consensus documents [FINISHED]
+301  Don't include package fingerprints in consensus documents [OPEN]
 302  Hiding onion service clients using padding [CLOSED]
 303  When and how to remove support for protocol versions [OPEN]
 304  Extending SOCKS5 Onion Service Error Codes [CLOSED]
@@ -230,11 +230,11 @@ Proposals by number:
 307  Onion Balance Support for Onion Service v3 [RESERVE]
 308  Counter Galois Onion: A New Proposal for Forward-Secure Relay 
Cryptography [OPEN]
 309  Optimistic SOCKS Data [OPEN]
-310  Towards load-balancing in Prop 271 [FINISHED]
+310  Towards load-balancing in Prop 271 [CLOSED]
 311  Tor Relay IPv6 Reachability [ACCEPTED]
 312  Tor Relay Automatic IPv6 Address Discovery [ACCEPTED]
 313  Tor Relay IPv6 Statistics [ACCEPTED]
-314  Allow Markdown for proposal format [FINISHED]
+314  Allow Markdown for proposal format [CLOSED]
 315  Updating the list of fields required in directory documents [OPEN]
 316  FlashFlow: A 

[tor-commits] [torspec/main] Mark proposal 160 as closed.

2021-11-22 Thread nickm
commit 6a406bc719812eeaa56d1e9b620392c3424c3af9
Author: Nick Mathewson 
Date:   Mon Nov 22 09:28:31 2021 -0500

Mark proposal 160 as closed.

It was documented back in b4d580ebbd65fde4d69fa4f9d2c75c405e1a12a1.
---
 proposals/160-bandwidth-offset.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proposals/160-bandwidth-offset.txt 
b/proposals/160-bandwidth-offset.txt
index de9c6e4..8ad4d18 100644
--- a/proposals/160-bandwidth-offset.txt
+++ b/proposals/160-bandwidth-offset.txt
@@ -2,7 +2,7 @@ Filename: 160-bandwidth-offset.txt
 Title: Authorities vote for bandwidth offsets in consensus
 Author: Roger Dingledine
 Created: 4-May-2009
-Status: Finished
+Status: Closed
 Target: 0.2.1.x
 
 1. Motivation



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Mark proposal 310 (guard bandaid) as Closed.

2021-11-22 Thread nickm
commit b9f4effedeeaa98f29263a5c3b07a87079b15587
Author: Nick Mathewson 
Date:   Mon Nov 22 09:21:30 2021 -0500

Mark proposal 310 (guard bandaid) as Closed.

This behavior is now documented in guard-spec, since around
91ea21e3a36d5.
---
 proposals/310-bandaid-on-guard-selection.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proposals/310-bandaid-on-guard-selection.txt 
b/proposals/310-bandaid-on-guard-selection.txt
index 74842dc..2001994 100644
--- a/proposals/310-bandaid-on-guard-selection.txt
+++ b/proposals/310-bandaid-on-guard-selection.txt
@@ -3,7 +3,7 @@ Title: Towards load-balancing in Prop 271
 Author:  Florentin Rochet, Aaron Johnson et al.
 Created: 2019-10-27
 Supersedes: 271
-Status: Finished
+Status: Closed
 
 1. Motivation and Context
 



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Mark proposal 282 as "accepted", not "finished".

2021-11-22 Thread nickm
commit 68b474c00b738462d6cf00daa550fd3099d502b8
Author: Nick Mathewson 
Date:   Mon Nov 22 09:15:34 2021 -0500

Mark proposal 282 as "accepted", not "finished".

Nobody votes on this flag any more, but we _didn't_ actually remove
support in the code for voting on it.

I incorrectly marked it Finished because its ticket was closed,
but it doesn't seem to be actually implemented in Tor.
---
 proposals/282-remove-named-from-consensus.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proposals/282-remove-named-from-consensus.txt 
b/proposals/282-remove-named-from-consensus.txt
index 4c3ba13..7fc28f0 100644
--- a/proposals/282-remove-named-from-consensus.txt
+++ b/proposals/282-remove-named-from-consensus.txt
@@ -2,7 +2,7 @@ Filename: 282-remove-named-from-consensus.txt
 Title: Remove "Named" and "Unnamed" handling from consensus voting
 Author: Nick Mathewson
 Created: 12-Sep-2017
-Status: Finished
+Status: Accepted
 Target: 0.3.3.x
 
 1. Summary



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Mark proposal 273 (exit pinning) as Reserve.

2021-11-22 Thread nickm
commit 14c8021629ee8f4e8809e878489d670e7e8a2106
Author: Nick Mathewson 
Date:   Mon Nov 22 09:32:33 2021 -0500

Mark proposal 273 (exit pinning) as Reserve.

There's not been much progress here, and I don't think we'll
come back to it any time soon.
---
 proposals/273-exit-relay-pinning.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proposals/273-exit-relay-pinning.txt 
b/proposals/273-exit-relay-pinning.txt
index 91c3763..4a83a00 100644
--- a/proposals/273-exit-relay-pinning.txt
+++ b/proposals/273-exit-relay-pinning.txt
@@ -2,7 +2,7 @@ Filename: 273-exit-relay-pinning.txt
 Title: Exit relay pinning for web services
 Author: Philipp Winter, Tobias Pulls, Roya Ensafi, and Nick Feamster
 Created: 2016-09-22
-Status: Draft
+Status: Reserve
 Target: n/a
 
 0. Overview



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Mark 232 (TOR_PT_PROXY) as Closed.

2021-11-22 Thread nickm
commit b22531e3bfa97020fd0e546ad4d27219a6c750bc
Author: Nick Mathewson 
Date:   Mon Nov 22 09:25:45 2021 -0500

Mark 232 (TOR_PT_PROXY) as Closed.

George Kadianakis documented this back in 4dcd7e94f17c072.
---
 proposals/232-pluggable-transports-through-proxy.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proposals/232-pluggable-transports-through-proxy.txt 
b/proposals/232-pluggable-transports-through-proxy.txt
index f4fa1ce..03cee07 100644
--- a/proposals/232-pluggable-transports-through-proxy.txt
+++ b/proposals/232-pluggable-transports-through-proxy.txt
@@ -2,7 +2,7 @@ Filename: 232-pluggable-transports-through-proxy.txt
 Title: Pluggable Transport through SOCKS proxy
 Author: Arturo Filastò
 Created: 28 February 2012
-Status: Finished
+Status: Closed
 Implemented-In: 0.2.6
 
 Overview



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Fold 314 (markdown) into 001 (process).

2021-11-22 Thread nickm
commit 21a23221f6e5721e17db472208063e7c62ffe27b
Author: Nick Mathewson 
Date:   Mon Nov 22 09:02:20 2021 -0500

Fold 314 (markdown) into 001 (process).
---
 proposals/001-process.txt | 6 ++
 proposals/314-allow-markdown-proposals.md | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/proposals/001-process.txt b/proposals/001-process.txt
index d6717bf..7211c3b 100644
--- a/proposals/001-process.txt
+++ b/proposals/001-process.txt
@@ -145,6 +145,12 @@ What should go in a proposal:
 can avoid really expensive performance regressions, and so we can
 avoid wasting time on insignificant gains.
 
+How to format proposals:
+
+   Proposals may be written in plain text (like this one), or in Markdown.
+   If using Markdown, the header must be wrapped in triple-backtick ("```")
+   lines.  Whenever possible, we prefer the Commonmark dialect of Markdown.
+
 Proposal status:
 
Open: A proposal under discussion.
diff --git a/proposals/314-allow-markdown-proposals.md 
b/proposals/314-allow-markdown-proposals.md
index 99677f0..8469757 100644
--- a/proposals/314-allow-markdown-proposals.md
+++ b/proposals/314-allow-markdown-proposals.md
@@ -3,7 +3,7 @@ Filename: 314-allow-markdown-proposals.md
 Title: Allow Markdown for proposal format.
 Author: Nick Mathewson
 Created: 23 April 2020
-Status: Finished
+Status: Closed
 ```
 
 # Introduction



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Mark proposal 332-ntor-v3 as accepted

2021-11-22 Thread nickm
commit aa1c603d1711b89cc76bbeb0d01730d1001ad2f7
Author: Nick Mathewson 
Date:   Mon Nov 22 09:04:27 2021 -0500

Mark proposal 332-ntor-v3 as accepted
---
 proposals/332-ntor-v3-with-extra-data.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proposals/332-ntor-v3-with-extra-data.md 
b/proposals/332-ntor-v3-with-extra-data.md
index 207bc07..4e55713 100644
--- a/proposals/332-ntor-v3-with-extra-data.md
+++ b/proposals/332-ntor-v3-with-extra-data.md
@@ -3,7 +3,7 @@ Filename: 332-ntor-v3-with-extra-data.md
 Title: Ntor protocol with extra data, version 3.
 Author: Nick Mathewson
 Created: 12 July 2021
-Status: Open
+Status: Accepted
 ```
 
 # Overview



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Move proposal 288 (privcount-shamir) to reserve.

2021-11-22 Thread nickm
commit 017674275d85dbc3a901acec1a8841c4ff18612b
Author: Nick Mathewson 
Date:   Mon Nov 22 09:03:59 2021 -0500

Move proposal 288 (privcount-shamir) to reserve.
---
 proposals/288-privcount-with-shamir.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proposals/288-privcount-with-shamir.txt 
b/proposals/288-privcount-with-shamir.txt
index 62faa1d..109c743 100644
--- a/proposals/288-privcount-with-shamir.txt
+++ b/proposals/288-privcount-with-shamir.txt
@@ -3,7 +3,7 @@ Title: Privacy-Preserving Statistics with Privcount in Tor 
(Shamir version)
 Author: Nick Mathewson, Tim Wilson-Brown, Aaron Johnson
 Created: 1-Dec-2017
 Supercedes: 280
-Status: Accepted
+Status: Reserve
 
 0. Acknowledgments
 



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Mark proposal 242-better-families superseded by 321-happy-families

2021-11-22 Thread nickm
commit e210e093a82735733e758c9218bda07cac686225
Author: Nick Mathewson 
Date:   Mon Nov 22 09:01:41 2021 -0500

Mark proposal 242-better-families superseded by 321-happy-families
---
 proposals/242-better-families.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/proposals/242-better-families.txt 
b/proposals/242-better-families.txt
index 8a79fa2..5f4ac47 100644
--- a/proposals/242-better-families.txt
+++ b/proposals/242-better-families.txt
@@ -2,7 +2,8 @@ Filename: 242-better-families.txt
 Title: Better performance and usability for the MyFamily option
 Author: Nick Mathewson
 Created: 2015-02-27
-Status: Reserve
+Status: Superseded
+Superseded-by: 321-happy-families.md
 
 1. Problem statement.
 



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Mark proposal 301 as "open", not "finished".

2021-11-22 Thread nickm
commit 4ffd7c34e259c88df79104f311993c345ba0
Author: Nick Mathewson 
Date:   Mon Nov 22 09:15:34 2021 -0500

Mark proposal 301 as "open", not "finished".

I incorrectly marked it Finished because its ticket was closed,
but it doesn't seem to be actually implemented in Tor.
---
 proposals/301-dont-vote-on-package-fingerprints.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proposals/301-dont-vote-on-package-fingerprints.txt 
b/proposals/301-dont-vote-on-package-fingerprints.txt
index 0a2f146..8e8b63a 100644
--- a/proposals/301-dont-vote-on-package-fingerprints.txt
+++ b/proposals/301-dont-vote-on-package-fingerprints.txt
@@ -2,7 +2,7 @@ Filename: 301-dont-vote-on-package-fingerprints.txt
 Title: Don't include package fingerprints in consensus documents
 Author: Iain R. Learmonth
 Created: 2019-02-21
-Status: Finished
+Status: Open
 Ticket: #28465
 
 0. Abstract



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [chutney/main] Update to new arti configuration format.

2021-11-18 Thread nickm
commit c825cba0bcd813c644c6ac069deeb7347d3200ee
Author: Nick Mathewson 
Date:   Thu Nov 18 14:34:09 2021 -0500

Update to new arti configuration format.
---
 lib/chutney/TorNet.py | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lib/chutney/TorNet.py b/lib/chutney/TorNet.py
index 863a456..55c9378 100644
--- a/lib/chutney/TorNet.py
+++ b/lib/chutney/TorNet.py
@@ -2368,14 +2368,15 @@ state_dir = "{path}/arti/state"
 # These values disable enforce_distance entirely; we can replace them
 # with something like Tor's "EnforceDistinceSubnets 0" if Arti ever
 # implements it.
-enforce_distance = {{ "subnets_family_v4" = 33, "subnets_family_v6" = 129 }}
+ipv4_subnet_family_prefix = 33
+ipv6_subnet_family_prefix = 129
 
-[addr_config]
+[address_filter]
 # Allow the client to accept requests to connect to e.g. 127.0.0.1
 allow_local_addrs = true
 
 """.format(path=self.dir))
-f.write("""[network]
+f.write("""[tor_network]
 fallback_caches = [
 """)
 f.write("".join(arti_fallback_lines))

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Mark proposal 333 as Finished.

2021-11-12 Thread nickm
commit 0e5ef653f7f10a14b3ba037ea1dfb4b852522dec
Author: Nick Mathewson 
Date:   Fri Nov 12 11:49:05 2021 -0500

Mark proposal 333 as Finished.
---
 proposals/000-index.txt | 4 ++--
 proposals/333-vanguards-lite.md | 3 ++-
 proposals/BY_INDEX.md   | 2 +-
 proposals/README.md | 2 +-
 4 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index a8de698..f6e844b 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -253,7 +253,7 @@ Proposals by number:
 330  Modernizing authority contact entries [OPEN]
 331  Res tokens: Anonymous Credentials for Onion Service DoS Resilience [DRAFT]
 332  Ntor protocol with extra data, version 3 [OPEN]
-333  Vanguards lite [DRAFT]
+333  Vanguards lite [FINISHED]
 334  A Directory Authority Flag To Mark Relays As Middle-only [OPEN]
 335  An authority-only design for MiddleOnly [OPEN]
 336  Randomized schedule for guard retries [OPEN]
@@ -269,7 +269,6 @@ Proposals by status:
327  A First Take at PoW Over Introduction Circuits
329  Overcoming Tor's Bottlenecks with Traffic Splitting
331  Res tokens: Anonymous Credentials for Onion Service DoS Resilience
-   333  Vanguards lite
  NEEDS-REVISION:
212  Increase Acceptable Consensus Age [for 0.2.4.x+]
219  Support for full DNS and DNSSEC resolution in Tor [for 0.2.5.x]
@@ -330,6 +329,7 @@ Proposals by status:
301  Don't include package fingerprints in consensus documents
310  Towards load-balancing in Prop 271
314  Allow Markdown for proposal format
+   333  Vanguards lite [in 0.4.7.1-alpha]
  CLOSED:
101  Voting on the Tor Directory System [in 0.2.0.x]
102  Dropping "opt" from the directory format [in 0.2.0.x]
diff --git a/proposals/333-vanguards-lite.md b/proposals/333-vanguards-lite.md
index 998bb4a..5e62b03 100644
--- a/proposals/333-vanguards-lite.md
+++ b/proposals/333-vanguards-lite.md
@@ -3,7 +3,8 @@ Filename: 333-vanguards-lite.md
 Title: Vanguards lite
 Author: George Kadianakis, Mike Perry
 Created: 2021-05-20
-Status: Draft
+Status: Finished
+Implemented-In: 0.4.7.1-alpha
 ```
 
 # 0. Introduction & Motivation
diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md
index da9dbef..a7e847f 100644
--- a/proposals/BY_INDEX.md
+++ b/proposals/BY_INDEX.md
@@ -250,7 +250,7 @@ Below are a list of proposals sorted by their proposal 
number.  See
 * [`330-authority-contact.md`](/proposals/330-authority-contact.md): 
Modernizing authority contact entries [OPEN]
 * 
[`331-res-tokens-for-anti-dos.md`](/proposals/331-res-tokens-for-anti-dos.md): 
Res tokens: Anonymous Credentials for Onion Service DoS Resilience [DRAFT]
 * 
[`332-ntor-v3-with-extra-data.md`](/proposals/332-ntor-v3-with-extra-data.md): 
Ntor protocol with extra data, version 3 [OPEN]
-* [`333-vanguards-lite.md`](/proposals/333-vanguards-lite.md): Vanguards lite 
[DRAFT]
+* [`333-vanguards-lite.md`](/proposals/333-vanguards-lite.md): Vanguards lite 
[FINISHED]
 * [`334-middle-only-flag.txt`](/proposals/334-middle-only-flag.txt): A 
Directory Authority Flag To Mark Relays As Middle-only [OPEN]
 * [`335-middle-only-redux.md`](/proposals/335-middle-only-redux.md): An 
authority-only design for MiddleOnly [OPEN]
 * 
[`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): 
Randomized schedule for guard retries [OPEN]
diff --git a/proposals/README.md b/proposals/README.md
index 75f5c4c..6366e72 100644
--- a/proposals/README.md
+++ b/proposals/README.md
@@ -75,6 +75,7 @@ themselves still need to be merged into the specifications 
proper.
 * 
[`301-dont-vote-on-package-fingerprints.txt`](/proposals/301-dont-vote-on-package-fingerprints.txt):
 Don't include package fingerprints in consensus documents
 * 
[`310-bandaid-on-guard-selection.txt`](/proposals/310-bandaid-on-guard-selection.txt):
 Towards load-balancing in Prop 271
 * 
[`314-allow-markdown-proposals.md`](/proposals/314-allow-markdown-proposals.md):
 Allow Markdown for proposal format
+* [`333-vanguards-lite.md`](/proposals/333-vanguards-lite.md): Vanguards lite
 
 
 ## META proposals: about the proposal process
@@ -114,7 +115,6 @@ discussion.
 * [`327-pow-over-intro.txt`](/proposals/327-pow-over-intro.txt): A First Take 
at PoW Over Introduction Circuits
 * [`329-traffic-splitting.txt`](/proposals/329-traffic-splitting.txt): 
Overcoming Tor's Bottlenecks with Traffic Splitting
 * 
[`331-res-tokens-for-anti-dos.md`](/proposals/331-res-tokens-for-anti-dos.md): 
Res tokens: Anonymous Credentials for Onion Service DoS Resilience
-* [`333-vanguards-lite.md`](/proposals/333-vanguards-lite.md): Vanguards lite
 
 
 ## NEEDS-REVISION proposals: ideas that we can't implement as-is

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [trunnel/main] 1L is no longer good python either.

2021-11-04 Thread nickm
commit 27d8d81bf10017fb9ce26ab3c1402d563b77d347
Author: Nick Mathewson 
Date:   Thu Nov 4 11:41:07 2021 -0400

1L is no longer good python either.
---
 lib/trunnel/SeedFuzzer.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/trunnel/SeedFuzzer.py b/lib/trunnel/SeedFuzzer.py
index 38403cb..0cb7034 100644
--- a/lib/trunnel/SeedFuzzer.py
+++ b/lib/trunnel/SeedFuzzer.py
@@ -399,7 +399,7 @@ class CorpusGenerator(trunnel.CodeGen.ASTVisitor):
 yield [ni], NIL
 elif smi.constraints is None:
 yield [ni.withVal(0)], NIL
-yield [ni.withVal((1L << width) - 1)], NIL
+yield [ni.withVal((1 << width) - 1)], NIL
 else:
 for lo, hi in smi.constraints.ranges:
 lo = self.expandConst(lo)

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [trunnel/main] Fix a pair of python2-style print invocations.

2021-11-04 Thread nickm
commit a989078a8927aa80ee76afe65efc46f2fde59b60
Author: Nick Mathewson 
Date:   Thu Nov 4 11:32:40 2021 -0400

Fix a pair of python2-style print invocations.
---
 lib/trunnel/SeedFuzzer.py | 2 +-
 lib/trunnel/__main__.py   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/trunnel/SeedFuzzer.py b/lib/trunnel/SeedFuzzer.py
index 9726c3a..38403cb 100644
--- a/lib/trunnel/SeedFuzzer.py
+++ b/lib/trunnel/SeedFuzzer.py
@@ -374,7 +374,7 @@ class CorpusGenerator(trunnel.CodeGen.ASTVisitor):
 continue
 digest = hashlib.sha256(item).hexdigest()
 fname = os.path.join(target, digest)
-print fname
+print(fname)
 with open(fname, 'wb') as f:
 f.write(item)
 examples.add(item)
diff --git a/lib/trunnel/__main__.py b/lib/trunnel/__main__.py
index dc4a66c..f232544 100644
--- a/lib/trunnel/__main__.py
+++ b/lib/trunnel/__main__.py
@@ -36,7 +36,7 @@ if __name__ == '__main__':
 sys.stderr.write("I'm %s; you asked for %s\n" % (me, it))
 sys.exit(1)
 except ImportError:
-print "Can't import"
+print("Can't import LooseVersion tool.")
 
 if len(args) < 1 and not write_c_files and not need_version:
 sys.stderr.write("Syntax: python -m trunnel \n")

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Fix typos and cleanup

2021-10-25 Thread nickm
commit 29245fd50d1ee3d96cca52154da4d888f34fedea
Author: Dimitris Apostolou 
Date:   Mon Oct 25 23:03:20 2021 +0300

Fix typos and cleanup
---
 README.md   |  2 +-
 bandwidth-file-spec.txt |  2 +-
 bridgedb-spec.txt   |  2 +-
 control-spec.txt|  6 +++---
 dir-list-spec.txt   |  4 ++--
 dos-spec.md |  2 +-
 ext-orport-spec.txt |  6 +++---
 guard-spec.txt  |  2 +-
 param-spec.txt  |  6 +++---
 path-spec.txt   |  8 
 pt-spec.txt |  8 
 rend-spec-v3.txt| 24 
 srv-spec.txt| 12 ++--
 tor-spec.txt|  6 +++---
 14 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/README.md b/README.md
index 1a02a37..bce6bcf 100644
--- a/README.md
+++ b/README.md
@@ -6,7 +6,7 @@ the reader to implement a compatible implementation of Tor 
without ever
 having to read the Tor source code.
 
 The [proposals](/proposals) directory holds our design proposals.  These
-include historical documents that have now been merged into .  For more
+include historical documents that have now been merged into.  For more
 information on the proposal process, including an explanation of how to
 make new proposals, see, see
 [001-process.txt](/proposals/001-process.txt).
diff --git a/bandwidth-file-spec.txt b/bandwidth-file-spec.txt
index 58ce83c..d9f4db6 100644
--- a/bandwidth-file-spec.txt
+++ b/bandwidth-file-spec.txt
@@ -1161,7 +1161,7 @@ B.1. Scaling requirements
 
 B.2. A linear scaling method
 
-  If scaling is required, here is a simple linear bandwith scaling
+  If scaling is required, here is a simple linear bandwidth scaling
   method, which ensures that all bandwidth votes contain approximately
   the same total bandwidth:
 
diff --git a/bridgedb-spec.txt b/bridgedb-spec.txt
index 5ccce92..51f6e5d 100644
--- a/bridgedb-spec.txt
+++ b/bridgedb-spec.txt
@@ -94,7 +94,7 @@ Table of Contents
in the bridge network status parsed earlier or if the bridge does not
have the Running flag.
BridgeDB discards bridge descriptors which have a different purpose
-   than "bridge".  BridgeDB can be configured to only accept descriptors
+   than "bridge". BridgeDB can be configured to only accept descriptors
with another purpose or not discard descriptors based on purpose at
all.
BridgeDB memorizes the IP addresses and OR ports of the remaining
diff --git a/control-spec.txt b/control-spec.txt
index 1feb250..0e2add3 100644
--- a/control-spec.txt
+++ b/control-spec.txt
@@ -1023,7 +1023,7 @@ Table of Contents
 
 "net/listeners/dir"
 
-  Listeners for Tor directory protocol, as decribed in dir-spec.txt.
+  Listeners for Tor directory protocol, as described in dir-spec.txt.
 
 "net/listeners/socks"
 
@@ -2699,7 +2699,7 @@ Table of Contents
 
   [NOTE: This feature was removed in Tor 0.3.2.1-alpha.]
 
-  Tor generates this event when it's an directory authority, and
+  Tor generates this event when it's a directory authority, and
   somebody has just uploaded a server descriptor.
 
   Syntax:
@@ -3736,7 +3736,7 @@ Table of Contents
 
   Program = The program path as defined in the *TransportPlugin
 configuration option. Tor accepts relative and full path.
-  Transport = This value indicate a hint on what the PT is such as the
+  Transport = This value indicates a hint on what the PT is such as the
   name or the protocol used for instance.
   Message = The status message that the PT sends back to the tor parent
 process minus the "STATUS" string prefix. Formatted as
diff --git a/dir-list-spec.txt b/dir-list-spec.txt
index c2d83f4..65af536 100644
--- a/dir-list-spec.txt
+++ b/dir-list-spec.txt
@@ -358,7 +358,7 @@ Table of Contents
recent Tor versions.
 
weight was removed in version 2.0.0, but is documented because it
-   may be of interest to libraries implementing Tor's fallaback
+   may be of interest to libraries implementing Tor's fallback
behaviour.
 
  DQUOTE SP+ key_value DQUOTE SP* NL
@@ -457,7 +457,7 @@ Table of Contents
Libraries SHOULD consider the potential load on the authorities, and
whether other sources can meet their needs.
 
-   Libraries that require high-uptime availablility of Tor directory
+   Libraries that require high-uptime availability of Tor directory
information should investigate the following options:
 
  * OnionOO: https://metrics.torproject.org/onionoo.html
diff --git a/dos-spec.md b/dos-spec.md
index d1ca55c..04470b2 100644
--- a/dos-spec.md
+++ b/dos-spec.md
@@ -46,7 +46,7 @@ kinds of allocation:
   * Half-open stream records.
   * Cached onion service descriptors (hsdir only).
   * Cached DNS resolves (relay only).
-  * GEOIP-based  usage activity statistics.
+  * GEOIP-based usage activity statistics.
 
 Note that directory caches aren't counted, since those are stored on
 disk and accessed via mmap.

[tor-commits] [torspec/main] Fix grammar in README.md

2021-10-25 Thread nickm
commit d3165c9ae0d346288ccb94fbfb831d2686f7abf3
Author: Nick Mathewson 
Date:   Mon Oct 25 16:35:46 2021 -0400

Fix grammar in README.md
---
 README.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/README.md b/README.md
index bce6bcf..3ad1db4 100644
--- a/README.md
+++ b/README.md
@@ -6,9 +6,9 @@ the reader to implement a compatible implementation of Tor 
without ever
 having to read the Tor source code.
 
 The [proposals](/proposals) directory holds our design proposals.  These
-include historical documents that have now been merged into.  For more
-information on the proposal process, including an explanation of how to
-make new proposals, see, see
+include historical documents that have now been merged into the main
+specifications.  For more information on the proposal process, including an
+explanation of how to make new proposals, see
 [001-process.txt](/proposals/001-process.txt).
 
 ## What you can find here

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Add proposals 336 and 337.

2021-10-25 Thread nickm
commit ea41a664476e7bc3690f080fbd3c13e2e32629fc
Author: Nick Mathewson 
Date:   Fri Oct 22 17:36:04 2021 -0400

Add proposals 336 and 337.
---
 proposals/336-randomize-guard-retries.md |  87 +++
 proposals/337-simpler-guard-usability.md | 138 +++
 2 files changed, 225 insertions(+)

diff --git a/proposals/336-randomize-guard-retries.md 
b/proposals/336-randomize-guard-retries.md
new file mode 100644
index 000..5ee5b71
--- /dev/null
+++ b/proposals/336-randomize-guard-retries.md
@@ -0,0 +1,87 @@
+```
+Filename: 336-randomize-guard-retries.md
+Title: Randomized schedule for guard retries
+Author: Nick Mathewson
+Created: 2021-10-22
+Status: Open
+```
+
+# Introduction
+
+When we notice that a guard isn't working, we don't mark it as retriable
+until a certain interval has passed.  Currently, these intervals are
+fixed, as described in the documentation for `GUARDS_RETRY_SCHED` in
+`guard-spec` appendix A.1.  Here we propose using a randomized retry
+interval instead, based on the same decorrelated-jitter algorithm we use
+for directory retries.
+
+The upside of this approach is that it makes our behavior in
+the presence of an unreliable network a bit harder for an attacker to
+predict. It also means that if a guard goes down for a while, its
+clients will notice that it is up at staggered times, rather than
+probing it in lock-step.
+
+The downside of this approach is that we can, if we get unlucky
+enough, completely fail to notice that a preferred guard is online when
+we would otherwise have noticed sooner.
+
+Note that when a guard is marked retriable, it isn't necessarily retried
+immediately.  Instead, its status is changed from "Unreachable" to
+"Unknown", which will cause it to get retried.
+
+For reference, our previous schedule was:
+
+```
+   {param:PRIMARY_GUARDS_RETRY_SCHED}
+  -- every 10 minutes for the first six hours,
+  -- every 90 minutes for the next 90 hours,
+  -- every 4 hours for the next 3 days,
+  -- every 9 hours thereafter.
+
+   {param:GUARDS_RETRY_SCHED} --
+  -- every hour for the first six hours,
+  -- every 4 hours for the next 90 hours,
+  -- every 18 hours for the next 3 days,
+  -- every 36 hours thereafter.
+```
+
+# The new algorithm
+
+We re-use the decorrelated-jitter algorithm from `dir-spec` section 5.5.
+The specific formula used to compute the 'i+1'th delay is:
+
+```
+Delay_{i+1} = MIN(cap, random_between(lower_bound, upper_bound))
+where upper_bound = MAX(lower_bound+1, Delay_i * 3)
+  lower_bound = MAX(1, base_delay).
+```
+
+For primary guards, we set base_delay to 30 seconds and cap to 6 hours.
+
+For non-primary guards, we set base_delay to 10 minutes and cap to 36
+hours.
+
+(These parameters were selected by simulating the results of using them
+until they looked "a bit more aggressive" than the current algorithm, but
+not too much.)
+
+The average behavior for the new primary schedule is:
+
+```
+First 1.0 hours: 10.14283 attempts. (Avg delay 4m 47.41s)
+First 6.0 hours: 19.02377 attempts. (Avg delay 15m 36.95s)
+First 96.0 hours: 56.11173 attempts. (Avg delay 1h 40m 3.13s)
+First 168.0 hours: 83.67091 attempts. (Avg delay 1h 58m 43.16s)
+Steady state: 2h 36m 44.63s between attempts.
+```
+
+The average behavior for the new non-primary schedule is:
+
+```
+First 1.0 hours: 3.08069 attempts. (Avg delay 14m 26.08s)
+First 6.0 hours: 8.1473 attempts. (Avg delay 35m 25.27s)
+First 96.0 hours: 22.57442 attempts. (Avg delay 3h 49m 32.16s)
+First 168.0 hours: 29.02873 attempts. (Avg delay 5h 27m 2.36s)
+Steady state: 11h 15m 28.47s between attempts.
+```
+
diff --git a/proposals/337-simpler-guard-usability.md 
b/proposals/337-simpler-guard-usability.md
new file mode 100644
index 000..d75c4d8
--- /dev/null
+++ b/proposals/337-simpler-guard-usability.md
@@ -0,0 +1,138 @@
+```
+Filename: 337-simpler-guard-usability.md
+Title: A simpler way to decide, "Is this guard usable?"
+Author: Nick Mathewson
+Created: 2021-10-22
+Status: Open
+```
+
+# Introduction
+
+The current `guard-spec` describes a mechanism for how to behave when
+our primary guards are unreachable, and we don't know which other guards
+are reachable.  This proposal describes a simpler method, currently
+implemented in [Arti](https://gitlab.torproject.org/tpo/core/arti/).
+
+(Note that this method might not actually give different results: its
+only advantage is that it is much simpler to implement.)
+
+## The task at hand
+
+For illustration, we'll assume that our primary guards are P1, P2, and
+P3, and our subsequent guards (in preference order) are G1, G2, G3, and
+so on.  The status of each guard is Reachable (we think we can connect
+to it), Unreachable (we think it's down), or Unknown (we haven't tried
+it recently).
+
+The question becomes, "What should we do when P1, P2, and P3 are
+Unreachable, and G1, G2, ... are all Unknown"?
+
+In this circumstance, we _could_ say that we only build circuits to G1,

[tor-commits] [torspec/main] Update proposal index.

2021-10-25 Thread nickm
commit c10dd31c0dcf970b8e199e029d56fc483f8a216c
Author: Nick Mathewson 
Date:   Mon Oct 25 16:33:21 2021 -0400

Update proposal index.
---
 proposals/000-index.txt | 4 
 proposals/BY_INDEX.md   | 2 ++
 proposals/README.md | 2 ++
 3 files changed, 8 insertions(+)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index af0c8b1..3ae1776 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -256,6 +256,8 @@ Proposals by number:
 333  Vanguards lite [DRAFT]
 334  A Directory Authority Flag To Mark Relays As Middle-only [OPEN]
 335  An authority-only design for MiddleOnly [OPEN]
+336  Randomized schedule for guard retries [OPEN]
+337  A simpler way to decide, "Is this guard usable?" [OPEN]
 
 
 Proposals by status:
@@ -302,6 +304,8 @@ Proposals by status:
332  Ntor protocol with extra data, version 3
334  A Directory Authority Flag To Mark Relays As Middle-only
335  An authority-only design for MiddleOnly
+   336  Randomized schedule for guard retries
+   337  A simpler way to decide, "Is this guard usable?"
  ACCEPTED:
265  Load Balancing with Overhead Parameters [for 0.2.9.x]
275  Stop including meaningful "published" time in microdescriptor 
consensus [for 0.3.1.x-alpha]
diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md
index 5e07863..31cc5f8 100644
--- a/proposals/BY_INDEX.md
+++ b/proposals/BY_INDEX.md
@@ -253,4 +253,6 @@ Below are a list of proposals sorted by their proposal 
number.  See
 * [`333-vanguards-lite.md`](/proposals/333-vanguards-lite.md): Vanguards lite 
[DRAFT]
 * [`334-middle-only-flag.txt`](/proposals/334-middle-only-flag.txt): A 
Directory Authority Flag To Mark Relays As Middle-only [OPEN]
 * [`335-middle-only-redux.md`](/proposals/335-middle-only-redux.md): An 
authority-only design for MiddleOnly [OPEN]
+* 
[`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): 
Randomized schedule for guard retries [OPEN]
+* 
[`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): 
A simpler way to decide, "Is this guard usable?" [OPEN]
 
diff --git a/proposals/README.md b/proposals/README.md
index 49968f8..737dad1 100644
--- a/proposals/README.md
+++ b/proposals/README.md
@@ -43,6 +43,8 @@ for discussion.
 * 
[`332-ntor-v3-with-extra-data.md`](/proposals/332-ntor-v3-with-extra-data.md): 
Ntor protocol with extra data, version 3
 * [`334-middle-only-flag.txt`](/proposals/334-middle-only-flag.txt): A 
Directory Authority Flag To Mark Relays As Middle-only
 * [`335-middle-only-redux.md`](/proposals/335-middle-only-redux.md): An 
authority-only design for MiddleOnly
+* 
[`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): 
Randomized schedule for guard retries
+* 
[`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): 
A simpler way to decide, "Is this guard usable?"
 
 
 ## ACCEPTED proposals: slated for implementation

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [chutney/main] Use the correct name for arti's addr_config.

2021-10-22 Thread nickm
commit 6a7de8dde6b32d8e2d58d74502ea71f948ebbb7c
Author: Nick Mathewson 
Date:   Fri Oct 22 08:02:16 2021 -0400

Use the correct name for arti's addr_config.
---
 lib/chutney/TorNet.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/chutney/TorNet.py b/lib/chutney/TorNet.py
index 53a8a6c..863a456 100644
--- a/lib/chutney/TorNet.py
+++ b/lib/chutney/TorNet.py
@@ -2370,7 +2370,7 @@ state_dir = "{path}/arti/state"
 # implements it.
 enforce_distance = {{ "subnets_family_v4" = 33, "subnets_family_v6" = 129 }}
 
-[client_config]
+[addr_config]
 # Allow the client to accept requests to connect to e.g. 127.0.0.1
 allow_local_addrs = true
 

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [chutney/main] Allow add_local_addrs = true to arti.toml

2021-10-21 Thread nickm
commit 6a12172d2e952f364a607c95760559fbffdb0b22
Author: Nick Mathewson 
Date:   Thu Oct 21 11:52:24 2021 -0400

Allow add_local_addrs = true to arti.toml
---
 lib/chutney/TorNet.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/chutney/TorNet.py b/lib/chutney/TorNet.py
index ce3873a..53a8a6c 100644
--- a/lib/chutney/TorNet.py
+++ b/lib/chutney/TorNet.py
@@ -2370,6 +2370,10 @@ state_dir = "{path}/arti/state"
 # implements it.
 enforce_distance = {{ "subnets_family_v4" = 33, "subnets_family_v6" = 129 }}
 
+[client_config]
+# Allow the client to accept requests to connect to e.g. 127.0.0.1
+allow_local_addrs = true
+
 """.format(path=self.dir))
 f.write("""[network]
 fallback_caches = [

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] clarify prop335 based on tor-dev feedback from nusenu

2021-10-17 Thread nickm
commit cabf6c7203d01ca663cdaff53d5515e421caa2dc
Author: Nick Mathewson 
Date:   Sun Oct 17 14:19:00 2021 -0400

clarify prop335 based on tor-dev feedback from nusenu
---
 proposals/335-middle-only-redux.md | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/proposals/335-middle-only-redux.md 
b/proposals/335-middle-only-redux.md
index 19e6c1b..3329afe 100644
--- a/proposals/335-middle-only-redux.md
+++ b/proposals/335-middle-only-redux.md
@@ -22,17 +22,17 @@ Chauhan, and the related discussions on tor-dev.
 ## Generating votes
 
 When voting for a relay with the `MiddleOnly` flag, an authority
-should set all flags indicating that a relay is unusable for a
-particular purpose, and against all flags indicating that the relay
+should vote _for_ all flags indicating that a relay is unusable for a
+particular purpose, and _against_ all flags indicating that the relay
 is usable for a particular position.
 
-These flags SHOULD be set in a vote whenever `MiddleOnly` is
-present, and only when the authority is configured to vote on the
-`BadExit` flag.
+Specifically, these flags SHOULD be set in a vote whenever
+`MiddleOnly` is present, and only when the authority is configured
+to vote on the `BadExit` flag.
 
   * `BadExit`
 
-These flags SHOULD be cleared in a vote whenever `MiddleOnly` is
+And these flags SHOULD be cleared in a vote whenever `MiddleOnly` is
 present.
 
   * `Exit`

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Changes file for new fuzzers

2021-10-16 Thread nickm
commit 9ac1ed525f6d21338d675f2898987a13d82f4b78
Author: Nick Mathewson 
Date:   Sat Oct 16 10:51:41 2021 -0400

Changes file for new fuzzers
---
 changes/bug40488 | 4 
 1 file changed, 4 insertions(+)

diff --git a/changes/bug40488 b/changes/bug40488
new file mode 100644
index 00..6fc265cc20
--- /dev/null
+++ b/changes/bug40488
@@ -0,0 +1,4 @@
+  o Minor features (testing):
+- We now have separate fuzzers for the inner layers of v3 onion
+  service descriptors, to prevent future bugs like 40392.
+  Closes ticket 40488.

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Merge remote-tracking branch 'asn-private/hsfuz' into hs_fuzzing

2021-10-16 Thread nickm
commit 37c0542d0d87a288e12c9397593bd890f2964a58
Merge: ed4b8ca74b 7034c8449d
Author: Nick Mathewson 
Date:   Fri Oct 15 11:20:06 2021 -0400

Merge remote-tracking branch 'asn-private/hsfuz' into hs_fuzzing

 scripts/codegen/fuzzing_include_am.py |   2 +
 src/feature/hs/hs_descriptor.c|  16 ++---
 src/feature/hs/hs_descriptor.h|  19 ++
 src/test/fuzz/fuzz_hsdescv3_inner.c   | 119 ++
 src/test/fuzz/fuzz_hsdescv3_middle.c  | 116 +
 src/test/fuzz/include.am  |  61 +
 6 files changed, 325 insertions(+), 8 deletions(-)




___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Implement fuzzing for superencrypted HSv3 desc layer

2021-10-16 Thread nickm
commit 7034c8449defc91fa96d8f1095fab17a3a60c63f
Author: George Kadianakis 
Date:   Fri Jun 11 01:55:20 2021 +0300

Implement fuzzing for superencrypted HSv3 desc layer

Here is a corpus:

desc-auth-type x25519
desc-auth-ephemeral-key 68GrIdhTe01n7WfZroM+Uwqzd4N6GpFWgVfperanvDM=
auth-client viYu6HEs7bo ljriJfI9acOhbwhjksBvAg omzl9Hz/XK6fMdifuIAXiw
auth-client SNzxBNMmHiU Mh0Zv0GrGxjFaKr9OG1QNg 9xayJnQoEXsuakxolL54nQ
auth-client Ho28DFsBhTE tBB4ebOhBu95a+3dHEv+Fg XUkBvpJXerGUX/eS3uwXdQ
auth-client 7BHnYML5O20 eMm3Csm92XdR9Mt/Xzy/ug HrEx44IVpQlQBu7tcP4F2g
auth-client xsrAsjgWj/0 5QdhG282mmK35U5BCkqaMg Ops8Lgl+ASOXKnfii7egdA
auth-client 6FO1oPHXwmI mEl0Z5Pn8GLlCNH5xbUeWg 9610jM1OWyASws80exma6Q
auth-client MvOMOF2ynd0 t2TFwq3mj5ZKm8yH6wDEIg hM1wsvG4CTY8X1MLOInIIg
auth-client WJs5l92CN4Y vfmHF82nJ8qmGqJ/DLRTGg g9d51VyUEi9LOsmdQvaQJQ
auth-client 1TiTYG9rpDU xPJPjzHtQYmJTFm8zR1j9Q /Uv+1B5co/86sOKEGJzCqQ
auth-client ZBkeY2qXdTc ir85lASBZRF/pD4PQIK+EQ 2LxDABMvmv86KaNQqzNenQ
auth-client 1AOfLh0KtmI 2+yYUfy1BAKB+PKwMukTrA S1d6QTczWqADotn+yl+2aQ
auth-client xd2xsZiNr3A FWk/SsFrech49gODym+7gA 5ydb7Ji0e7yCNZFlVD4Q5Q
auth-client DQYYX5iSlGA VIV3wSGKIfK1GxF0xxm4dg wdH1bc2zm5dSvCVJX8ZzLg
auth-client 1rqVzmtYgGU aSQbgq+/sF93k5stnA+8KA aAWoQMV0VM262Znc7RCMxw
auth-client sx7Br+mYTp8 b/0rd+9e5Q1zGa79I1O41A jc1sm3lOfujPljWA09Q3ng
auth-client S4C/qS7s5N8 XtRzoNhqQGcrVaeTQqMk2A O4bBlq8d3gopBRMWkpuyeg
encrypted
-BEGIN MESSAGE-
BxzghAOjM4De6Z6eGTvBrTP2SJDdQOYV/u9qtvlFsa2FRQWk20Adv3zJ/AI10CQO
mUP4DNXM8FWQYGTvmD7wGz2/cXGjKwBXg1qO7zF5eP/D/My1sXsIfCcb41mkheNt
xn1I5eKXcnghtd4lw7OkPVjSb/Z+VARUMmf+0qSNgmHLgEVnAoGJsn8W8B4qtIay
4h4PuV0jPPlqJx6jMFOOEW72uqnfmqeNvClENXXW60xhnaxsf0up62fuW8ktu6Wf
lnX/lvTstBFZZQ8/XI1+G+BPf8TZf7mxu0WYVg1s/KWYasYMSw46as59nkqdq2Ii
qJnqHX/R20mWBhgpLse6wO0aNpky/rozEnikaPqyO1DShf6a6jXY8ADBg7spnK2/
h7sf1+F1xfi2dy2WGxc1EUMP1kTVUmbft7kOo2nA7+3YZwQuSJHaN/66HrzU2x5z
ayRUJ8+qDtfpEf17xthc/Uh253blFK96IoJJiqBfI6xt3IqOdHJq0OOC9zBbF6Rj
vKMsaxmc/nc6uOB2WePYSgkZ0qs/dRKBJs6+Ahn1KdGkadyd8mDKL86Oe8lncHdB
m/6sQjhKqFgngkCDOIlEJyWizqfN84AGqD5Zyxq0rbsN+9KLsHFfEbCRjgqjO5nS
FYSFtuKgCZl2gaYEslL1pIEYE6BD2Whjn/HWTRyWiULJr6SuavgcbxeNEQDuVCC+
fm0X7Z+qERaMAMR0vTMJK/NzT4GifrDpgmgbxc+34CtNBF5TriM8aXTNZZlsW00k
d0XRxFbbbtiT5VOaEHbny7R3MdTVutEc9E/BhLBvjSSrGX7vrryh6Oj++nthIIzm
F4M7I11S0TyA+UE06qF1C8rKmhcqU9MWy1SiccJ9KOWhJ5xwlsXBIID7wVygUhVl
ovzfKkDDPfRoBch6NdVkxNJx3gb63CUmC2TzfwOMh973nntMVzqqw9A7jYkro9ln
217kHUwMk3e83UgFL4nn7NCf3Kj0zhJ4jSfAsuQpV6e7dhzrlNya0lqrUsY2zFXP
xv8wUtg6Vo1KewgVQas4oElkgFjDN8RJ7uBAwfuE/b9NnYJoQd76G8DHei/1PHbu
tbtwN9I5RHaTvEOfetsJFnIAkCG6O4CQpzwHu1DdvEP4s6/el10b/4awBJ4VwOVZ
YHSe4X0DStTV4Cu6aLh5OvrOmGbieRj6HdGQ6syYCaEBTuxbBUUpjIAfVlReAIph
6aOrY6HNcCmeVmL5qm4dKr2XXOREsnUFuMqmfQuQd9pN3zlmS+RqCgSJuFrguFpd
mjo6UxZvbjE7yJjtCih38HRe5BaigP5RDRkXmiXjqJ4koLJpyjQh19k3BYGcdxUC
RCcYXydbGF7qHlnoaX9HnX7y6ZRsyKQpt91PMTGOUsB4fS8NhsqPpl2gdp4poLNs
+hqjWZJ3uuLotXBcgM39Dtq9tqqu9vM12T80UAfWnVEHrBphmukh49EhEr2sx/la
kAzRoTbLyTdlGVei8hI7/RtZIaIcOkzlhcFI5zmBlydyrv6/79vzt6WI/w9GVGpM
OuSM0NS2CDJ7Iw412nz3CV1pEXB551ZBmbme6NHUe4EtEsDbgkP1Z201H4j51yVz
wNoIksE5Bh5XRKuu4We5f9KZb+AEG9kxKJ5DbJk2YGJEQFTyfv0H68pl9urstPXD
aMQF806COe2uhGm5gV/skvPVTeEvStE3K8DxZgcWNcTMVk8ZjrUHNfguVVToP8hT
Fl4Iqo3r+JZEAGXnAbTpxUVC2Xxspf3jsT5xhUfB/NOexZxrXWnQZ+pscsbow0ba
GATtakD3TF2WBqq5WscmOex+lrJcBCWVIzVWdwi5ngAtm1S7efkJlFUvmi4OuYnN
RyZfxVIpoer8f2/xPXvxkOWFminDy5sFEvlh2/pnymfKOUV+CKih9ZApt+izlRJn
+sMIOW6Jhf/WYyjeN6KQpwi6CDpclQJXA1SVoOVVL5A3lotLjs0x7ThIcBoxCZBq
rFBhBu1gJgJ8guMySAHssIvhHHwXJsYEwzWCVAg/zIUXy4PLwIkgHApl+vGcldGv
Br5HNCuqQ2pD9z2RvzNneB/LrYB214i+BP2piO5HbmeJBhby93blGXVfQewQT6aF
dBlK8/jQM0rvb+LkmvQm2ypOttRpX2kyQXooJHYTTusaUr4jVmgngCvGtgqAQVqD
HULXfHWvugZbAh6dXF7gKnnsyDOWwAgy4OJRi8i0jCaZ8aWSFRUjeGKT26dg/ayB
U4QfMb8vL8tMdXVBfQLGcBgvrzQYrY69//pV6bX3SbLfUfWXV9eqUVWVPqVyPEwa
Tz/aGVnGv/dY8h2cVnrgSXJGlOO+mCwSl+k9nk7VcEaKYuNlaOP3ZlKJvVj1LefM
FODh4qTDBo5NkyfKu5fcZcOqDMBeGWXZzltE7CmvY7fOpDNMsuAoXYWI7q9gK82F
w+nS0tVFCIWYa9DgGMv9GKTOk4Ia9elkbWypdRE/4oz4QxmHsArEsK4gDI+wmcp7
/NsAZeuy96r2YDIUam4uASKOiAqrEfCv6B6cYctdYwZbAEXdo4fkGrCIjNRZmZGv
kcZzHzIymnAmKRTkPt/LQ7Rx27Qd/Vt++B3zt2ORFuopqowOP0ocGZtkm0daK3Fc
YDXMwIpf6Z8PwvvsG1bQHcSR+cUZi7vK7+hj/LGhMPafHM7HmFUbAxpJYr5CvR6y
V1pZQYltT8xWayCeMHlLAAg10RgDkqCnY4dHnrY4GdwI2O7Wpxomni7qVHMjn+cN
UTrd7EeVw+dxAIYosuqG7ua7ee3VGoOs+XMLrscAqHahfGbyYC+j+6Tow4qwWBdU
/W3NJXnRWaHTXFHllpClnxggPRQx4yPtgTOmBBVl/O0T6i4Bv0ygsJeZAqC3VmAJ
QodQTzGf2jwqsZf4uHKQa0EKGQvTGjFVgAFNpHmAuzyqh0b1pq5JeXiFERGsKC3j
xcJilq1XeIx4SL38YNuCxi4pnyJyLnGGHpNjdjeFO5lvgCaKPegsPo4hpNpTvBJ1
D7+o3E5CqxzjRt9kQmtwBbuH/SQX2T0x8aQ6vhwjj8ftDfw+FbjpMR9zfU0Lf8V7
UjVGIl2yiVBGScBZu1nSD83PxjFy3XdFtBYoU5OrlXwBEYQs91jwK7UCiGtjI2Ao
ZGkJaBd4AqP6voyJiGnC3LWFcmeMyzfExgiclQwfhFqqf762TX5JwG6xGqtdcNKS

[tor-commits] [tor/main] Merge branch 'hs_fuzzing'

2021-10-16 Thread nickm
commit 34f352986186b8542a4c7e473414a13c86d4a855
Merge: 8c18e9a949 37c0542d0d
Author: Nick Mathewson 
Date:   Sat Oct 16 10:49:41 2021 -0400

Merge branch 'hs_fuzzing'

 scripts/codegen/fuzzing_include_am.py |   2 +
 src/feature/hs/hs_descriptor.c|  16 ++---
 src/feature/hs/hs_descriptor.h|  19 ++
 src/test/fuzz/fuzz_hsdescv3_inner.c   | 119 ++
 src/test/fuzz/fuzz_hsdescv3_middle.c  | 116 +
 src/test/fuzz/include.am  |  61 +
 6 files changed, 325 insertions(+), 8 deletions(-)



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Quick-and-dirty fuzzer for inner-encrypted layer of hsv3 desc.

2021-10-16 Thread nickm
commit 88987ce8ebeea3fa2b8989cbe6dccb95d5d223e8
Author: Nick Mathewson 
Date:   Tue Jun 8 11:01:47 2021 -0400

Quick-and-dirty fuzzer for inner-encrypted layer of hsv3 desc.

Based on hsv3 outer-layer fuzzer; some code may be unnecessary.
---
 scripts/codegen/fuzzing_include_am.py |   3 +-
 src/feature/hs/hs_descriptor.c|  10 +--
 src/feature/hs/hs_descriptor.h|  10 +++
 src/test/fuzz/fuzz_hsdescv3_inner.c   | 119 ++
 src/test/fuzz/include.am  |  29 +
 5 files changed, 164 insertions(+), 7 deletions(-)

diff --git a/scripts/codegen/fuzzing_include_am.py 
b/scripts/codegen/fuzzing_include_am.py
index b52b956f81..d2d73a3c06 100755
--- a/scripts/codegen/fuzzing_include_am.py
+++ b/scripts/codegen/fuzzing_include_am.py
@@ -11,11 +11,10 @@ FUZZERS = """
diff
diff-apply
extrainfo
-   hsdescv2
hsdescv3
+   hsdescv3-inner
http
http-connect
-   iptsv2
microdesc
socks
strops
diff --git a/src/feature/hs/hs_descriptor.c b/src/feature/hs/hs_descriptor.c
index 10eca2176b..cad442718b 100644
--- a/src/feature/hs/hs_descriptor.c
+++ b/src/feature/hs/hs_descriptor.c
@@ -1639,10 +1639,10 @@ desc_decrypt_superencrypted(const hs_descriptor_t 
*desc, char **decrypted_out)
  * decrypted_out which contains the encrypted layer of the descriptor.
  * Return the length of decrypted_out on success else 0 is returned and
  * decrypted_out is set to NULL. */
-static size_t
-desc_decrypt_encrypted(const hs_descriptor_t *desc,
-   const curve25519_secret_key_t *client_auth_sk,
-   char **decrypted_out)
+MOCK_IMPL(STATIC size_t,
+desc_decrypt_encrypted,(const hs_descriptor_t *desc,
+const curve25519_secret_key_t *client_auth_sk,
+char **decrypted_out))
 {
   size_t encrypted_len = 0;
   char *encrypted_plaintext = NULL;
@@ -2259,7 +2259,7 @@ desc_decode_superencrypted_v3(const hs_descriptor_t *desc,
 
 /** Decode the version 3 encrypted section of the given descriptor desc. The
  * desc_encrypted_out will be populated with the decoded data. */
-static hs_desc_decode_status_t
+STATIC hs_desc_decode_status_t
 desc_decode_encrypted_v3(const hs_descriptor_t *desc,
  const curve25519_secret_key_t *client_auth_sk,
  hs_desc_encrypted_data_t *desc_encrypted_out)
diff --git a/src/feature/hs/hs_descriptor.h b/src/feature/hs/hs_descriptor.h
index 7e437faeb8..5f3531fac7 100644
--- a/src/feature/hs/hs_descriptor.h
+++ b/src/feature/hs/hs_descriptor.h
@@ -339,6 +339,16 @@ MOCK_DECL(STATIC size_t, decrypt_desc_layer,(const 
hs_descriptor_t *desc,
  bool is_superencrypted_layer,
  char **decrypted_out));
 
+STATIC hs_desc_decode_status_t desc_decode_encrypted_v3(
+ const hs_descriptor_t *desc,
+ const curve25519_secret_key_t *client_auth_sk,
+ hs_desc_encrypted_data_t *desc_encrypted_out);
+
+MOCK_DECL(STATIC size_t, desc_decrypt_encrypted,(
+const hs_descriptor_t *desc,
+const curve25519_secret_key_t *client_auth_sk,
+char **decrypted_out));
+
 #endif /* defined(HS_DESCRIPTOR_PRIVATE) */
 
 #endif /* !defined(TOR_HS_DESCRIPTOR_H) */
diff --git a/src/test/fuzz/fuzz_hsdescv3_inner.c 
b/src/test/fuzz/fuzz_hsdescv3_inner.c
new file mode 100644
index 00..5aa719f5c3
--- /dev/null
+++ b/src/test/fuzz/fuzz_hsdescv3_inner.c
@@ -0,0 +1,119 @@
+/* Copyright (c) 2017-2021, The Tor Project, Inc. */
+/* See LICENSE for licensing information */
+
+#define HS_DESCRIPTOR_PRIVATE
+
+#include "core/or/or.h"
+#include "trunnel/ed25519_cert.h" /* Trunnel interface. */
+#include "lib/crypt_ops/crypto_ed25519.h"
+#include "feature/hs/hs_descriptor.h"
+#include "feature/dirparse/unparseable.h"
+
+#include "test/fuzz/fuzzing.h"
+
+static void
+mock_dump_desc__nodump(const char *desc, const char *type)
+{
+  (void)desc;
+  (void)type;
+}
+
+static int
+mock_rsa_ed25519_crosscert_check(const uint8_t *crosscert,
+ const size_t crosscert_len,
+ const crypto_pk_t *rsa_id_key,
+ const ed25519_public_key_t *master_key,
+ const time_t reject_if_expired_before)
+{
+  (void) crosscert;
+  (void) crosscert_len;
+  (void) rsa_id_key;
+  (void) master_key;
+  (void) reject_if_expired_before;
+  return 0;
+}
+
+static size_t
+mock_decrypt_desc_layer(const hs_descriptor_t *desc,
+const uint8_t *descriptor_cookie,
+bool is_superencrypted_layer,
+char **decrypted_out)
+{
+  (void)is_superencrypted_layer;
+  (void)desc;
+  (void)descriptor_cookie;
+  const size_t 

[tor-commits] [torspec/main] Start writing a specification for DoS defense mechanism.

2021-10-15 Thread nickm
commit 7ebce31d3fa18405ad5139ec6df003b1d271b204
Author: Nick Mathewson 
Date:   Fri Oct 15 11:09:30 2021 -0400

Start writing a specification for DoS defense mechanism.
---
 dos-spec.md  | 97 
 tor-spec.txt |  2 ++
 2 files changed, 99 insertions(+)

diff --git a/dos-spec.md b/dos-spec.md
new file mode 100644
index 000..d1ca55c
--- /dev/null
+++ b/dos-spec.md
@@ -0,0 +1,97 @@
+# Denial-of-service prevention mechanisms in Tor
+
+This document is incomplete; it describes some mechanisms that Tor
+uses to avoid different kinds of denial-of-service attacks.
+
+## Handling low-memory conditions
+
+(See also `tor-spec.txt`, section 8.1.)
+
+The Tor protocol requires clients, onion services, relays, and
+authorities to store various kind of information in buffers and
+caches.  But an attacker can use these buffers and queues to queues
+to exhaust the memory of the a targeted Tor process, and force the
+operating system to kill that process.
+
+Worse still, the ability to kill targeted Tor instances can be used
+to facilitate traffic analysis. (For example, see
+[the "Sniper Attack" paper](https://www.freehaven.net/anonbib/#sniper14)
+by Jansen, Tschorsch, Johnson, and Scheuermann.
+
+With this in mind, any Tor implementation—especially one that
+runs as a relay or onion service—must take steps to prevent
+memory-based denial-of-service attacks.
+
+### Detecting low memory
+
+The easiest way to notice you're out of memory would, in theory, be
+getting an error when you try to allocate more.  Unfortunately, some
+systems (e.g. Linux) won't actually give you an "out of memory"
+error when you're low on memory.  Instead, they overcommit and
+promise you memory that they can't actually provide… and then later on,
+they might kill processes that actually try to use more memory than
+they wish they'd given out.
+
+So in practice, the mainline Tor implementation uses a different
+strategy.  It uses a self-imposed "MaxMemInQueues" value as an
+upper bound for how much memory it's willing to allocate to certain
+kinds of queued usages.  This value can either be set by the user,
+or derived from a fraction of the total amount of system RAM.
+
+As of Tor 0.4.7.x, the MaxMemInQueues mechanism tracks the following
+kinds of allocation:
+  * Cells queued on circuits.
+  * Per-connection read or write buffers.
+  * On-the-fly compression or decompression state.
+  * Half-open stream records.
+  * Cached onion service descriptors (hsdir only).
+  * Cached DNS resolves (relay only).
+  * GEOIP-based  usage activity statistics.
+
+Note that directory caches aren't counted, since those are stored on
+disk and accessed via mmap.
+
+### Responding to low memory
+
+If our allocations exceed MaxMemInQueues, then we take the following
+steps to reduce our memory allocation.
+
+*Freeing from caches*: For each of our onion service descriptor
+cache, our DNS cache, and our GEOIP statistics cache, we check
+whether they account for greater than 20% of our total allocation.
+If they do, we free memory from the offending cache until the total
+remaining is no more than 10% of our total allocation.
+
+When freeing entries from a cache, we aim to free (approximately)
+the oldest entries first.
+
+*Freeing from buffers*: After freeing data from caches, we see
+whether allocations are still above 90% of MaxMemInQueues. If they
+are, we try to close circuits and connections until we are below 90%
+of MaxMemInQueues.
+
+When deciding to what circuits to free, we sort them based on the
+age of the oldest data in their queues, and free the ones with the
+oldest data.  (For example, a circuit on which a single cell has
+been queued for 5 minutes would be freed before a circuit where 100
+cells have been queued for 5 seconds.)  "Data queued on a circuit"
+includes all data that we could drop if the circuit were destroyed:
+not only the cells on the circuit's cell queue, but also any bytes
+queued in buffers associated with streams or half-stream records
+attached to the circuit.
+
+We free non-tunneled directory connections according to a similar
+rule, according to the age of their oldest queued data.
+
+Upon freeing a circuit, a "DESTROY cell" must be sent in both
+directions.
+
+### Reporting low memory.
+
+We define a "low threshold" equal to 3/4 of MaxMemInQueues.  Every
+time our memory usage is above the low threshold, we record
+ourselves as being "under memory pressure".
+
+(This is not currently reported.)
+
+
diff --git a/tor-spec.txt b/tor-spec.txt
index 4b2c7f2..d0d2f73 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -2153,6 +2153,8 @@ see tor-design.pdf.
 
 8.1. Memory exhaustion.
 
+   (See also dos-spec.md.)
+
If RAM becomes low, an OR should begin destroying circuits until
more memory is free again.  We recommend the following algorithm:
 

___
tor-commits mailing list
tor-commits@lists.torproject.org

[tor-commits] [torspec/main] Lower the maximum value for guard-extreme-restriction-percent.

2021-10-14 Thread nickm
commit 98cf7ede083dc0fbb7242c7e557a8a2d5499e135
Author: Nick Mathewson 
Date:   Thu Oct 14 12:32:57 2021 -0400

Lower the maximum value for guard-extreme-restriction-percent.

The previous value was int32_max, which doesn't really make sense.

It's safe to do this, since the effect of getting a high value is
just to clamp it at 100%.

Closes torspec#66.
---
 param-spec.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/param-spec.txt b/param-spec.txt
index b2882a6..3cf36b2 100644
--- a/param-spec.txt
+++ b/param-spec.txt
@@ -363,8 +363,9 @@ Table of Contents
 "guard-extreme-restriction-percent" -- Warn the user if they have
 configured tor to exclude so many guards that the available guard
 bandwidth is less than this percentage of the total.
-Min: 1. Max: INT32_MAX. Default: 1.
-First appeared: 0.3.0
+Min: 1. Max: 100. Default: 1.
+First appeared: 0.3.0.  MAX was INT32_MAX, which would have no meaningful
+effect.  MAX lowered to 100 in 0.4.7.
 
 "guard-min-filtered-sample-size" -- If fewer than this number of
 guards is available in the sample after filtering out unusable

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] ci: Set 5MB data for all chutney tests

2021-10-14 Thread nickm
commit aae40113c76a5b0eb93562bcfba9dddcd6d5cdd5
Author: David Goulet 
Date:   Thu Oct 14 11:39:10 2021 -0400

ci: Set 5MB data for all chutney tests

Closes #40485

Signed-off-by: David Goulet 
---
 changes/ticket40485 | 3 +++
 scripts/ci/ci-driver.sh | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/changes/ticket40485 b/changes/ticket40485
new file mode 100644
index 00..849ee0719f
--- /dev/null
+++ b/changes/ticket40485
@@ -0,0 +1,3 @@
+  o Testing (CI, chutney):
+- Bump the data size that chutney transmit to 5MB in order to trigger flow
+  control and congestion window code. Closes ticket 40485.
diff --git a/scripts/ci/ci-driver.sh b/scripts/ci/ci-driver.sh
index d0b563a09b..ff4881dd8e 100755
--- a/scripts/ci/ci-driver.sh
+++ b/scripts/ci/ci-driver.sh
@@ -449,6 +449,8 @@ if [[ "${CHUTNEY}" = "yes" ]]; then
 start_section "Chutney"
 export CHUTNEY_TOR_SANDBOX=0
 export CHUTNEY_ALLOW_FAILURES=2
+# Send 5MB for every verify check.
+export CHUTNEY_DATA_BYTES=500
 if runcmd make "${CHUTNEY_MAKE_TARGET}"; then
 hooray "Chutney tests have succeeded"
 else



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Merge remote-tracking branch 'tor-gitlab/mr/457'

2021-10-14 Thread nickm
commit ed4b8ca74b4300cb5b5b43ee751915a31796ccb7
Merge: 75e195737e aae40113c7
Author: Nick Mathewson 
Date:   Thu Oct 14 12:25:22 2021 -0400

Merge remote-tracking branch 'tor-gitlab/mr/457'

 changes/ticket40485 | 3 +++
 scripts/ci/ci-driver.sh | 2 ++
 2 files changed, 5 insertions(+)

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Correct a version number.

2021-10-14 Thread nickm
commit 75e195737e4dabf9979f904e03efddeee58b78df
Author: Nick Mathewson 
Date:   Thu Oct 14 12:23:36 2021 -0400

Correct a version number.
---
 changes/bug40400 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/changes/bug40400 b/changes/bug40400
index 2ac5cf5dce..47bb1e6a1e 100644
--- a/changes/bug40400
+++ b/changes/bug40400
@@ -3,4 +3,4 @@
   instead log it at DEBUG. In every case where we would want to log
   this as a protocol warning, we are already logging another warning
   from inside circuit_receive_relay_cell. Fixes part of bug 40400;
-  bugfix on 0.1.1.9.
+  bugfix on 0.1.1.9-alpha.

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] guard-spec: Clarify how the list of primary guards can change.

2021-10-13 Thread nickm
commit a96f2f70cabb17867f8de72be5db3fc09013e6ac
Author: Nick Mathewson 
Date:   Wed Oct 13 17:05:59 2021 -0400

guard-spec: Clarify how the list of primary guards can change.
---
 guard-spec.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/guard-spec.txt b/guard-spec.txt
index 32c4faf..267ad1c 100644
--- a/guard-spec.txt
+++ b/guard-spec.txt
@@ -426,6 +426,10 @@ Table of Contents
 
   Once an element has been added to {PRIMARY_GUARDS}, we do not remove it
   until it is replaced by some element from {CONFIRMED_GUARDS}.
+  That is: if a non-primary guard becomes confirmed and not every primary
+  guard is confirmed, then the list of primary guards list is regenerated,
+  first from the confirmed guards (as before), and then from any
+  non-confirmed primary guards guards.
 
   Note that {PRIMARY_GUARDS} do not have to be in
   {USABLE_FILTERED_GUARDS}: they might be unreachable.



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] guard-spec: adjust retry schedule to match Tor's behavior.

2021-10-13 Thread nickm
commit 1c9b4235101582e4c9c9233ed4491c6c71f22439
Author: Nick Mathewson 
Date:   Wed Oct 13 17:09:36 2021 -0400

guard-spec: adjust retry schedule to match Tor's behavior.
---
 guard-spec.txt | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/guard-spec.txt b/guard-spec.txt
index 267ad1c..e0f61d1 100644
--- a/guard-spec.txt
+++ b/guard-spec.txt
@@ -719,15 +719,15 @@ A.1.  Parameters with suggested values. 
[Section:PARAM_VALS]
{param:N_PRIMARY_GUARDS} -- 3
 
{param:PRIMARY_GUARDS_RETRY_SCHED}
-  -- every 30 minutes for the first 6 hours.
-  -- every 2 hours for the next 3.75 days.
-  -- every 4 hours for the next 3 days.
+  -- every 10 minutes for the first six hours,
+  -- every 90 minutes for the next 90 hours,
+  -- every 4 hours for the next 3 days,
   -- every 9 hours thereafter.
 
-   {param:GUARDS_RETRY_SCHED} -- 1 hour
-  -- every hour for the first 6 hours.
-  -- every 4 hours for the next 3.75 days.
-  -- every 18 hours for the next 3 days.
+   {param:GUARDS_RETRY_SCHED} --
+  -- every hour for the first six hours,
+  -- every 4 hours for the 90 hours,
+  -- every 18 hours for the next 3 days,
   -- every 36 hours thereafter.
 
{param:INTERNET_LIKELY_DOWN_INTERVAL} -- 10 minutes

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Clarify guard-spec: Define "sample order".

2021-10-13 Thread nickm
commit 01ab7bd92502bbf8c3725a15de538757b3b6bc76
Author: Nick Mathewson 
Date:   Wed Oct 13 17:02:26 2021 -0400

Clarify guard-spec: Define "sample order".
---
 guard-spec.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/guard-spec.txt b/guard-spec.txt
index 883c2bf..32c4faf 100644
--- a/guard-spec.txt
+++ b/guard-spec.txt
@@ -421,8 +421,8 @@ Table of Contents
   {CONFIRMED_GUARDS} and {FILTERED_GUARDS}, and take the first
   {N_PRIMARY_GUARDS} elements.  If there are fewer than
   {N_PRIMARY_GUARDS} elements, append additional elements to
-  PRIMARY_GUARDS chosen from ({FILTERED_GUARDS} - {CONFIRMED_GUARDS}) in
-  sample order.
+  PRIMARY_GUARDS chosen from ({FILTERED_GUARDS} - {CONFIRMED_GUARDS}),
+  ordered in "sample order" (that is, by {ADDED_ON_DATE}).
 
   Once an element has been added to {PRIMARY_GUARDS}, we do not remove it
   until it is replaced by some element from {CONFIRMED_GUARDS}.



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Proposal 335: alternative implementation for MiddleOnly.

2021-10-08 Thread nickm
commit ecd41d465a5239a82e06ff88e4c03c2cbc99f2ec
Author: Nick Mathewson 
Date:   Fri Oct 8 10:22:53 2021 -0400

Proposal 335: alternative implementation for MiddleOnly.
---
 proposals/000-index.txt|  2 +
 proposals/335-middle-only-redux.md | 77 ++
 proposals/BY_INDEX.md  |  1 +
 proposals/README.md|  1 +
 4 files changed, 81 insertions(+)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index cb9a9fa..af0c8b1 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -255,6 +255,7 @@ Proposals by number:
 332  Ntor protocol with extra data, version 3 [OPEN]
 333  Vanguards lite [DRAFT]
 334  A Directory Authority Flag To Mark Relays As Middle-only [OPEN]
+335  An authority-only design for MiddleOnly [OPEN]
 
 
 Proposals by status:
@@ -300,6 +301,7 @@ Proposals by status:
330  Modernizing authority contact entries
332  Ntor protocol with extra data, version 3
334  A Directory Authority Flag To Mark Relays As Middle-only
+   335  An authority-only design for MiddleOnly
  ACCEPTED:
265  Load Balancing with Overhead Parameters [for 0.2.9.x]
275  Stop including meaningful "published" time in microdescriptor 
consensus [for 0.3.1.x-alpha]
diff --git a/proposals/335-middle-only-redux.md 
b/proposals/335-middle-only-redux.md
new file mode 100644
index 000..19e6c1b
--- /dev/null
+++ b/proposals/335-middle-only-redux.md
@@ -0,0 +1,77 @@
+```
+Filename: 335-middle-only-redux.md
+Title: An authority-only design for MiddleOnly
+Author: Nick Mathewson
+Created: 2021-10-08
+Status: Open
+```
+
+# Introduction
+
+This proposal describes an alternative design for a `MiddleOnly`
+flag.  Instead of making changes at the client level, it adds a
+little increased complexity at the directory authority's voting
+process.  In return for that complexity, this design will work
+without additional changes required from Tor clients.
+
+For additional motivation and discussion see proposal 334 by Neel
+Chauhan, and the related discussions on tor-dev.
+
+# Protocol changes
+
+## Generating votes
+
+When voting for a relay with the `MiddleOnly` flag, an authority
+should set all flags indicating that a relay is unusable for a
+particular purpose, and against all flags indicating that the relay
+is usable for a particular position.
+
+These flags SHOULD be set in a vote whenever `MiddleOnly` is
+present, and only when the authority is configured to vote on the
+`BadExit` flag.
+
+  * `BadExit`
+
+These flags SHOULD be cleared in a vote whenever `MiddleOnly` is
+present.
+
+  * `Exit`
+  * `Guard`
+  * `HSDir`
+  * `V2Dir`
+
+## Computing a consensus
+
+This proposal will introduce a new consensus method (probably 32).
+Whenever computing a consensus using that consensus method or later,
+authorities post-process the set of flags that appear in the
+consensus after flag voting takes place, by applying the same rule
+as above.
+
+That is, with this consensus method, the authorities first compute
+the presence or absence of each flag on each relay as usual.  Then,
+if the `MiddleOnly` flag is present, the authorities set `BadExit`,
+and clear `Exit`, `Guard`, `HSDir`, and `V2Dir`.
+
+# Configuring authorities
+
+We'll need a means for configuring which relays will receive this
+flag.  For now, we'll just reuse the same mechanism as
+`AuthDirReject` and `AuthDirBadExit`: a set of torrc configuration
+lines listing relays by address.  We'll call this
+`AuthDirMiddleOnly`.
+
+We'll also add an `AuthDirListsMiddleOnly` option to turn on or off
+voting on this option at all.
+
+# Notes on safety and migration
+
+Under this design, the MiddleOnly option becomes useful immediately,
+since authorities that use it will stop voting for certain
+additional options for MiddleOnly relays without waiting for the
+other authorities.
+
+We don't need to worry about a single authority setting MiddleOnly
+unilaterally for all relays, since the MiddleOnly flag will have no
+special effect until most authorities have upgraded to the new
+consensus method.
diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md
index 9fa8a78..5e07863 100644
--- a/proposals/BY_INDEX.md
+++ b/proposals/BY_INDEX.md
@@ -252,4 +252,5 @@ Below are a list of proposals sorted by their proposal 
number.  See
 * 
[`332-ntor-v3-with-extra-data.md`](/proposals/332-ntor-v3-with-extra-data.md): 
Ntor protocol with extra data, version 3 [OPEN]
 * [`333-vanguards-lite.md`](/proposals/333-vanguards-lite.md): Vanguards lite 
[DRAFT]
 * [`334-middle-only-flag.txt`](/proposals/334-middle-only-flag.txt): A 
Directory Authority Flag To Mark Relays As Middle-only [OPEN]
+* [`335-middle-only-redux.md`](/proposals/335-middle-only-redux.md): An 
authority-only design for MiddleOnly [OPEN]
 
diff --git a/proposals/README.md b/proposals/README.md
index 3e3645a..49968f8 100644
--- a/proposals/README.md
+++ b/proposals/README.md
@@ -42,6 +42,7 @@ for discussion.
 * 

[tor-commits] [tor/main] cc: Fix 32bit arithmetic to actually be 64bit

2021-10-05 Thread nickm
commit cdbf756b90b05fcf8211d6fea302652923af4171
Author: David Goulet 
Date:   Tue Oct 5 13:47:49 2021 -0400

cc: Fix 32bit arithmetic to actually be 64bit

Coverity report: CID 1492322



*** CID 1492322:  Integer handling issues  (OVERFLOW_BEFORE_WIDEN)
/src/core/or/congestion_control_flow.c: 399 in circuit_process_stream_xon()
393   }
394
395   log_info(LD_EDGE, "Got XON: %d", xon->kbps_ewma);
396
397   /* Adjust the token bucket of this edge connection with the drain 
rate in
398* the XON. Rate is in bytes from kilobit (kpbs). */
>>> CID 1492322:  Integer handling issues  (OVERFLOW_BEFORE_WIDEN)
>>> Potentially overflowing expression "xon_cell_get_kbps_ewma(xon) * 
1000U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit 
arithmetic, and then used in a context that expects an expression of type 
"uint64_t" (64 bits, unsigned).
399   uint64_t rate = xon_cell_get_kbps_ewma(xon) * 1000;
400   if (rate == 0 || INT32_MAX < rate) {
401 /* No rate. */
402 rate = INT32_MAX;
403   }
404   token_bucket_rw_adjust(>bucket, (uint32_t) rate, (uint32_t) 
rate);

Fixes #40478

Signed-off-by: David Goulet 
---
 src/core/or/congestion_control_flow.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/core/or/congestion_control_flow.c 
b/src/core/or/congestion_control_flow.c
index 0c2baa96e2..9e0cd670c7 100644
--- a/src/core/or/congestion_control_flow.c
+++ b/src/core/or/congestion_control_flow.c
@@ -396,7 +396,7 @@ circuit_process_stream_xon(edge_connection_t *conn,
 
   /* Adjust the token bucket of this edge connection with the drain rate in
* the XON. Rate is in bytes from kilobit (kpbs). */
-  uint64_t rate = xon_cell_get_kbps_ewma(xon) * 1000;
+  uint64_t rate = ((uint64_t) xon_cell_get_kbps_ewma(xon) * 1000);
   if (rate == 0 || INT32_MAX < rate) {
 /* No rate. */
 rate = INT32_MAX;

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] sandbox: Allow use with fragile hardening

2021-09-29 Thread nickm
commit fbf2e7e9218b8e0ffabcd59fab2322d7c2c7178c
Author: Simon South 
Date:   Fri Sep 24 14:08:58 2021 -0400

sandbox: Allow use with fragile hardening

When building with --enable-fragile-hardening, add or relax Linux
seccomp rules to allow AddressSanitizer to execute normally if the
process terminates with the sandbox active.

Further resolves issue 11477.
---
 changes/issue11477|  8 +
 src/app/main/main.c   |  7 +
 src/lib/sandbox/sandbox.c | 75 +++
 3 files changed, 90 insertions(+)

diff --git a/changes/issue11477 b/changes/issue11477
new file mode 100644
index 00..bb5d9e4099
--- /dev/null
+++ b/changes/issue11477
@@ -0,0 +1,8 @@
+  o Minor bugfixes (fragile-hardening, sandbox):
+- When building with --enable-fragile-hardening, add or relax Linux
+  seccomp rules to allow AddressSanitizer to execute normally if the
+  process terminates with the sandbox active. This has the side
+  effect of disabling the filtering of file- and directory-open
+  requests on most systems and dilutes the effectiveness of the
+  sandbox overall, as a wider range of system calls must be
+  permitted. Fixes bug 11477; bugfix on 0.2.5.4-alpha.
diff --git a/src/app/main/main.c b/src/app/main/main.c
index 89564490e6..0959b0db71 100644
--- a/src/app/main/main.c
+++ b/src/app/main/main.c
@@ -1343,6 +1343,13 @@ tor_run_main(const tor_main_configuration_t *tor_cfg)
   pubsub_connect();
 
   if (get_options()->Sandbox && get_options()->command == CMD_RUN_TOR) {
+#ifdef ENABLE_FRAGILE_HARDENING
+log_warn(LD_CONFIG, "Sandbox is enabled but this Tor was built using "
+ "fragile compiler hardening. The sandbox may be unable to filter "
+ "requests to open files and directories and its overall "
+ "effectiveness will be reduced.");
+#endif
+
 sandbox_cfg_t* cfg = sandbox_init_filter();
 
 if (sandbox_init(cfg)) {
diff --git a/src/lib/sandbox/sandbox.c b/src/lib/sandbox/sandbox.c
index 0e5a1c..a78e4a7ac7 100644
--- a/src/lib/sandbox/sandbox.c
+++ b/src/lib/sandbox/sandbox.c
@@ -58,6 +58,10 @@
 #include 
 #include 
 
+#ifdef ENABLE_FRAGILE_HARDENING
+#include 
+#endif
+
 #include 
 #include 
 #include 
@@ -191,6 +195,9 @@ static int filter_nopar_gen[] = {
 SCMP_SYS(getgid32),
 #endif
 SCMP_SYS(getpid),
+#ifdef ENABLE_FRAGILE_HARDENING
+SCMP_SYS(getppid),
+#endif
 #ifdef __NR_getrlimit
 SCMP_SYS(getrlimit),
 #endif
@@ -532,6 +539,24 @@ sb_open(scmp_filter_ctx ctx, sandbox_cfg_t *filter)
 
   int use_openat = libc_uses_openat_for_open();
 
+#ifdef ENABLE_FRAGILE_HARDENING
+  /* AddressSanitizer uses the "open" syscall to access information about the
+   * running process via the filesystem, so that call must be allowed without
+   * restriction or the sanitizer will be unable to execute normally when the
+   * process terminates. */
+  rc = seccomp_rule_add_0(ctx, SCMP_ACT_ALLOW, SCMP_SYS(open));
+  if (rc != 0) {
+log_err(LD_BUG,"(Sandbox) failed to add open syscall, received "
+"libseccomp error %d", rc);
+return rc;
+  }
+
+  /* If glibc also uses only the "open" syscall to open files on this system
+   * there is no need to consider any additional rules. */
+  if (!use_openat)
+return 0;
+#endif
+
   // for each dynamic parameter filters
   for (elem = filter; elem != NULL; elem = elem->next) {
 smp_param_t *param = elem->param;
@@ -687,6 +712,34 @@ sb_opendir(scmp_filter_ctx ctx, sandbox_cfg_t *filter)
   return 0;
 }
 
+#ifdef ENABLE_FRAGILE_HARDENING
+/**
+ * Function responsible for setting up the ptrace syscall for
+ * the seccomp filter sandbox.
+ */
+static int
+sb_ptrace(scmp_filter_ctx ctx, sandbox_cfg_t *filter)
+{
+  int rc;
+  pid_t pid = getpid();
+  (void) filter;
+
+  rc = seccomp_rule_add_2(ctx, SCMP_ACT_ALLOW, SCMP_SYS(ptrace),
+  SCMP_CMP(0, SCMP_CMP_EQ, PTRACE_ATTACH),
+  SCMP_CMP(1, SCMP_CMP_EQ, pid));
+  if (rc)
+return rc;
+
+  rc = seccomp_rule_add_2(ctx, SCMP_ACT_ALLOW, SCMP_SYS(ptrace),
+  SCMP_CMP(0, SCMP_CMP_EQ, PTRACE_GETREGS),
+  SCMP_CMP(1, SCMP_CMP_EQ, pid));
+  if (rc)
+return rc;
+
+  return 0;
+}
+#endif
+
 /**
  * Function responsible for setting up the socket syscall for
  * the seccomp filter sandbox.
@@ -1009,6 +1062,18 @@ sb_prctl(scmp_filter_ctx ctx, sandbox_cfg_t *filter)
   int rc = 0;
   (void) filter;
 
+#ifdef ENABLE_FRAGILE_HARDENING
+  rc = seccomp_rule_add_1(ctx, SCMP_ACT_ALLOW, SCMP_SYS(prctl),
+  SCMP_CMP(0, SCMP_CMP_EQ, PR_GET_DUMPABLE));
+  if (rc)
+return rc;
+
+  rc = seccomp_rule_add_1(ctx, SCMP_ACT_ALLOW, SCMP_SYS(prctl),
+  SCMP_CMP(0, SCMP_CMP_EQ, PR_SET_PTRACER));
+  if (rc)
+return rc;
+#endif
+
   rc = seccomp_rule_add_1(ctx, SCMP_ACT_ALLOW, SCMP_SYS(prctl),
   SCMP_CMP(0, SCMP_CMP_EQ, PR_SET_DUMPABLE));
   if (rc)
@@ -1053,6 +1118,13 @@ sb_rt_sigprocmask(scmp_filter_ctx ctx, sandbox_cfg_t 
*filter)
   int rc = 0;
   

[tor-commits] [tor/main] configure.ac: Define ENABLE_COVERAGE macro

2021-09-29 Thread nickm
commit 3bc3a108955c7b25a13808a2cfefcc77d2364cf4
Author: Simon South 
Date:   Thu Sep 23 09:21:13 2021 -0400

configure.ac: Define ENABLE_COVERAGE macro

Allow conditional compilation based on whether the "--enable-coverage"
configure option was specified.
---
 configure.ac | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configure.ac b/configure.ac
index b4617a4003..f010c547b7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -119,6 +119,11 @@ AM_CONDITIONAL(USE_RUST, test "x$enable_rust" = "xyes")
 AM_CONDITIONAL(USE_NSS, test "x$enable_nss" = "xyes")
 AM_CONDITIONAL(USE_OPENSSL, test "x$enable_nss" != "xyes")
 
+if test "x$enable_coverage" = "xyes"; then
+  AC_DEFINE(ENABLE_COVERAGE, 1,
+   [Defined if coverage support is enabled for the unit tests])
+fi
+
 if test "x$enable_nss" = "xyes"; then
   AC_DEFINE(ENABLE_NSS, 1,
[Defined if we're building with NSS.])



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] configure.ac: Define ENABLE_FRAGILE_HARDENING macro

2021-09-29 Thread nickm
commit 352677556e14480753f75e8abe1f584f1580f1b2
Author: Simon South 
Date:   Wed Sep 22 14:42:45 2021 -0400

configure.ac: Define ENABLE_FRAGILE_HARDENING macro

Allow conditional compilation based on whether the
"--enable-fragile-hardening" configure option was specified.
---
 configure.ac | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure.ac b/configure.ac
index 23ba4b0d2d..b4617a4003 100644
--- a/configure.ac
+++ b/configure.ac
@@ -233,6 +233,7 @@ AC_ARG_ENABLE(fragile-hardening,
 AS_HELP_STRING(--enable-fragile-hardening, [enable more fragile and 
expensive compiler hardening; makes Tor slower]))
 if test "x$enable_expensive_hardening" = "xyes" || test 
"x$enable_fragile_hardening" = "xyes"; then
   fragile_hardening="yes"
+  AC_DEFINE(ENABLE_FRAGILE_HARDENING, 1, [Defined if we're building with 
additional, fragile and expensive compiler hardening])
   AC_DEFINE(DEBUG_SMARTLIST, 1, [Enable smartlist debugging])
 fi
 



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] test: Add sandbox unit tests

2021-09-29 Thread nickm
commit 1a10948260d915d4982415e37dd6495bca9ef545
Author: Simon South 
Date:   Thu Sep 2 11:04:23 2021 -0400

test: Add sandbox unit tests
---
 changes/issue16803  |   2 +
 src/test/include.am |   1 +
 src/test/test.c |   4 +
 src/test/test.h |   1 +
 src/test/test_sandbox.c | 348 
 5 files changed, 356 insertions(+)

diff --git a/changes/issue16803 b/changes/issue16803
new file mode 100644
index 00..7d0dd833e2
--- /dev/null
+++ b/changes/issue16803
@@ -0,0 +1,2 @@
+  o Testing:
+- Add unit tests for the Linux seccomp sandbox. Resolves issue 16803.
diff --git a/src/test/include.am b/src/test/include.am
index 0dc1630044..fb2c03ceb9 100644
--- a/src/test/include.am
+++ b/src/test/include.am
@@ -231,6 +231,7 @@ src_test_test_SOURCES += \
src/test/test_routerkeys.c \
src/test/test_routerlist.c \
src/test/test_routerset.c \
+   src/test/test_sandbox.c \
src/test/test_scheduler.c \
src/test/test_sendme.c \
src/test/test_shared_random.c \
diff --git a/src/test/test.c b/src/test/test.c
index 0aa1353ec2..c38d78da30 100644
--- a/src/test/test.c
+++ b/src/test/test.c
@@ -52,6 +52,7 @@
 #include "core/crypto/onion_fast.h"
 #include "core/crypto/onion_tap.h"
 #include "core/or/policies.h"
+#include "lib/sandbox/sandbox.h"
 #include "app/config/statefile.h"
 #include "lib/crypt_ops/crypto_curve25519.h"
 #include "feature/nodelist/networkstatus.h"
@@ -732,6 +733,9 @@ struct testgroup_t testgroups[] = {
   { "routerkeys/", routerkeys_tests },
   { "routerlist/", routerlist_tests },
   { "routerset/" , routerset_tests },
+#ifdef USE_LIBSECCOMP
+  { "sandbox/" , sandbox_tests },
+#endif
   { "scheduler/", scheduler_tests },
   { "sendme/", sendme_tests },
   { "shared-random/", sr_tests },
diff --git a/src/test/test.h b/src/test/test.h
index 0a22043acc..e17bce427c 100644
--- a/src/test/test.h
+++ b/src/test/test.h
@@ -184,6 +184,7 @@ extern struct testcase_t router_tests[];
 extern struct testcase_t routerkeys_tests[];
 extern struct testcase_t routerlist_tests[];
 extern struct testcase_t routerset_tests[];
+extern struct testcase_t sandbox_tests[];
 extern struct testcase_t scheduler_tests[];
 extern struct testcase_t sendme_tests[];
 extern struct testcase_t socks_tests[];
diff --git a/src/test/test_sandbox.c b/src/test/test_sandbox.c
new file mode 100644
index 00..e5064c58ec
--- /dev/null
+++ b/src/test/test_sandbox.c
@@ -0,0 +1,348 @@
+/* Copyright (c) 2021, The Tor Project, Inc. */
+/* See LICENSE for licensing information */
+
+#ifndef _LARGEFILE64_SOURCE
+/**
+ * Temporarily required for O_LARGEFILE flag. Needs to be removed
+ * with the libevent fix.
+ */
+#define _LARGEFILE64_SOURCE
+#endif /* !defined(_LARGEFILE64_SOURCE) */
+
+#include "orconfig.h"
+
+#include "lib/sandbox/sandbox.h"
+
+#ifdef USE_LIBSECCOMP
+
+#include 
+#ifdef HAVE_FCNTL_H
+#include 
+#endif
+#ifdef HAVE_SYS_STAT_H
+#include 
+#endif
+#ifdef HAVE_UNISTD_H
+#include 
+#endif
+
+#include "core/or/or.h"
+
+#include "test/test.h"
+#include "test/log_test_helpers.h"
+
+typedef struct {
+  sandbox_cfg_t *cfg;
+
+  char *file_ops_allowed;
+  char *file_ops_blocked;
+
+  char *file_rename_target_allowed;
+
+  char *dir_ops_allowed;
+  char *dir_ops_blocked;
+} sandbox_data_t;
+
+/* All tests are skipped when coverage support is enabled (see further below)
+ * as the sandbox interferes with the use of gcov.  Prevent a compiler warning
+ * by omitting these definitions in that case. */
+#ifndef ENABLE_COVERAGE
+static void *
+setup_sandbox(const struct testcase_t *testcase)
+{
+  sandbox_data_t *data = tor_malloc_zero(sizeof(*data));
+
+  (void)testcase;
+
+  /* Establish common file and directory names within the test suite's
+   * temporary directory. */
+  data->file_ops_allowed = tor_strdup(get_fname("file_ops_allowed"));
+  data->file_ops_blocked = tor_strdup(get_fname("file_ops_blocked"));
+
+  data->file_rename_target_allowed =
+tor_strdup(get_fname("file_rename_target_allowed"));
+
+  data->dir_ops_allowed = tor_strdup(get_fname("dir_ops_allowed"));
+  data->dir_ops_blocked = tor_strdup(get_fname("dir_ops_blocked"));
+
+  /* Create the corresponding filesystem objects. */
+  creat(data->file_ops_allowed, S_IRWXU);
+  creat(data->file_ops_blocked, S_IRWXU);
+  mkdir(data->dir_ops_allowed, S_IRWXU);
+  mkdir(data->dir_ops_blocked, S_IRWXU);
+
+  /* Create the sandbox configuration. */
+  data->cfg = sandbox_cfg_new();
+
+  sandbox_cfg_allow_open_filename(>cfg,
+  tor_strdup(data->file_ops_allowed));
+  sandbox_cfg_allow_open_filename(>cfg,
+  tor_strdup(data->dir_ops_allowed));
+
+  sandbox_cfg_allow_chmod_filename(>cfg,
+   tor_strdup(data->file_ops_allowed));
+  sandbox_cfg_allow_chmod_filename(>cfg,
+   tor_strdup(data->dir_ops_allowed));
+  

[tor-commits] [chutney/main] Document some issues around arti config.

2021-09-27 Thread nickm
commit 78f4bd03c3c236bd3932e24a0236ea2fa64387b5
Author: Nick Mathewson 
Date:   Mon Sep 27 08:49:44 2021 -0400

Document some issues around arti config.
---
 lib/chutney/TorNet.py | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/lib/chutney/TorNet.py b/lib/chutney/TorNet.py
index 873681d..ce3873a 100644
--- a/lib/chutney/TorNet.py
+++ b/lib/chutney/TorNet.py
@@ -791,9 +791,17 @@ class LocalNodeBuilder(NodeBuilder):
 self._env['fingerprint_ed25519'] = ""
 
 def _getAltAuthLines(self, hasbridgeauth=False):
-"""Return a combination of AlternateDirAuthority,
-and AlternateBridgeAuthority lines for
-this Node, appropriately.  Non-authorities return ""."""
+"""Return a set of lines to configure other nodes to use this Node as
+an authority.  For C tor, this is a combination of
+AternateDirAuthority and AlternateBridgeAuthority.  For Arti,
+this is a pair of lines to use this node as an authority and
+as a fallback.  (Arti does not automatically use authorities
+as fallbacks.)
+
+The answers are returned as: (tor-auth, (arti-auth, arti-fallback))
+
+If this node not an authority, the returned strings are empty.
+"""
 if not self._env['authority']:
 return ("",("", ""))
 
@@ -2357,6 +2365,9 @@ cache_dir = "{path}/arti/cache"
 state_dir = "{path}/arti/state"
 
 [path_rules]
+# These values disable enforce_distance entirely; we can replace them
+# with something like Tor's "EnforceDistinceSubnets 0" if Arti ever
+# implements it.
 enforce_distance = {{ "subnets_family_v4" = 33, "subnets_family_v6" = 129 }}
 
 """.format(path=self.dir))

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [chutney/main] update support for arti

2021-09-27 Thread nickm
commit 043c3b1ec545715cfb9a1bfef9aaf21daa4fe33f
Author: Trinity Pointard 
Date:   Sun Sep 26 15:24:32 2021 +0200

update support for arti
---
 lib/chutney/TorNet.py | 47 +--
 1 file changed, 29 insertions(+), 18 deletions(-)

diff --git a/lib/chutney/TorNet.py b/lib/chutney/TorNet.py
index 950806e..873681d 100644
--- a/lib/chutney/TorNet.py
+++ b/lib/chutney/TorNet.py
@@ -795,7 +795,7 @@ class LocalNodeBuilder(NodeBuilder):
 and AlternateBridgeAuthority lines for
 this Node, appropriately.  Non-authorities return ""."""
 if not self._env['authority']:
-return ("","")
+return ("",("", ""))
 
 datadir = self._env['dir']
 certfile = Path(datadir, 'keys', "authority_certificate")
@@ -841,7 +841,7 @@ class LocalNodeBuilder(NodeBuilder):
 self._env['dirport'], self._env['fingerprint'])
 
 # generate arti configuartion if supported
-arti_lines = ""
+arti_lines = ("","")
 if arti:
 addrs = '"%s:%s"' % (self._env['ip'], self._env['orport'])
 if self._env['ipv6_addr'] is not None:
@@ -852,18 +852,10 @@ class LocalNodeBuilder(NodeBuilder):
  "orports": addrs,
  "nick": self._env['nick'],
  "v3id": v3id }
-arti_lines = """
-[[network.fallback_cache]]
-rsa_identity = "{fp}"
-ed_identity = "{ed_fp}"
-orports = [ {orports} ]
-
-[[network.authority]]
-name = "{nick}"
-v3ident = "{v3id}"
-
-""".format(**elts)
-
+arti_lines = (
+"""{{rsa_identity = "{fp}", ed_identity = "{ed_fp}", 
orports = [{orports}]}},\n""".format(**elts),
+"""{{name = "{nick}", v3ident = 
"{v3id}"}},\n""".format(**elts),
+)
 return (authlines, arti_lines)
 
 def _getBridgeLines(self):
@@ -2233,6 +2225,7 @@ class Network(object):
 self._requirements = []
 self._dfltEnv = defaultEnviron
 self._nextnodenum = 0
+self.dir = ""
 
 def _addNode(self, n):
 n.setNodenum(self._nextnodenum)
@@ -2301,6 +2294,7 @@ class Network(object):
 else:
 raise
 nodeslink.symlink_to(newnodesdir)
+self.dir = newnodesdir
 
 def _checkConfig(self):
 for n in self._nodes:
@@ -2332,7 +2326,8 @@ class Network(object):
 network = self
 altauthlines = []
 bridgelines = []
-artilines = []
+arti_fallback_lines = []
+arti_auth_lines = []
 all_builders = [ n.getBuilder() for n in self._nodes ]
 builders = [ b for b in all_builders
  if b._env['config_phase'] == phase ]
@@ -2343,10 +2338,11 @@ class Network(object):
 
 for b in all_builders:
 b.preConfig(network)
-tor_auth_line, arti_auth = b._getAltAuthLines(
+tor_auth_line, (arti_fallback, arti_auth) = b._getAltAuthLines(
 self._dfltEnv['hasbridgeauth'])
 altauthlines.append(tor_auth_line)
-artilines.append(arti_auth)
+arti_fallback_lines.append(arti_fallback)
+arti_auth_lines.append(arti_auth)
 bridgelines.append(b._getBridgeLines())
 
 self._dfltEnv['authorities'] = "".join(altauthlines)
@@ -2356,7 +2352,22 @@ class Network(object):
 b.config(network)
 
 with open(os.path.join(get_absolute_nodes_path(),"arti.toml"), 'w') as 
f:
-f.write("".join(artilines))
+f.write("""[storage]
+cache_dir = "{path}/arti/cache"
+state_dir = "{path}/arti/state"
+
+[path_rules]
+enforce_distance = {{ "subnets_family_v4" = 33, "subnets_family_v6" = 129 }}
+
+""".format(path=self.dir))
+f.write("""[network]
+fallback_caches = [
+""")
+f.write("".join(arti_fallback_lines))
+f.write("]\n")
+f.write("authorities = [\n")
+f.write("".join(arti_auth_lines))
+f.write("]")
 
 for b in builders:
 b.postConfig(network)



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Edit changelog with a few grammar and simplicity fixes.

2021-09-17 Thread nickm
commit 46094d1ec03230eb4fa6be3823efb9d28374cba2
Author: Nick Mathewson 
Date:   Fri Sep 17 10:50:23 2021 -0400

Edit changelog with a few grammar and simplicity fixes.
---
 ChangeLog | 28 
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 8e424096b9..c3abd9b0e4 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,13 +1,13 @@
 Changes in version 0.4.7.1-alpha - 2021-09-17
   This version is the first alpha release of the 0.4.7.x series. One major
-  feature is the Vanguard Lite, from proposal 333, that help mitigate guard
-  discovery attacks for onion services. It also includes numerous bugfixes.
+  feature is Vanguards Lite, from proposal 333, to help mitigate guard
+  discovery attacks against onion services. It also includes numerous bugfixes.
 
   o Major features (Proposal 332, onion services, guard selection algorithm):
 - Clients and onion services now choose four long-lived "layer 2"
   guard relays for use as the middle hop in all onion circuits.
   These relays are kept in place for a randomized duration averaging
-  1 week each. This mitigates guard discovery attacks against
+  1 week. This mitigates guard discovery attacks against
   clients and short-lived onion services such as OnionShare. Long-
   lived onion services that need high security should still use the
   Vanguards addon (https://github.com/mikeperry-tor/vanguards).
@@ -24,10 +24,8 @@ Changes in version 0.4.7.1-alpha - 2021-09-17
   were using a set of flags from 2017. Closes ticket 40407.
 
   o Minor features (testing configuration):
-- When TestingTorNetwork is enabled, skip the permission check on
-  the hidden service directory. Closes ticket 40338.
-
-  o Minor features (testing):
+- When TestingTorNetwork is enabled, skip the permissions check on
+  hidden service directories. Closes ticket 40338.
 - On a testing network, relays can now use the
   TestingMinTimeToReportBandwidth option to change the smallest
   amount of time over which they're willing to report their observed
@@ -41,7 +39,7 @@ Changes in version 0.4.7.1-alpha - 2021-09-17
   immediately from startup. Previously, they waited until they had
   been running for a full day. Closes ticket 40337.
 
-  o Minor bugfix (onion service):
+  o Minor bugfixes (onion service):
 - Do not flag an HSDir as non-running in case the descriptor upload
   or fetch fails. An onion service closes pending directory
   connections before uploading a new descriptor which leads to
@@ -62,16 +60,10 @@ Changes in version 0.4.7.1-alpha - 2021-09-17
 
   o Minor bugfixes (control, sandbox):
 - Allows the control command SAVECONF to succeed when the seccomp
-  sandbox is enabled. Makes SAVECONF keep only one backup file to
+  sandbox is enabled. Makes SAVECONF keep only one backup file, to
   simplify implementation. Fixes bug 40317; bugfix on 0.2.5.4-alpha.
   Patch by Daniel Pinto.
 
-  o Minor bugfixes (documentation):
-- Add a mention of the "fingerprint-ed25519" for relays in the tor.1
-  man page. Also clarify the difference between the RSA-based
-  "fingerprint" and "fingerprint-ed25519" files. Fixes bug 40467;
-  bugfix on 0.4.3.1-alpha. Patch by Neel Chauhan.
-
   o Minor bugfixes (heartbeat):
 - Adjust the heartbeat log message about distinct clients to
   consider the HeartbeatPeriod rather than a flat 6-hour delay.
@@ -83,7 +75,8 @@ Changes in version 0.4.7.1-alpha - 2021-09-17
   Fixes bug 40453; bugfix on 0.4.5.1-alpha. Patch by Neel Chauhan.
 
   o Minor bugfixes (statistics):
-- Fix the fencepost issue when we check stability_last_downrated
+- Fix a fencepost issue when we check stability_last_downrated
+  that had caused us to call
   where we call rep_hist_downrate_old_runs() twice. Fixes bug 40394;
   bugfix on 0.2.0.5-alpha. Patch by Neel Chauhan.
 
@@ -95,6 +88,9 @@ Changes in version 0.4.7.1-alpha - 2021-09-17
 - Add links to original tor design paper and anonbib to
   docs/HACKING/README.1st.md. Closes ticket 33742. Patch from
   Emily Bones.
+- Describe the "fingerprint-ed25519" file the tor.1
+  man page. Fixes bug 40467;
+  bugfix on 0.4.3.1-alpha. Patch by Neel Chauhan.
 
 
 Changes in version 0.4.6.7 - 2021-08-16



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Run format_changelog.

2021-09-17 Thread nickm
commit 0877eee18c7a9e70eb531e2961433f920d2cb4c5
Author: Nick Mathewson 
Date:   Fri Sep 17 10:50:40 2021 -0400

Run format_changelog.
---
 ChangeLog | 44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c3abd9b0e4..09c9fe1bd4 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,17 +1,18 @@
 Changes in version 0.4.7.1-alpha - 2021-09-17
-  This version is the first alpha release of the 0.4.7.x series. One major
-  feature is Vanguards Lite, from proposal 333, to help mitigate guard
-  discovery attacks against onion services. It also includes numerous bugfixes.
+  This version is the first alpha release of the 0.4.7.x series. One
+  major feature is Vanguards Lite, from proposal 333, to help mitigate
+  guard discovery attacks against onion services. It also includes
+  numerous bugfixes.
 
   o Major features (Proposal 332, onion services, guard selection algorithm):
 - Clients and onion services now choose four long-lived "layer 2"
   guard relays for use as the middle hop in all onion circuits.
   These relays are kept in place for a randomized duration averaging
-  1 week. This mitigates guard discovery attacks against
-  clients and short-lived onion services such as OnionShare. Long-
-  lived onion services that need high security should still use the
-  Vanguards addon (https://github.com/mikeperry-tor/vanguards).
-  Closes ticket 40363; implements proposal 333.
+  1 week. This mitigates guard discovery attacks against clients and
+  short-lived onion services such as OnionShare. Long- lived onion
+  services that need high security should still use the Vanguards
+  addon (https://github.com/mikeperry-tor/vanguards). Closes ticket
+  40363; implements proposal 333.
 
   o Minor features (bridge testing support):
 - Let external bridge reachability testing tools discard cached
@@ -39,13 +40,6 @@ Changes in version 0.4.7.1-alpha - 2021-09-17
   immediately from startup. Previously, they waited until they had
   been running for a full day. Closes ticket 40337.
 
-  o Minor bugfixes (onion service):
-- Do not flag an HSDir as non-running in case the descriptor upload
-  or fetch fails. An onion service closes pending directory
-  connections before uploading a new descriptor which leads to
-  wrongly flagging many relays and thus affecting circuit path
-  selection. Fixes bug 40434; bugfix on 0.2.0.13-alpha.
-
   o Minor bugfixes (circuit padding):
 - Don't send STOP circuit padding cells when the other side has
   already shut down the corresponding padding machine. Fixes bug
@@ -74,11 +68,18 @@ Changes in version 0.4.7.1-alpha - 2021-09-17
   managed to confirm reachability for its" on dual-stack relays
   Fixes bug 40453; bugfix on 0.4.5.1-alpha. Patch by Neel Chauhan.
 
+  o Minor bugfixes (onion service):
+- Do not flag an HSDir as non-running in case the descriptor upload
+  or fetch fails. An onion service closes pending directory
+  connections before uploading a new descriptor which leads to
+  wrongly flagging many relays and thus affecting circuit path
+  selection. Fixes bug 40434; bugfix on 0.2.0.13-alpha.
+
   o Minor bugfixes (statistics):
-- Fix a fencepost issue when we check stability_last_downrated
-  that had caused us to call
-  where we call rep_hist_downrate_old_runs() twice. Fixes bug 40394;
-  bugfix on 0.2.0.5-alpha. Patch by Neel Chauhan.
+- Fix a fencepost issue when we check stability_last_downrated that
+  had caused us to call where we call rep_hist_downrate_old_runs()
+  twice. Fixes bug 40394; bugfix on 0.2.0.5-alpha. Patch by
+  Neel Chauhan.
 
   o Minor bugfixes (tests):
 - Fix a bug that prevented some tests from running with the correct
@@ -88,9 +89,8 @@ Changes in version 0.4.7.1-alpha - 2021-09-17
 - Add links to original tor design paper and anonbib to
   docs/HACKING/README.1st.md. Closes ticket 33742. Patch from
   Emily Bones.
-- Describe the "fingerprint-ed25519" file the tor.1
-  man page. Fixes bug 40467;
-  bugfix on 0.4.3.1-alpha. Patch by Neel Chauhan.
+- Describe the "fingerprint-ed25519" file the tor.1 man page. Fixes
+  bug 40467; bugfix on 0.4.3.1-alpha. Patch by Neel Chauhan.
 
 
 Changes in version 0.4.6.7 - 2021-08-16

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Merge remote-tracking branches 'tor-gitlab/mr/439' and 'tor-gitlab/mr/441'

2021-09-16 Thread nickm
commit 2c10cc3080f61df2aadfc1bb1eebcfd1d0e34350
Merge: 17ceeb7f92 515ccc4a42
Author: Nick Mathewson 
Date:   Thu Sep 16 08:53:28 2021 -0400

Merge remote-tracking branches 'tor-gitlab/mr/439' and 'tor-gitlab/mr/441'

 doc/man/tor.1.txt | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] tor.1 man page: Add mention of fingerprint-ed25519, and clarify differences

2021-09-16 Thread nickm
commit 17ceeb7f9224713f51929d94c3424761114271a1
Author: Neel Chauhan 
Date:   Tue Sep 14 11:10:11 2021 -0700

tor.1 man page: Add mention of fingerprint-ed25519, and clarify differences
---
 changes/bug40467  | 5 +
 doc/man/tor.1.txt | 7 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/changes/bug40467 b/changes/bug40467
new file mode 100644
index 00..03f1cc3816
--- /dev/null
+++ b/changes/bug40467
@@ -0,0 +1,5 @@
+  o Minor bugfixes (documentation):
+- Add a mention of the `fingerprint-ed25519` for relays in the tor.1 man
+  page. Also clarify the difference between the RSA-based `fingerprint` and
+  `fingerprint-ed25519` files. Fixes bug 40467; bugfix on 0.4.3.1-alpha.
+  Patch by Neel Chauhan.
diff --git a/doc/man/tor.1.txt b/doc/man/tor.1.txt
index 2b5a1d9df7..e5a0e0ea85 100644
--- a/doc/man/tor.1.txt
+++ b/doc/man/tor.1.txt
@@ -3826,7 +3826,12 @@ __KeyDirectory__/**`secret_onion_key_ntor`** and 
**`secret_onion_key_ntor.old`**
 by clients that didn't have the new one.
 
 __DataDirectory__/**`fingerprint`**::
-Only used by servers. Contains the fingerprint of the server's identity 
key.
+Only used by servers. Contains the fingerprint of the server's RSA
+identity key.
+
+__DataDirectory__/**`fingerprint-ed25519`**::
+Only used by servers. Contains the fingerprint of the server's ed25519
+identity key.
 
 __DataDirectory__/**`hashed-fingerprint`**::
 Only used by bridges. Contains the hashed fingerprint of the bridge's



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Update Tor's man 1 page

2021-09-16 Thread nickm
commit 515ccc4a42234d0cf8c1531a7e0acbfb5b39c790
Author: skaluzka 
Date:   Wed Sep 15 19:16:07 2021 +0200

Update Tor's man 1 page

Add few missing periods, convert tabs to spaces.
No new significant content added.

Signed-off-by: skaluzka 
---
 doc/man/tor.1.txt | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/doc/man/tor.1.txt b/doc/man/tor.1.txt
index 2b5a1d9df7..6744c85183 100644
--- a/doc/man/tor.1.txt
+++ b/doc/man/tor.1.txt
@@ -71,7 +71,7 @@ The following options in this section are only recognized on 
the
 Specify a new configuration file to contain further Tor configuration
 options, or pass *-* to make Tor read its configuration from standard
 input. (Default: **`@CONFDIR@/torrc`**, or **`$HOME/.torrc`** if
-that file is not found)
+that file is not found.)
 
 [[opt-allow-missing-torrc]] **`--allow-missing-torrc`**::
 Allow the configuration file specified by **`-f`** to be missing,
@@ -101,7 +101,7 @@ The following options in this section are only recognized 
on the
 [[opt-dump-config]] **`--dump-config`** **`short`**|**`full`**::
 Write a list of Tor's configured options to standard output.
 When the `short` flag is selected, only write the options that
-are different from their default values
+are different from their default values.
 When `full` is selected, write every option.
 
 [[opt-serviceinstall]] **`--service install`** [**`--options`** __command-line 
options__]::
@@ -988,20 +988,20 @@ forward slash (/) in the configuration file and on the 
command line.
 running. (Default: none)
 
 [[TCPProxy]] **TCPProxy** __protocol__ __host__:__port__::
-   Tor will use the given protocol to make all its OR (SSL) connections 
through
-   a TCP proxy on host:port, rather than connecting directly to servers. 
You may
-   want to set **FascistFirewall** to restrict the set of ports you might 
try to
-   connect to, if your proxy only allows connecting to certain ports. 
There is no
-   equivalent option for directory connections, because all Tor client 
versions
-   that support this option download directory documents via OR 
connections. +
+Tor will use the given protocol to make all its OR (SSL) connections 
through
+a TCP proxy on host:port, rather than connecting directly to servers. You 
may
+want to set **FascistFirewall** to restrict the set of ports you might try 
to
+connect to, if your proxy only allows connecting to certain ports. There 
is no
+equivalent option for directory connections, because all Tor client 
versions
+that support this option download directory documents via OR connections. +
 +
-   The only protocol supported right now 'haproxy'. This option is only for
-   clients. (Default: none) +
+The only protocol supported right now 'haproxy'. This option is only for
+clients. (Default: none) +
 +
-   The HAProxy version 1 proxy protocol is described in detail at
-   https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt +
+The HAProxy version 1 proxy protocol is described in detail at
+https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt +
 +
-   Both source IP address and source port will be set to zero.
+Both source IP address and source port will be set to zero.
 
 [[TruncateLogFile]] **TruncateLogFile** **0**|**1**::
 If 1, Tor will overwrite logs at startup and in response to a HUP signal,



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Merge remote-tracking branch 'tor-gitlab/mr/44'

2021-09-13 Thread nickm
commit 498023bd188be99435391a2b192519f9ce3a572c
Merge: 363ea98 04eb311
Author: Nick Mathewson 
Date:   Mon Sep 13 09:42:47 2021 -0400

Merge remote-tracking branch 'tor-gitlab/mr/44'

 control-spec.txt | 1 +
 1 file changed, 1 insertion(+)

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Add error 451 for ONION_CLIENT_AUTH_ADD

2021-09-13 Thread nickm
commit 04eb311e87c61dba797459eb81329f1ed8817cf5
Author: Neel Chauhan 
Date:   Sun Sep 12 11:17:08 2021 -0700

Add error 451 for ONION_CLIENT_AUTH_ADD
---
 control-spec.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/control-spec.txt b/control-spec.txt
index 616387c..25977b9 100644
--- a/control-spec.txt
+++ b/control-spec.txt
@@ -1935,6 +1935,7 @@
 
 251 - Client auth credentials for this onion service already existed and 
replaced.
 252 - Added client auth credentials and successfully decrypted a cached 
descriptor.
+451 - We reached authorized client capacity
 512 - Syntax error in "HSAddress", or "PrivateKeyBlob" or "Nickname"
 551 - Client with with this "Nickname" already exists
 552 - Unrecognized KeyType



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Merge remote-tracking branch 'tor-gitlab/mr/45'

2021-09-13 Thread nickm
commit 363ea9878b265d28086c8e392e9fea2ef11af219
Merge: b03be04 8b1babf
Author: Nick Mathewson 
Date:   Mon Sep 13 09:35:49 2021 -0400

Merge remote-tracking branch 'tor-gitlab/mr/45'

 proposals/326-tor-relay-well-known-uri-rfc8615.md | 21 +
 1 file changed, 21 insertions(+)

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] add ed25519-master-pubkey.txt description

2021-09-13 Thread nickm
commit 8b1babf17c4b61084bfce18daee72d83ea6dfba3
Author: nusenu <360-nus...@gitlab.torproject.org>
Date:   Sun Sep 12 20:27:26 2021 +

add ed25519-master-pubkey.txt description
---
 proposals/326-tor-relay-well-known-uri-rfc8615.md | 21 +
 1 file changed, 21 insertions(+)

diff --git a/proposals/326-tor-relay-well-known-uri-rfc8615.md 
b/proposals/326-tor-relay-well-known-uri-rfc8615.md
index 568d387..b1ed60a 100644
--- a/proposals/326-tor-relay-well-known-uri-rfc8615.md
+++ b/proposals/326-tor-relay-well-known-uri-rfc8615.md
@@ -53,6 +53,27 @@ B234567890123456789012345678901234567890
 ```
 The RSA SHA1 relay fingerprint can be found in the file named "fingerprint" 
located in the Tor data directory on the relay.
 
+## /.well-known/tor-relay/ed25519-master-pubkey.txt
+
+* The file contains one or more ed25519 Tor relay public master keys of relays 
operated by the entity in control of this website.
+* Each line contains one public ed25519 master key in its base64 encoded form.
+* The file may contain comments (starting with #).
+* Non-comment lines must be exactly 43 characters long and consist of the 
following characters [a-zA-z0-9/+].
+* Each key MUST appear at most once.
+* The file MUST not be larger than one MByte.
+* The content MUST be a media type of "text/plain".
+
+Example file content:
+
+```
+# we operate these Tor relays
+yp0fwtp4aa/VMyZJGz8vN7Km3zYet1YBZwqZEk1CwHI
+kXdA5dmIhXblAquMx0M0ApWJJ4JGQGLsjUSn86cbIaU
+bHzOT41w56KHh+w6TYwUhN4KrGwPWQWJX04/+tw/+RU
+```
+
+The base64 encoded ed25519 public master key can be found in the file named 
"fingerprint-ed25519" located in the Tor data directory on the relay.
+
 
 # Change Controller
 



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Align and fix indentations in several maint scripts

2021-09-08 Thread nickm
commit 82168e5e8bbd2600f99d37f85202c8126a959b24
Author: skaluzka 
Date:   Tue Sep 7 23:44:44 2021 +0200

Align and fix indentations in several maint scripts

Use 4 spaces indentations, convert tabs to spaces.
No real code changes.
---
 scripts/maint/checkOptionDocs.pl.in |  2 +-
 scripts/maint/checkSpace.pl | 14 +++---
 scripts/maint/check_config_macros.pl|  4 ++--
 scripts/maint/findMergedChanges.pl  | 16 
 scripts/maint/gen_ccls_file.sh  | 10 +-
 scripts/maint/run_calltool.sh   |  8 
 scripts/maint/updateRustDependencies.sh |  2 +-
 7 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/scripts/maint/checkOptionDocs.pl.in 
b/scripts/maint/checkOptionDocs.pl.in
index bb8008c2e8..2d4a7884f5 100644
--- a/scripts/maint/checkOptionDocs.pl.in
+++ b/scripts/maint/checkOptionDocs.pl.in
@@ -43,7 +43,7 @@ open(F, "@abs_top_srcdir@/doc/man/tor.1.txt") or die;
 while () {
 if (m!^(?:\[\[([A-za-z0-9_]+)\]\] *)?\*\*([A-Za-z0-9_]+)\*\*!) {
 $manPageOptions{$2} = 1;
-   print "Missing an anchor: $2\n" unless (defined $1 or $2 eq 'tor');
+print "Missing an anchor: $2\n" unless (defined $1 or $2 eq 'tor');
 }
 }
 close F;
diff --git a/scripts/maint/checkSpace.pl b/scripts/maint/checkSpace.pl
index 857ce6f6f1..8ecbf414cf 100755
--- a/scripts/maint/checkSpace.pl
+++ b/scripts/maint/checkSpace.pl
@@ -7,13 +7,13 @@ my $found = 0;
 my $COLON_POS = 10;
 
 sub msg {
-  $found = 1;
-  my $v = shift;
-  $v =~ /^\s*([^:]+):(.*)$/;
-  chomp(my $errtype = $1);
-  my $rest = $2;
-  my $padding = ' ' x ($COLON_POS - length $errtype);
-  print "$padding$errtype:$rest\n";
+$found = 1;
+my $v = shift;
+$v =~ /^\s*([^:]+):(.*)$/;
+chomp(my $errtype = $1);
+my $rest = $2;
+my $padding = ' ' x ($COLON_POS - length $errtype);
+print "$padding$errtype:$rest\n";
 }
 
 my $C = 0;
diff --git a/scripts/maint/check_config_macros.pl 
b/scripts/maint/check_config_macros.pl
index bcde2beccc..1398b9984a 100755
--- a/scripts/maint/check_config_macros.pl
+++ b/scripts/maint/check_config_macros.pl
@@ -7,7 +7,7 @@ my @macros = ();
 open(F, 'orconfig.h.in');
 while() {
 if (/^#undef +([A-Za-z0-9_]*)/) {
-   push @macros, $1;
+push @macros, $1;
 }
 }
 close F;
@@ -15,6 +15,6 @@ close F;
 for my $m (@macros) {
 my $s = `git grep '$m' src`;
 if ($s eq '') {
-   print "Unused: $m\n";
+print "Unused: $m\n";
 }
 }
diff --git a/scripts/maint/findMergedChanges.pl 
b/scripts/maint/findMergedChanges.pl
index 9b3496403d..427f2b111d 100755
--- a/scripts/maint/findMergedChanges.pl
+++ b/scripts/maint/findMergedChanges.pl
@@ -9,7 +9,7 @@ sub nChanges {
 # requires perl 5.8.  Avoids shell issues if we ever get a changes
 # file named by the parents of Little Johnny Tables.
 open F, "-|", "git", "log", "--no-merges", "--pretty=format:%H", 
$branches, "--", $fname
-   or die "$!";
+or die "$!";
 my @changes = ;
 return scalar @changes
 }
@@ -42,13 +42,13 @@ my $head = "origin/main";
 while (@ARGV and $ARGV[0] =~ /^--/) {
 my $flag = shift @ARGV;
 if ($flag =~ /^--(weird|merged|unmerged|list)/) {
-   $look_for_type = $1;
+$look_for_type = $1;
 } elsif ($flag =~ /^--branch=(\S+)/) {
 $target_branch = $1;
 } elsif ($flag =~ /^--head=(\S+)/) {
 $head = $1;
 } else {
-   die "Unrecognized flag $flag";
+die "Unrecognized flag $flag";
 }
 }
 
@@ -58,16 +58,16 @@ for my $changefile (@ARGV) {
 my $type;
 
 if ($n_merged != 0 and $n_postmerged == 0) {
-   $type = "merged";
+$type = "merged";
 } elsif ($n_merged == 0 and $n_postmerged != 0) {
-   $type = "unmerged";
+$type = "unmerged";
 } else {
-   $type = "weird";
+$type = "weird";
 }
 
 if ($type eq $look_for_type) {
-   print "$changefile\n";
+print "$changefile\n";
 } elsif ($look_for_type eq 'list') {
-   printf "% 8s: %s\n", $type, $changefile;
+printf "% 8s: %s\n", $type, $changefile;
 }
 }
diff --git a/scripts/maint/gen_ccls_file.sh b/scripts/maint/gen_ccls_file.sh
index b1fa55c973..04e31d22a8 100755
--- a/scripts/maint/gen_ccls_file.sh
+++ b/scripts/maint/gen_ccls_file.sh
@@ -19,13 +19,13 @@ echo "clang" > "$CCLS_FILE"
 # Add these include so the ccls server can properly check new files that are
 # not in the compile_commands.json yet
 {
-  echo "-I."
-  echo "-I./src"
-  echo "-I./src/ext"
-  echo "-I./src/ext/trunnel"
+echo "-I."
+echo "-I./src"
+echo "-I./src/ext"
+echo "-I./src/ext/trunnel"
 } >> "$CCLS_FILE"
 
 # Add all defines (-D).
 for p in $PRIVATE_DEFS; do
-  echo "-D$p" >> "$CCLS_FILE"
+echo "-D$p" >> "$CCLS_FILE"
 done
diff --git a/scripts/maint/run_calltool.sh b/scripts/maint/run_calltool.sh
index b0268322f4..025a49cd03 100755
--- a/scripts/maint/run_calltool.sh
+++ b/scripts/maint/run_calltool.sh
@@ 

[tor-commits] [torspec/main] Merge branch '61_pathspec'

2021-09-07 Thread nickm
commit ba6bf07fbf5aa2506fa17c24060f1342acbb9a6b
Merge: c17c36c 62ad3ea
Author: Nick Mathewson 
Date:   Tue Sep 7 16:36:34 2021 -0400

Merge branch '61_pathspec'

 path-spec.txt | 64 +++
 1 file changed, 56 insertions(+), 8 deletions(-)

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] cbtinitialtimeout also affects the default abandon timeout.

2021-09-07 Thread nickm
commit 710e230e278cf089b3bb81dd5b6c22aaa2702be4
Author: Nick Mathewson 
Date:   Fri Aug 27 11:14:14 2021 -0400

cbtinitialtimeout also affects the default abandon timeout.
---
 path-spec.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/path-spec.txt b/path-spec.txt
index 34e3bec..46f788d 100644
--- a/path-spec.txt
+++ b/path-spec.txt
@@ -643,8 +643,9 @@ of their choices.
 Default: 6
 Min: Value of cbtmintimeout
 Max: 2147483647 (INT32_MAX)
-Effect: This is the timeout value to use before computing a timeout,
-in milliseconds.
+Effect: This is the timeout value to use before we have enough data
+to compute a timeout, in milliseconds.  The circuit close
+time defaults to 1.5 times this value.
 
   cbtlearntimeout
 Default: 180



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] path-spec corrections from Mike.

2021-09-07 Thread nickm
commit 62ad3ea125aafd39a7de2907344b79126860d4cc
Author: Nick Mathewson 
Date:   Tue Sep 7 16:36:16 2021 -0400

path-spec corrections from Mike.
---
 path-spec.txt | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/path-spec.txt b/path-spec.txt
index 46f788d..eb7d6e6 100644
--- a/path-spec.txt
+++ b/path-spec.txt
@@ -414,8 +414,10 @@ of their choices.
times in a circular array.
 
These build times only include the times required to build three-hop
-   circuits. Other circuits' build times are not included.
-
+   circuits, and the times required to build the first three hops of circuits
+   with more than three hops.  Circuits of fewer than three hops are not
+   recorded, and hops past the third are not recorded.
+   
The Tor client should build test circuits at a rate of one every 
'cbttestfreq'
(10 seconds) until 'cbtmincircs' (100 circuits) are built, with a maximum of
'cbtmaxopencircs' (default: 10) circuits open at once. This allows a fresh
@@ -557,11 +559,8 @@ of their choices.
the client doubles the timeout.
 
The records here (of how many circuits succeeded or failed among the most
-   recent 'cbrrecentcount') are also stored as persistent state.  On reload,
-   the history here is reconstructed from the counts by placing successes and
-   failures in an arbitrary order.  (The C Tor implementation shuffles them,
-   whereas Arti always places failures before successes so that they expire
-   sooner.)
+   recent 'cbrrecentcount') are not stored as persistent state.  On reload,
+   we start with a new, empty state.
 
 2.4.6. Consensus parameters governing behavior
 
@@ -644,8 +643,10 @@ of their choices.
 Min: Value of cbtmintimeout
 Max: 2147483647 (INT32_MAX)
 Effect: This is the timeout value to use before we have enough data
-to compute a timeout, in milliseconds.  The circuit close
-time defaults to 1.5 times this value.
+to compute a timeout, in milliseconds.  If we do not have
+enough data to compute a timeout estimate (see cbtmincircs),
+then we use this interval both for the close timeout and the
+abandon timeout.
 
   cbtlearntimeout
 Default: 180



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Describe reload behavior of path-spec data.

2021-09-07 Thread nickm
commit de373736ee74a300f68e1355e0cbeed812ca5d80
Author: Nick Mathewson 
Date:   Fri Aug 27 11:04:22 2021 -0400

Describe reload behavior of path-spec data.
---
 path-spec.txt | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/path-spec.txt b/path-spec.txt
index f257e86..0243260 100644
--- a/path-spec.txt
+++ b/path-spec.txt
@@ -423,9 +423,9 @@ of their choices.
or network change (see section 2.4.5 below).
 
Timeouts are stored on disk in a histogram of 10ms bin width, the same
-   width used to calculate the Xm value above. This histogram must be shuffled
-   after being read from disk, to preserve a proper expiration of old values
-   after restart.
+   width used to calculate the Xm value above. The timeouts recorded in the
+   histogram must be shuffled after being read from disk, to preserve a
+   proper expiration of old values after restart.
 
Thus, some build time resolution is lost during restart. Implementations may
choose a different persistence mechanism than this histogram, but be aware
@@ -534,6 +534,13 @@ of their choices.
If the timeout was already at least `cbtinitialtimeout`,
the client doubles the timeout.
 
+   The records here (of how many circuits succeeded or failed among the most
+   recent 'cbrrecentcount') are also stored as persistent state.  On reload,
+   the history here is reconstructed from the counts by placing successes and
+   failures in an arbitrary order.  (The C Tor implementation shuffles them,
+   whereas Arti always places failures before successes so that they expire
+   sooner.)
+
 2.4.6. Consensus parameters governing behavior
 
Clients that implement circuit build timeout learning should obey the



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Clarify Xm tiebreaker rules.

2021-09-07 Thread nickm
commit 2b92f992ef27ceea3b253a3940a6da3127a0a8b8
Author: Nick Mathewson 
Date:   Fri Aug 27 10:48:43 2021 -0400

Clarify Xm tiebreaker rules.
---
 path-spec.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/path-spec.txt b/path-spec.txt
index 77368d8..f257e86 100644
--- a/path-spec.txt
+++ b/path-spec.txt
@@ -449,7 +449,8 @@ of their choices.
Instead of using the mode of discrete build times directly, Tor clients
compute the Xm parameter using the weighted average of the the midpoints
of the 'cbtnummodes' (10) most frequently occurring 10ms histogram bins.
-   Ties are broken in favor of earlier bins.
+   Ties are broken in favor of earlier bins (that is, in favor of bins
+   corresponding to shorter build times).
 
(The use of 10 modes was found to minimize error from the selected
cbtquantile, with 10ms bins for quantiles 60-80, compared to many other



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] path-spec: describe the behavior of circuit_expire_building()

2021-09-07 Thread nickm
commit a282bfc4996b39658b207e9ce1da322de26185cf
Author: Nick Mathewson 
Date:   Fri Aug 27 11:11:08 2021 -0400

path-spec: describe the behavior of circuit_expire_building()

This is my attempt to extract a general concise rule here.

(I am not sure that Tor adjusts both timeout_ms and close_ms, but
Arti does indeed adjust both.)
---
 path-spec.txt | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/path-spec.txt b/path-spec.txt
index 0243260..34e3bec 100644
--- a/path-spec.txt
+++ b/path-spec.txt
@@ -481,7 +481,8 @@ of their choices.
 
   F(q) = Xm/((1.0-q)^(1.0/alpha))
 
-   Thus, clients obtain their circuit build timeout by computing:
+   Thus, clients obtain the circuit build timeout for 3-hop circuits by
+   computing:
 
  timeout_ms = F(0.8)# 'cbtquantile' == 0.8
 
@@ -500,6 +501,27 @@ of their choices.
  timeout_ms = MIN(timeout_ms, max_observed_timeout)
  close_ms = MAX(MIN(close_ms, 2*max_observed_timeout), 'cbtinitialtimeout')
 
+2.4.3. Calculating timeouts thresholds for circuits of different lengths
+
+   The timeout_ms and close_ms estimates above are good only for 3-hop
+   circuits, since only 3-hop circuits are recorded in the list of build
+   times.
+
+   To calculate the appropriate timeouts and close timeouts for circuits of
+   other lengths, the client multiples the timeout_ms and close_ms values
+   by a scaling factor determined by the number of communication hops
+   needed to build their circuits:
+
+   timeout_ms[hops=n] = timeout_ms * Actions(N) / Actions(3)
+
+   close_ms[hops=n] = close_ms * Actions(N) / Actions(3)
+
+   where Actions(N) = N * (N + 1) / 2.
+
+   To calculate timeouts for operations other than circuit building,
+   the client should add X to Actions(N) for every round-trip communication
+   required with the Xth hop.
+
 2.4.4. How to record timeouts
 
Pareto estimators begin to lose their accuracy if the tail is omitted.



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Explain when circuits are torn down, and how they become dirty.

2021-09-07 Thread nickm
commit e226989eb19cdbcfa46c6ef9ec6ed866f453a871
Author: Nick Mathewson 
Date:   Fri Aug 27 10:46:46 2021 -0400

Explain when circuits are torn down, and how they become dirty.
---
 path-spec.txt | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/path-spec.txt b/path-spec.txt
index 65d56c4..235f64b 100644
--- a/path-spec.txt
+++ b/path-spec.txt
@@ -205,6 +205,11 @@ of their choices.
might be supported by a pending or built circuit. For internal
circuits, we pick an arbitrary acceptable path, repeating as needed.
 
+   Clients consider a circuit to become "dirty" as soon as a stream is
+   attached to it, or some other request is performed over the circuit.
+   If a circuit has been "dirty" for at least MaxCircuitDirtiness seconds,
+   new circuits may not be attached to it.
+
In some cases we can reuse an already established circuit if it's
clean; see Section 2.3 (cannibalizing circuits) for details.
 
@@ -242,8 +247,16 @@ of their choices.
 
 2.1.6. When to tear down circuits
 
-   
+   Clients should tear down circuits (in general) only when those circuits
+   have no streams on them.  Additionally, clients should tear-down
+   stream-less circuits only under one of the following conditions:
+
+ - The circuit has never had a stream attached, and it was created too
+   long in the past (based on CircuitsAvailableTimeout or
+   cbtlearntimeout, depending on timeout estimate status).
 
+ - The circuit is dirty (has had a stream attached), and it has been
+   dirty for at least MaxCircuitDirtiness.
 
 2.2. Path selection and constraints
 



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Note that only three-hop circuits are used as build time observations.

2021-09-07 Thread nickm
commit 8f5b7021b65b5379ad7fecc6f0559a21af77d740
Author: Nick Mathewson 
Date:   Fri Aug 27 10:47:01 2021 -0400

Note that only three-hop circuits are used as build time observations.
---
 path-spec.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/path-spec.txt b/path-spec.txt
index 235f64b..77368d8 100644
--- a/path-spec.txt
+++ b/path-spec.txt
@@ -413,6 +413,9 @@ of their choices.
good fit over the long term, clients store 1000 most recent circuit build
times in a circular array.
 
+   These build times only include the times required to build three-hop
+   circuits. Other circuits' build times are not included.
+
The Tor client should build test circuits at a rate of one every 
'cbttestfreq'
(10 seconds) until 'cbtmincircs' (100 circuits) are built, with a maximum of
'cbtmaxopencircs' (default: 10) circuits open at once. This allows a fresh



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Merge remote-tracking branch 'tor-gitlab/mr/426'

2021-09-07 Thread nickm
commit 677b0c9f6d9d7793a6a2c961036017076fe2abf4
Merge: fe6898157c e5b234e358
Author: Nick Mathewson 
Date:   Tue Sep 7 07:51:07 2021 -0400

Merge remote-tracking branch 'tor-gitlab/mr/426'

 scripts/maint/practracker/includes.py | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Improve fname_is_c func in pratracker/includes.py

2021-09-07 Thread nickm
commit e5b234e3582aef3476efb6bfc3d47981b3fb038f
Author: skaluzka 
Date:   Sun Aug 29 22:10:44 2021 +0200

Improve fname_is_c func in pratracker/includes.py

Use tuples for bname.startswith and fname.endswith in "fname_is_c"
function.
---
 scripts/maint/practracker/includes.py | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/scripts/maint/practracker/includes.py 
b/scripts/maint/practracker/includes.py
index a5ee728824..46630d987f 100755
--- a/scripts/maint/practracker/includes.py
+++ b/scripts/maint/practracker/includes.py
@@ -40,11 +40,13 @@ def warn(msg):
 print(msg, file=sys.stderr)
 
 def fname_is_c(fname):
-""" Return true iff 'fname' is the name of a file that we should
-search for possibly disallowed #include directives. """
-if fname.endswith(".h") or fname.endswith(".c"):
+"""
+Return true if 'fname' is the name of a file that we should
+search for possibly disallowed #include directives.
+"""
+if fname.endswith((".c", ".h")):
 bname = os.path.basename(fname)
-return not (bname.startswith(".") or bname.startswith("#"))
+return not bname.startswith((".", "#"))
 else:
 return False
 



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Merge remote-tracking branch 'tor-gitlab/main'

2021-08-29 Thread nickm
commit c17c36c57635a9ebf88b2b41dc41cbddcf56f7ef
Merge: 845a4d7 b244dd3
Author: Nick Mathewson 
Date:   Sun Aug 29 22:23:17 2021 -0400

Merge remote-tracking branch 'tor-gitlab/main'

 proposals/324-rtt-congestion-control.txt | 890 ---
 1 file changed, 580 insertions(+), 310 deletions(-)

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Merge branch 'tor-gitlab/mr/38'

2021-08-29 Thread nickm
commit b244dd33a525e3c81aa8679cda128226dcd9d6fa
Merge: df6af4f 481bcc7
Author: David Goulet 
Date:   Fri Jul 30 13:27:25 2021 -0400

Merge branch 'tor-gitlab/mr/38'

 proposals/324-rtt-congestion-control.txt | 890 ---
 1 file changed, 580 insertions(+), 310 deletions(-)



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Prop 324: Fix fencepost error in SENDME BDP calculation

2021-08-29 Thread nickm
commit 481bcc74de14ef62ade8ad3cd229cde6992a49c6
Author: Mike Perry 
Date:   Fri Jul 30 13:45:02 2021 +

Prop 324: Fix fencepost error in SENDME BDP calculation
---
 proposals/324-rtt-congestion-control.txt | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/proposals/324-rtt-congestion-control.txt 
b/proposals/324-rtt-congestion-control.txt
index 25118a4..f98c28a 100644
--- a/proposals/324-rtt-congestion-control.txt
+++ b/proposals/324-rtt-congestion-control.txt
@@ -332,13 +332,19 @@ timestamps.
 
 With this, the calculation becomes:
 
-   BWE = num_sendmes * cc_sendme_inc / num_sendme_timestamp_delta
+   BWE = (num_sendmes-1) * cc_sendme_inc / num_sendme_timestamp_delta
BDP = BWE * RTT_min
 
-However, because the timestamps are microseconds, to avoid integer
+Note that because we are counting the number of cells *between* the first
+and last sendme of the congestion window, we must subtract 1 from the number
+of sendmes actually recieved. Over the time period between the first and last
+sendme of the congestion window, the other endpoint successfully read
+(num_sendmes-1) * cc_sendme_inc cells.
+
+Furthermore, because the timestamps are microseconds, to avoid integer
 truncation, we compute the BDP using multiplication first:
 
-   BDP = num_sendmes * cc_sendme_inc * RTT_min / num_sendme_timestamp_delta
+   BDP = (num_sendmes-1) * cc_sendme_inc * RTT_min / num_sendme_timestamp_delta
 
 Note that the SENDME BDP estimation will only work after two (2) SENDME acks
 have been received. Additionally, it tends not to be stable unless at least



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Update Prop 324 since prototype.

2021-08-29 Thread nickm
commit 9e704923e71dde08263bd3b79c2bb167b79f037d
Author: Mike Perry 
Date:   Thu Jul 1 23:10:57 2021 +

Update Prop 324 since prototype.

 - Correct algorithms to update once per cwnd
 - Clarify orconn blocking and edge connection checks
 - Mention Westwood RTT backoff, and a couple other fixes
 - Specify BDP estimators based on testing and bugfixing.
 - Specify BDP-based congestion algorithm (TOR_NOLA)
 - Update consensus parameters with tuning notes.
---
 proposals/324-rtt-congestion-control.txt | 729 ---
 1 file changed, 463 insertions(+), 266 deletions(-)

diff --git a/proposals/324-rtt-congestion-control.txt 
b/proposals/324-rtt-congestion-control.txt
index 807471b..14f4370 100644
--- a/proposals/324-rtt-congestion-control.txt
+++ b/proposals/324-rtt-congestion-control.txt
@@ -120,8 +120,10 @@ and the arrival of the SENDME command that the other 
endpoint
 immediately sends to ack that 100th cell.
 
 Circuits will record the current RTT measurement as a field in their
-circuit_t data structure. They will also record the minimum and maximum
-RTT seen so far.
+circuit_t data structure. The current RTT is N-EWMA smoothed[27] over a
+'cc_ewma_cwnd_cnt' multiple of congestion window worth.
+
+Circuits will also record the minimum and maximum RTT seen so far.
 
 Algorithms that make use of this RTT measurement for congestion
 window update are specified in [CONTROL_ALGORITHMS].
@@ -137,7 +139,7 @@ algorithm mechanisms.  We will need a similar announcement 
in the onion
 service descriptors of services that support congestion control.
 
 Second, we will turn CIRCWINDOW_INCREMENT into a consensus parameter
-'circwindow_inc', instead of using a hardcoded value of 100 cells. It is
+cc_sendme_inc, instead of using a hardcoded value of 100 cells. It is
 likely that more frequent SENDME cells will provide quicker reaction to
 congestion, since the RTT will be measured more often. If
 experimentation in Shadow shows that more frequent SENDMEs reduce
@@ -145,26 +147,15 @@ congestion and improve performance but add significant 
overhead, we can
 reduce SENDME overhead by allowing SENDME cells to carry stream data, as
 well, using Proposal 325.
 
-  TODO: If two endpoints view different consensus parameters for
-'circwindow_inc', we will have complications measuring RTT,
-as well as complications for authenticated SENDME hash
-accounting. We need a way for endpoints to negotiate SENDME
-pacing with eachother, perhaps during circuit setup. This will
-require changes to the Onionskin/CREATE cell format (and
-RELAY_COMMAND_EXTEND), as mentioned in Section [PROTOCOL_SPEC].
-This could be accomplished via hs-ntor's handshake, which
-allows extra data fields in the circuit handshake.
-
-  TODO: circwindow_inc's rate of change could be capped for safety
-
-  TODO: As an optimization, 'circwindow_inc' could change as a function
-of slow start vs AIMD.
+  TODO: Refer to or include final version of the negotiation proposal for
+  this: https://gitlab.torproject.org/tpo/core/tor/-/issues/40377
 
 Second, all end-to-end relay cells except RELAY_COMMAND_DROP and SENDME
 itself will count towards SENDME cell counts. The details behind how these
 cells are handled is addressed in section [SYSTEM_INTERACTIONS].
 
-   TODO: List any other exceptions. There probably are some more.
+   XXX: Hrmm, this is not strictly necessary for this proposal to function.
+   It may make conflux easier though, but we can defer it to then.
 
 Third, authenticated SENDMEs can remain as-is in terms of protocol
 behavior, but will require some implementation updates to account for
@@ -184,14 +175,23 @@ streams and backpressure is covered in [FLOW_CONTROL].
 
 3. Congestion Window Update Algorithms [CONTROL_ALGORITHMS]
 
-We specify two candidate window update algorithms. The specification
-describes the update algorithms for the slow start phase and the
-steady state phase separately, with some explanation. Then the
-combined algorithm is given.
+In general, the goal of congestion control is to ensure full and fair
+utilization of the capacity of a network path -- in the case of Tor the spare
+capacity of the circuit. This is accomplished by setting the congestion window
+to target the Bandwidth-Delay Product[28] (BDP) of the circuit in one way or
+another, so that the total data outstanding is roughly equal to the actual
+transit capacity of the circuit.
+
+There are several ways to update a congestion window to target the BDP. Some
+use direct BDP estimation, where as others use backoff properties to achieve
+this. We specify three BDP estimation algorithms in the [BDP_ESTIMATION]
+sub-section, and three congestion window update algorithms in [TOR_WESTWOOD],
+[TOR_VEGAS], and [TOR_NOLA].
 
-Note that these algorithms differ slightly from the background tor-dev
-mails[1,2], due to corrections and improvements. Hence they 

[tor-commits] [torspec/main] Prop 324: Rename cc_icw to cc_cwnd_init

2021-08-29 Thread nickm
commit 532bec055175b626a0b200aeeb24e57bbeb4e78e
Author: Mike Perry 
Date:   Thu Jul 29 17:02:32 2021 +

Prop 324: Rename cc_icw to cc_cwnd_init
---
 proposals/324-rtt-congestion-control.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/proposals/324-rtt-congestion-control.txt 
b/proposals/324-rtt-congestion-control.txt
index b7d827e..25118a4 100644
--- a/proposals/324-rtt-congestion-control.txt
+++ b/proposals/324-rtt-congestion-control.txt
@@ -228,8 +228,8 @@ network traffic. This experimentation and tuning is 
detailed in section
 
 All of these algorithms have rules to update 'cwnd' - the current congestion
 window, which starts out at a value controlled by consensus parameter
-'cc_icw'. The algorithms also keep track of 'inflight', which is a count of
-the number of cells currently not yet acked by a SENDME. The algorithm MUST
+'cc_cwnd_init'. The algorithms also keep track of 'inflight', which is a count
+of the number of cells currently not yet acked by a SENDME. The algorithm MUST
 ensure that cells cease being sent if 'cwnd - inflight <= 0'. Note that this
 value CAN become negative in the case where the cwnd is reduced while packets
 are inflight.
@@ -922,7 +922,7 @@ These are sorted in order of importance to tune, most 
important first.
The lower this value is, the sooner we can get an estimate of
the true BDP of a circuit. Low values may lead to massive
over-estimation, due to ack compression. However, if this
-   value is above the number of acks that fit in cc_icw, then
+   value is above the number of acks that fit in cc_cwnd_init, then
we won't get a BDP estimate within the first use of the circuit.
Additionally, if this value is above the number of acks that
fit in cc_cwnd_min, we may not be able to estimate BDP
@@ -942,7 +942,7 @@ These are sorted in order of importance to tune, most 
important first.
100, we can set this as low as 33 to have the same amount of
overhead.
 
-  cc_icw:
+  cc_cwnd_init:
 - Description: Initial congestion window for new congestion
control Tor clients. This can be set much higher
than TCP, since actual TCP to the guard will prevent



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Prop 324: Describe clock jump and stall heuristics.

2021-08-29 Thread nickm
commit baa504ea8f54fd7d3da1ece073843e672bf00a00
Author: Mike Perry 
Date:   Wed Jul 28 01:17:11 2021 +

Prop 324: Describe clock jump and stall heuristics.
---
 proposals/324-rtt-congestion-control.txt | 42 +++-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/proposals/324-rtt-congestion-control.txt 
b/proposals/324-rtt-congestion-control.txt
index 362..b7d827e 100644
--- a/proposals/324-rtt-congestion-control.txt
+++ b/proposals/324-rtt-congestion-control.txt
@@ -128,6 +128,29 @@ Circuits will also record the minimum and maximum RTT seen 
so far.
 Algorithms that make use of this RTT measurement for congestion
 window update are specified in [CONTROL_ALGORITHMS].
 
+2.1.1. Clock Jump Heuristics [CLOCK_HEURISTICS]
+
+The timestamps for RTT (and BDP) are measured using Tor's
+monotime_absolute_usec() API. This API is designed to provide a monotonic
+clock that only moves forward. However, depending on the underlying system
+clock, this may result in the same timestamp value being returned for long
+periods of time, which would result in RTT 0-values. Alternatively, the clock
+may jump forward, resulting in abnormally large RTT values.
+
+To guard against this, we perform a series of heuristic checks on the time 
delta
+measured by the RTT estimator, and if these heurtics detect a stall or a jump,
+we do not use that value to update RTT or BDP, nor do we update any congestion
+control algorithm information that round.
+
+If the time delta is 0, that is always treated as a clock stall.
+
+If we have measured at least 'cc_bwe_min' RTT values or we have successfully
+exited slow start, then every sendme ACK, the new candidate RTT is compared to
+the stored EWMA RTT. If the new RTT is either 100 times larger than the EWMA
+RTT, or 100 times smaller than the stored EWMA RTT, then we do not record that
+estimate, and do not update BDP or the congestion control algorithms for that
+SENDME ack.
+
 2.2. SENDME behavior changes
 
 We will make four major changes to SENDME behavior to aid in computing
@@ -320,7 +343,8 @@ truncation, we compute the BDP using multiplication first:
 Note that the SENDME BDP estimation will only work after two (2) SENDME acks
 have been received. Additionally, it tends not to be stable unless at least
 five (5) num_sendme's are used, due to ack compression. This is controlled by
-the 'cc_bwe_min' consensus parameter.
+the 'cc_bwe_min' consensus parameter. Finally, if [CLOCK_HEURISTICS] have
+detected a clock jump or stall, this estimator is not updated.
 
 If all edge connections no longer have data available to send on a circuit
 and all circuit queues have drained without blocking the local orconn, we stop
@@ -430,6 +454,11 @@ each time we get a SENDME (aka 
sendme_process_circuit_level()):
  if next_cc_event:
next_cc_event--
 
+ # Do not update anything if we detected a clock stall or jump,
+ # as per [CLOCK_HEURISTICS]
+ if clock_stalled_or_jumped:
+   return
+
  if next_cc_event == 0:
# BOOTLEG_RTT_TOR threshold; can also be BACKWARD_ECN check:
if (RTT_current <
@@ -497,6 +526,11 @@ ack:
   if next_cc_event:
 next_cc_event--
 
+  # Do not update anything if we detected a clock stall or jump,
+  # as per [CLOCK_HEURISTICS]
+  if clock_stalled_or_jumped:
+return
+
   if next_cc_event == 0:
  if BDP > cwnd:
queue_use = 0
@@ -535,6 +569,12 @@ and scores of others. What's up with that?
 
 Here's the pseudocode for TOR_NOLA that runs on every SENDME ack:
 
+  # Do not update anything if we detected a clock stall or jump,
+  # as per [CLOCK_HEURISTICS]
+  if clock_stalled_or_jumped:
+return
+
+  # If the orconn is blocked, do not overshoot BDP
   if orconn_blocked:
 cwnd = BDP
   else:



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Further Prop 324 Updates:

2021-08-29 Thread nickm
commit 89b9702cc75f2489993790f5bb8939d58d6b0a5a
Author: Mike Perry 
Date:   Tue Jul 27 23:38:59 2021 +

Further Prop 324 Updates:

  - Clarify what we learned in experimentation
  - Clarify N-EWMA and next_cc_event behavior
  - Clarify order of operations in BDP estimator
  - Clarify and expand on parameter tuning
  - Clarify Vegas and Nola descriptions
  - Mention that we need to test intermittent clients
  - Update old trac URLs
---
 proposals/324-rtt-congestion-control.txt | 247 +--
 1 file changed, 137 insertions(+), 110 deletions(-)

diff --git a/proposals/324-rtt-congestion-control.txt 
b/proposals/324-rtt-congestion-control.txt
index 14f4370..362 100644
--- a/proposals/324-rtt-congestion-control.txt
+++ b/proposals/324-rtt-congestion-control.txt
@@ -121,7 +121,7 @@ immediately sends to ack that 100th cell.
 
 Circuits will record the current RTT measurement as a field in their
 circuit_t data structure. The current RTT is N-EWMA smoothed[27] over a
-'cc_ewma_cwnd_cnt' multiple of congestion window worth.
+'cc_ewma_cwnd_cnt' multiple of congestion window worth of sendme acks.
 
 Circuits will also record the minimum and maximum RTT seen so far.
 
@@ -155,7 +155,9 @@ itself will count towards SENDME cell counts. The details 
behind how these
 cells are handled is addressed in section [SYSTEM_INTERACTIONS].
 
XXX: Hrmm, this is not strictly necessary for this proposal to function.
-   It may make conflux easier though, but we can defer it to then.
+   It may make conflux easier though, but we can defer it to then. The
+   current implementation only counts RELAY_COMMAND_DATA towards sendme
+   acks, which is the same behavior as the old fixed sendme implementation.
 
 Third, authenticated SENDMEs can remain as-is in terms of protocol
 behavior, but will require some implementation updates to account for
@@ -191,7 +193,8 @@ sub-section, and three congestion window update algorithms 
in [TOR_WESTWOOD],
 Note that the congestion window update algorithms differ slightly from the
 background tor-dev mails[1,2], due to corrections and improvements. Hence they
 have been given different names than in those two mails. The third algorithm,
-[TOR_NOLA], simply uses BDP estimate directly as its congestion window.
+[TOR_NOLA], simply uses the latest BDP estimate directly as its congestion
+window.
 
 These algorithms will be evaluated by running Shadow simulations, to
 help determine parameter ranges, but experimentation on the live network
@@ -209,12 +212,15 @@ value CAN become negative in the case where the cwnd is 
reduced while packets
 are inflight.
 
 While these algorithms are in use, updates and checks of the current
-'package_window' field are disabled. The 'deliver_window' field is still used
-to decide when to send a SENDME. In C tor, the deliver window is initially set
-at 1000, but it never gets below 900, because authenticated sendmes (Proposal
-289) require that we must send only one SENDME at a time, and send it
-immediately after 100 cells are received. This property turns out to be very
-useful for [BDP_ESTIMATION].
+'package_window' field are disabled. Where a 'package_window' value is
+still needed, for example by cell packaging schedulers, 'cwnd - inflight' is
+used (with checks to return 0 in the event of negative values).
+
+The 'deliver_window' field is still used to decide when to send a SENDME. In C
+tor, the deliver window is initially set at 1000, but it never gets below 900,
+because authenticated sendmes (Proposal 289) require that we must send only
+one SENDME at a time, and send it immediately after 100 cells are received.
+This property turns out to be very useful for [BDP_ESTIMATION].
 
 Implementation of different algorithms should be very simple - each
 algorithm should have a different update function depending on the selected 
algorithm,
@@ -259,16 +265,26 @@ The SENDME arrival rate is the most accurate way to 
estimate BDP, but it
 requires averaging over multiple SENDME acks to do so. The congestion window
 and inflight estimates rely on the congestion algorithm more or less correctly
 tracking an approximation of the BDP, and then use current and minimum RTT to
-compensate for overshoot. These estimators tend to be accurate once the
-congestion window exceeds BDP.
+compensate for overshoot.
+
+The SENDME estimator tends to be accurate after ~3-5 SENDME acks. The cwnd and
+inflight estimators tend to be accurate once the congestion window exceeds
+BDP.
 
 We specify all three because they are all useful in various cases. These cases
 are broken up and combined to form the Piecewise BDP estimator.
 
-It is also useful to smooth these estimates through N-EWMA averaging on these
-estimators[27], to smooth out temporary effects. The N parameter can be
-modified by consensus parameter 'cc_ewma_cwnd_cnt', which specifies the number
-of congestion windows worth of SENDME acks to compute an N-EWMA average 

[tor-commits] [torspec/main] Fix typo "epheremal" -> "ephemeral"

2021-08-29 Thread nickm
commit 845a4d7213e8e28bb039d6925437b5b1c0d607e7
Author: Nick Mathewson 
Date:   Sun Aug 29 15:42:35 2021 -0400

Fix typo "epheremal" -> "ephemeral"

Close #62
---
 control-spec.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/control-spec.txt b/control-spec.txt
index 9b51715..616387c 100644
--- a/control-spec.txt
+++ b/control-spec.txt
@@ -1921,7 +1921,7 @@
   currently supported flags are:
 
 "Permanent" - This client's credentials should be stored in the filesystem.
-  If this is not set, the client's credentials are epheremal
+  If this is not set, the client's credentials are ephemeral
   and stored in memory.
 
   If client auth credentials already existed for this service, replace them

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Add spaces between the "and" when logging the "Your server has not managed to confirm reachability for its" on dual-stack relays

2021-08-27 Thread nickm
commit 8ead53330c73e9bc1b82f6b7fc8946d629063842
Author: Neel Chauhan 
Date:   Thu Aug 26 13:38:48 2021 -0700

Add spaces between the "and" when logging the "Your server has not managed 
to confirm reachability for its" on dual-stack relays
---
 changes/bug40453   | 4 
 src/feature/relay/relay_periodic.c | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/changes/bug40453 b/changes/bug40453
new file mode 100644
index 00..28ed13b47a
--- /dev/null
+++ b/changes/bug40453
@@ -0,0 +1,4 @@
+  o Minor bugfixes (logging, relay):
+- Add spaces between the "and" when logging the "Your server has
+  not managed to confirm reachability for its" on dual-stack relays
+  Fixes bug 40453; bugfix on 0.4.5.1-alpha. Patch by Neel Chauhan.
diff --git a/src/feature/relay/relay_periodic.c 
b/src/feature/relay/relay_periodic.c
index ee94590e01..dd9be4e36f 100644
--- a/src/feature/relay/relay_periodic.c
+++ b/src/feature/relay/relay_periodic.c
@@ -219,7 +219,7 @@ reachability_warnings_callback(time_t now, const 
or_options_t *options)
   tor_asprintf(, "%s:%d", address4, me->ipv4_orport);
 if (!v6_ok)
   tor_asprintf(, "[%s]:%d", address6, me->ipv6_orport);
-const char *opt_and = (!v4_ok && !v6_ok) ? "and" : "";
+const char *opt_and = (!v4_ok && !v6_ok) ? " and " : "";
 
 /* IPv4 reachability test worked but not the IPv6. We will _not_
  * publish the descriptor if our IPv6 was configured. We will if it

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [torspec/main] Prop332: add test vectors.

2021-08-26 Thread nickm
commit 7a06c12fea6e65dd0bcb411000d968844335c22f
Author: Nick Mathewson 
Date:   Thu Aug 26 12:15:41 2021 -0400

Prop332: add test vectors.
---
 proposals/332-ntor-v3-with-extra-data.md | 34 
 1 file changed, 34 insertions(+)

diff --git a/proposals/332-ntor-v3-with-extra-data.md 
b/proposals/332-ntor-v3-with-extra-data.md
index a6e9c9b..207bc07 100644
--- a/proposals/332-ntor-v3-with-extra-data.md
+++ b/proposals/332-ntor-v3-with-extra-data.md
@@ -391,6 +391,40 @@ The relay rejects the message if the value given is 
outside of the
 [`circwindow_inc_min`, `circwindow_inc_max`] range.  Otherwise, it
 accepts it, and replies with the same message that the client sent.
 
+# X.2: Test vectors
 
+The following test values, in hex, were generated by a Python reference
+implementation.
 
+Inputs:
 
+b = "4051daa5921cfa2a1c27b08451324919538e79e788a81b38cbed097a5dff454a"
+B = "f8307a2bc1870b00b828bb74dbb8fd88e632a6375ab3bcd1ae706aaa8b6cdd1d"
+ID = "9fad2af287ef942632833d21f946c6260c33fae6172b60006e86e4a6911753a2"
+x = "b825a3719147bcbe5fb1d0b0fcb9c09e51948048e2e3283d2ab7b45b5ef38b49"
+X = "252fe9ae91264c91d4ecb8501f79d0387e34ad8ca0f7c995184f7d11d5da4f46"
+CM = "68656c6c6f20776f726c64"
+VER = "78797a7a79"
+y = "4865a5b7689dafd978f529291c7171bc159be076b92186405d13220b80e2a053"
+Y = "4bf4814326fdab45ad5184f5518bd7fae25dc59374062698201a50a22954246d"
+SM = "486f6c61204d756e646f"
+
+Intermediate values:
+
+ENC_K1 = "4cd166e93f1c60a29f8fb9ec40ea0fc878930c27800594593e1c4d0f3b5fbd02"
+MAC_K1 = "f5b69e85fdd26e1b0bdbbc8128e32d8123040255f11f744af3cc98fc13613cda"
+msg_mac = "9e044d53565f04d82bbb3bebed3d06cea65db8be9c72b68cd461942088502f67"
+key_seed = "b9a092741098e1f5b8ab37ce74399dd57522c974d7ae4626283a1077b9273255"
+verify = "1dc09fb249738a79f1bc3a545eee8c415f27213894a760bb4df58862e414799a"
+ENC_KEY (server) = 
"cab8a93eef62246a83536c4384f331ec26061b66098c61421b6cae81f4f57c56"
+AUTH = "2fc5f8773ca824542bc6cf6f57c7c29bbf4e5476461ab130c5b18ab0a9127665"
+
+Messages:
+
+client_handshake = 
"9fad2af287ef942632833d21f946c6260c33fae6172b60006e86e4a6911753a2f8307a2bc1870b00b828bb74dbb8fd88e632a6375ab3bcd1ae706aaa8b6cdd1d252fe9ae91264c91d4ecb8501f79d0387e34ad8ca0f7c995184f7d11d5da4f463bebd9151fd3b47c180abc9e044d53565f04d82bbb3bebed3d06cea65db8be9c72b68cd461942088502f67"
+
+server_handshake = 
"4bf4814326fdab45ad5184f5518bd7fae25dc59374062698201a50a22954246d2fc5f8773ca824542bc6cf6f57c7c29bbf4e5476461ab130c5b18ab0a91276651202c3e1e87c0d32054c"
+
+First 256 bytes of keystream:
+
+KEYSTREAM = 
"9c19b631fd94ed86a817e01f6c80b0743a43f5faebd39cfaa8b00fa8bcc65c3bfeaa403d91acbd68a821bf6ee8504602b094a254392a07737d5662768c7a9fb1b2814bb34780eaee6e867c773e28c212ead563e98a1cd5d5b4576f5ee61c59bde025ff2851bb19b721421694f263818e3531e43a9e4e3e2c661e2ad547d8984caa28ebecd3e4525452299be26b9185a20a90ce1eac20a91f2832d731b54502b09749b5a2a2949292f8cfcbeffb790c7790ed935a9d251e7e336148ea83b063a5618fcff674a44581585fd22077ca0e52c59a24347a38d1a1ceebddbf238541f226b8f88d0fb9c07a1bcd2ea7645dacdaf5312a14c0b9e4f06309b0333b4a"

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Remove changes files that have already been in changelogs for 0.4.6

2021-08-26 Thread nickm
commit 29ec66fb39ec07df6809f47741dc48d9d366ef22
Author: Nick Mathewson 
Date:   Thu Aug 26 11:20:53 2021 -0400

Remove changes files that have already been in changelogs for 0.4.6
---
 changes/autoconf-2.70| 3 ---
 changes/bug40078 | 3 ---
 changes/bug40175 | 5 -
 changes/bug40375 | 5 -
 changes/bug40380 | 3 ---
 changes/bug40383 | 7 ---
 changes/bug40391 | 9 -
 changes/bug40392 | 4 
 changes/bug40399 | 5 -
 changes/bug40409 | 3 ---
 changes/geoip-2021-05-07 | 3 ---
 changes/geoip-2021-06-10 | 3 ---
 changes/geoip-2021-08-12 | 3 ---
 changes/ticket40290  | 3 ---
 changes/ticket40301  | 4 
 changes/ticket40356  | 3 ---
 changes/ticket40369  | 4 
 changes/ticket40370  | 4 
 changes/ticket40373  | 3 ---
 changes/ticket40374  | 4 
 changes/ticket40378  | 4 
 changes/ticket40382  | 6 --
 changes/ticket40389  | 3 ---
 changes/ticket40390  | 8 
 changes/ticket40410  | 4 
 changes/ticket40419  | 3 ---
 changes/ticket40421  | 3 ---
 changes/ticket40447  | 2 --
 28 files changed, 114 deletions(-)

diff --git a/changes/autoconf-2.70 b/changes/autoconf-2.70
deleted file mode 100644
index 27a9f243b1..00
--- a/changes/autoconf-2.70
+++ /dev/null
@@ -1,3 +0,0 @@
-  o Minor features (compilation):
-- Make the autoconf script build correctly with autoconf versions 2.70
-  and later. Closes part of ticket 40335.
diff --git a/changes/bug40078 b/changes/bug40078
deleted file mode 100644
index 717309e076..00
--- a/changes/bug40078
+++ /dev/null
@@ -1,3 +0,0 @@
-  o Minor bugfix (crypto):
-- Disable the unused batch verification feature of ed25519-donna. Fixes
-  bug 40078; bugfix on 0.2.6.1-alpha. Found by Henry de Valence.
\ No newline at end of file
diff --git a/changes/bug40175 b/changes/bug40175
deleted file mode 100644
index aa2ce9566f..00
--- a/changes/bug40175
+++ /dev/null
@@ -1,5 +0,0 @@
-  o Minor features (logging, diagnostic):
-- Log decompression failures at a higher severity level, since they
-  can help provide missing context for other warning messages.
-  We rate-limit these messages, to avoid flooding the logs if they
-  begin to occur frequently. Closes ticket 40175.
diff --git a/changes/bug40375 b/changes/bug40375
deleted file mode 100644
index 7ac32bc628..00
--- a/changes/bug40375
+++ /dev/null
@@ -1,5 +0,0 @@
-  o Minor bugfixes (consensus handling):
-- Avoid a set of bugs that could be caused by inconsistently preferring
-  an out-of-date consensus stored in a stale directory cache over
-  a more recent one stored on disk as the latest consensus.
-  Fixes bug 40375; bugfix on 0.3.1.1-alpha.
diff --git a/changes/bug40380 b/changes/bug40380
deleted file mode 100644
index 24d2876b7d..00
--- a/changes/bug40380
+++ /dev/null
@@ -1,3 +0,0 @@
-  o Minor bugfixes (compiler warnings):
-- Fix an indentation problem that led to a warning from  GCC 11.1.1.
-  Fixes bug 40380; bugfix on 0.3.0.1-alpha.
diff --git a/changes/bug40383 b/changes/bug40383
deleted file mode 100644
index c4ca46fac7..00
--- a/changes/bug40383
+++ /dev/null
@@ -1,7 +0,0 @@
-  o Minor bugfixes (timekeeping):
-- Calculate the time of day correctly on systems where the time_t
-  type includes leap seconds. (This is not the case on most
-  operating systems, but on those where it occurs, our tor_timegm
-  function did not correctly invert the system's gmtime function,
-  which could result in assertion failures when calculating
-  voting schedules.)  Fixes bug 40383; bugfix on 0.2.0.3-alpha.
diff --git a/changes/bug40391 b/changes/bug40391
deleted file mode 100644
index e3c186275f..00
--- a/changes/bug40391
+++ /dev/null
@@ -1,9 +0,0 @@
-  o Major bugfixes (security):
-- Resist a hashtable-based CPU denial-of-service attack against
-  relays. Previously we used a naive unkeyed hash function to look up
-  circuits in a circuitmux object. An attacker could exploit this to
-  construct circuits with chosen circuit IDs in order to try to create
-  collisions and make the hash table inefficient.  Now we use a SipHash
-  construction for this hash table instead. Fixes bug 40391; bugfix on
-  0.2.4.4-alpha. This issue is also tracked as TROVE-2021-005.
-  Reported by Jann Horn from Google's Project Zero.
diff --git a/changes/bug40392 b/changes/bug40392
deleted file mode 100644
index 4dffa50bb2..00
--- a/changes/bug40392
+++ /dev/null
@@ -1,4 +0,0 @@
-  o Major bugfixes (security, denial of service, onion services):
-  - Fix an out-of-bounds memory access in v3 descriptor parsing. Fixes bug
-40392; bugfix on 0.3.0.1-alpha. This issue is also tracked as
-TROVE-2021-006. Reported by Sergei Glazunov from Google's Project Zero.
\ No newline at end of file
diff --git 

[tor-commits] [torspec/main] Prop332: Minor edits.

2021-08-26 Thread nickm
commit b30b4b0d559deeb59db88e7c9e8dfe97bab5bdf8
Author: Nick Mathewson 
Date:   Thu Aug 26 10:40:19 2021 -0400

Prop332: Minor edits.

Document that MAC_KEY_LEN exists, and is 32.

Switch from SHAKE128 to SHAKE256: the performance difference is
negligible, and that's what we use elsewhere in Tor.
---
 proposals/332-ntor-v3-with-extra-data.md | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/proposals/332-ntor-v3-with-extra-data.md 
b/proposals/332-ntor-v3-with-extra-data.md
index 06c55f9..a6e9c9b 100644
--- a/proposals/332-ntor-v3-with-extra-data.md
+++ b/proposals/332-ntor-v3-with-extra-data.md
@@ -109,7 +109,7 @@ We require the following crypto operations:
   * `H(s,t)` -- a tweakable hash function of output length
  `DIGEST_LEN`.
   * `MAC(k, msg, t)` -- a tweakable message-authentication-code function,
- of output length `MAC_LEN`.
+ with key length `MAC_KEY_LEN` and output length `MAC_LEN`.
   * `EXP(pk,sk)` -- our Diffie Hellman group operation, taking a
  public key of length `PUB_KEY_LEN`.
   * `KEYGEN()` -- our Diffie-Hellman keypair generation algorithm,
@@ -280,18 +280,18 @@ using a new PROTOID.)
 
 # A.1 Instantiation
 
-Here are a set of functions based on SHA3, SHAKE128, Curve25519, and
+Here are a set of functions based on SHA3, SHAKE-256, Curve25519, and
 AES256:
 
 ```
 H(s, t) = SHA3_256(ENCAP(t) | s)
 MAC(k, msg, t) = SHA3_256(ENCAP(t) | ENCAP(k) | s)
-KDF(s, t) = SHAKE_128(ENCAP(t) | s)
+KDF(s, t) = SHAKE_256(ENCAP(t) | s)
 ENC(k, m) = AES_256_CTR(k, m)
 
 EXP(pk,sk), KEYGEN: defined as in curve25519
 
-DIGEST_LEN = MAC_LEN = ENC_KEY_LEN = PUB_KEY_LEN = 32
+DIGEST_LEN = MAC_LEN = MAC_KEY_LEN = ENC_KEY_LEN = PUB_KEY_LEN = 32
 
 ID_LEN = 32  (representing an ed25519 identity key)
 ```

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] dir: Do not flag non-running failing HSDir

2021-08-18 Thread nickm
commit cac612af42798bc76d8933837a9da97ddc039c9b
Author: David Goulet 
Date:   Tue Aug 17 12:43:58 2021 -0400

dir: Do not flag non-running failing HSDir

When a directory request fails, we flag the relay as non Running so we
don't use it anymore.

This can be problematic with onion services because there are cases
where a tor instance could have a lot of services, ephemeral ones, and
keeps failing to upload descriptors, let say due to a bad network, and
thus flag a lot of nodes as non Running which then in turn can not be
used for circuit building.

This commit makes it that we never flag nodes as non Running on a onion
service directory request (upload or fetch) failure as to keep the
hashring intact and not affect other parts of tor.

Fortunately, the onion service hashring is _not_ selected by looking at
the Running flag but since we do a 3-hop circuit to the HSDir, other
services on the same instance can influence each other by removing nodes
from the consensus for path selection.

This was made apparent with a small network that ran out of nodes to
used due to rapid succession of onion services uploading and failing.
See #40434 for details.

Fixes #40434

Signed-off-by: David Goulet 
---
 changes/ticket40434   |  6 ++
 src/feature/dirclient/dirclient.c | 17 -
 src/feature/dircommon/directory.h |  6 ++
 3 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/changes/ticket40434 b/changes/ticket40434
new file mode 100644
index 00..988bb416be
--- /dev/null
+++ b/changes/ticket40434
@@ -0,0 +1,6 @@
+  o Minor bugfix (onion service):
+- Do not flag an HSDir as non-running in case the descriptor upload or
+  fetch fails. An onion service closes pending directory connections
+  before uploading a new descriptor which can thus lead to wrongly
+  flagging many relays and thus affecting circuit building path selection.
+  Fixes bug 40434; bugfix on 0.2.0.13-alpha.
diff --git a/src/feature/dirclient/dirclient.c 
b/src/feature/dirclient/dirclient.c
index a5dd856729..f2e1e5b5ff 100644
--- a/src/feature/dirclient/dirclient.c
+++ b/src/feature/dirclient/dirclient.c
@@ -738,7 +738,22 @@ connection_dir_client_request_failed(dir_connection_t 
*conn)
 return; /* this was a test fetch. don't retry. */
   }
   if (!entry_list_is_constrained(get_options()))
-router_set_status(conn->identity_digest, 0); /* don't try this one again */
+/* We must not set a directory to non-running for HS purposes else we end
+ * up flagging nodes from the hashring has unusable. It doesn't have direct
+ * effect on the HS subsystem because the nodes are selected regardless of
+ * their status but still, we shouldn't flag them as non running.
+ *
+ * One example where this can go bad is if a tor instance gets added a lot
+ * of ephemeral services and with a network with problem then many nodes in
+ * the consenus ends up unusable.
+ *
+ * Furthermore, a service does close any pending directory connections
+ * before uploading a descriptor and thus we can end up here in a natural
+ * way since closing a pending directory connection leads to this code
+ * path. */
+if (!DIR_PURPOSE_IS_HS(TO_CONN(conn)->purpose)) {
+  router_set_status(conn->identity_digest, 0);
+}
   if (conn->base_.purpose == DIR_PURPOSE_FETCH_SERVERDESC ||
  conn->base_.purpose == DIR_PURPOSE_FETCH_EXTRAINFO) {
 log_info(LD_DIR, "Giving up on serverdesc/extrainfo fetch from "
diff --git a/src/feature/dircommon/directory.h 
b/src/feature/dircommon/directory.h
index 0aa2ff53ef..2cd9c176c8 100644
--- a/src/feature/dircommon/directory.h
+++ b/src/feature/dircommon/directory.h
@@ -87,6 +87,12 @@ const dir_connection_t *CONST_TO_DIR_CONN(const connection_t 
*c);
(p)==DIR_PURPOSE_UPLOAD_RENDDESC_V2 ||   \
(p)==DIR_PURPOSE_UPLOAD_HSDESC)
 
+/** True iff p is a purpose corresponding to onion service that is either
+ * uploading or fetching actions. */
+#define DIR_PURPOSE_IS_HS(p)  \
+  ((p) == DIR_PURPOSE_FETCH_HSDESC || \
+   (p) == DIR_PURPOSE_UPLOAD_HSDESC)
+
 enum compress_method_t;
 int parse_http_response(const char *headers, int *code, time_t *date,
 enum compress_method_t *compression, char **response);



___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


[tor-commits] [tor/main] Merge remote-tracking branch 'tor-gitlab/mr/420'

2021-08-18 Thread nickm
commit 984e3a9c6c4d193e095c376637321c0bfa371c08
Merge: 00b57e81f8 cac612af42
Author: Nick Mathewson 
Date:   Wed Aug 18 08:43:31 2021 -0400

Merge remote-tracking branch 'tor-gitlab/mr/420'

 changes/ticket40434   |  6 ++
 src/feature/dirclient/dirclient.c | 17 -
 src/feature/dircommon/directory.h |  6 ++
 3 files changed, 28 insertions(+), 1 deletion(-)

diff --cc src/feature/dirclient/dirclient.c
index a2b20621a0,f2e1e5b5ff..4e9c8e2f45
--- a/src/feature/dirclient/dirclient.c
+++ b/src/feature/dirclient/dirclient.c
@@@ -708,8 -734,26 +708,23 @@@ connection_dir_client_request_failed(di
   * failed. */
  entry_guard_failed(>guard_state);
}
 -  if (directory_conn_is_self_reachability_test(conn)) {
 -return; /* this was a test fetch. don't retry. */
 -  }
if (!entry_list_is_constrained(get_options()))
- router_set_status(conn->identity_digest, 0); /* don't try this one again 
*/
+ /* We must not set a directory to non-running for HS purposes else we end
+  * up flagging nodes from the hashring has unusable. It doesn't have 
direct
+  * effect on the HS subsystem because the nodes are selected regardless of
+  * their status but still, we shouldn't flag them as non running.
+  *
+  * One example where this can go bad is if a tor instance gets added a lot
+  * of ephemeral services and with a network with problem then many nodes 
in
+  * the consenus ends up unusable.
+  *
+  * Furthermore, a service does close any pending directory connections
+  * before uploading a descriptor and thus we can end up here in a natural
+  * way since closing a pending directory connection leads to this code
+  * path. */
+ if (!DIR_PURPOSE_IS_HS(TO_CONN(conn)->purpose)) {
+   router_set_status(conn->identity_digest, 0);
+ }
if (conn->base_.purpose == DIR_PURPOSE_FETCH_SERVERDESC ||
   conn->base_.purpose == DIR_PURPOSE_FETCH_EXTRAINFO) {
  log_info(LD_DIR, "Giving up on serverdesc/extrainfo fetch from "
diff --cc src/feature/dircommon/directory.h
index f233e8b244,2cd9c176c8..7d861682bb
--- a/src/feature/dircommon/directory.h
+++ b/src/feature/dircommon/directory.h
@@@ -78,8 -84,15 +78,14 @@@ const dir_connection_t *CONST_TO_DIR_CO
((p)==DIR_PURPOSE_UPLOAD_DIR ||   \
 (p)==DIR_PURPOSE_UPLOAD_VOTE ||  \
 (p)==DIR_PURPOSE_UPLOAD_SIGNATURES ||\
 -   (p)==DIR_PURPOSE_UPLOAD_RENDDESC_V2 ||   \
 (p)==DIR_PURPOSE_UPLOAD_HSDESC)
  
+ /** True iff p is a purpose corresponding to onion service that is either
+  * uploading or fetching actions. */
+ #define DIR_PURPOSE_IS_HS(p)  \
+   ((p) == DIR_PURPOSE_FETCH_HSDESC || \
+(p) == DIR_PURPOSE_UPLOAD_HSDESC)
+ 
  enum compress_method_t;
  int parse_http_response(const char *headers, int *code, time_t *date,
  enum compress_method_t *compression, char **response);

___
tor-commits mailing list
tor-commits@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits


  1   2   3   4   5   6   7   8   9   10   >