The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-09-16T14:19:59Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30414Move relay periodic events out of mainloop.c2021-09-16T14:19:59ZNick MathewsonMove relay periodic events out of mainloop.cTor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30411Consider rewriting git hooks in Python2020-07-29T03:51:05Zrl1987Consider rewriting git hooks in PythonIn legacy/trac#30286 we're looking into fixing pre-push hook to inspect only the commits that originate from the branch being pushed and that seems to be pretty complicated to do with shell scripting alone. As our git hook complexity gro...In legacy/trac#30286 we're looking into fixing pre-push hook to inspect only the commits that originate from the branch being pushed and that seems to be pretty complicated to do with shell scripting alone. As our git hook complexity grows, it may become worthwhile to write them in Python and use some Python module (e.g. GitPython) to have deeper integration with git repository.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30409Some of our tests require internet connectivity / an IPv4 stack2021-09-16T14:19:58ZGeorge KadianakisSome of our tests require internet connectivity / an IPv4 stackWe got word from an onion service operator that they had to disable some of our tests because they wouldn't work in their ipv6-only setup.
In particular they mentioned the following tests (or functions): get_if_addrs_list_internal, get_...We got word from an onion service operator that they had to disable some of our tests because they wouldn't work in their ipv6-only setup.
In particular they mentioned the following tests (or functions): get_if_addrs_list_internal, get_if_addrs_list_no_internal, get_if_addrs, status_vote_current_consensus_ns
We should probably investigate this.https://gitlab.torproject.org/tpo/core/tor/-/issues/30387open 20 onion bookmarks in tabs. tails, tor browser, onion circuits2020-06-27T13:50:15ZTracopen 20 onion bookmarks in tabs. tails, tor browser, onion circuitsAn onion site under DDOS published 20 onion links. After trying them manually for a while, I put them all into a bookmark folder and selected open all in bookmarks, hoping to find one that would connect. This did work on occasion. Watchi...An onion site under DDOS published 20 onion links. After trying them manually for a while, I put them all into a bookmark folder and selected open all in bookmarks, hoping to find one that would connect. This did work on occasion. Watching onion circuits showed unexpected behavior. A large number of circuits were being opened. Some showed four links. clicking on 4 link circuit almost always caused it to disappear. The guard node switched to a new one on new circuits after a while. After this, all onion sites became unreachable, with many circuits opening and failing when trying a single not overloaded site. Restarting tails was required to reach regular onion sites.
I didn't intend to DOS the network myself, but it looks like that was the result. Perhaps this should be rate limited at the source.
Also, if I hadn't had onion circuits window open, I wouldn't have realized that something was wrong in my tor client. Some of the reported unavailable sites could be due to the user's tor client in a similar state.
**Trac**:
**Username**: anon52569https://gitlab.torproject.org/tpo/core/tor/-/issues/30382prop304: Implement SOCKS new HS error code2021-06-23T17:24:34ZGeorge Kadianakisprop304: Implement SOCKS new HS error codeFor TB to be able to alert the user that they need to input their client auth credentials we need an appropriate control port event.
In particular:
1) When Tor fails to decrypt the second layer of desc encryption, we issue the `CLIENT_...For TB to be able to alert the user that they need to input their client auth credentials we need an appropriate control port event.
In particular:
1) When Tor fails to decrypt the second layer of desc encryption, we issue the `CLIENT_AUTH_NEEDED <onion> <reason>` event. Tor does not go to fetch more descs from the hsdir for this onion.
2) At the same time, we store the broken descriptor into the hs cache, with a special flag that says "missing client auth" and hence `desc` is `NULL`.
3) When TB intercepts the event it presents the user with a dialogue (legacy/trac#30237) and adds any client auth creds with the commands from legacy/trac#30381.
4) As part of the legacy/trac#30381 commands the descriptor is decrypted.
5) TB issues another SOCKS request which uses the right descriptor and goes forward.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/30381Provide control port commands to ADD/REMOVE/VIEW v3 client-auth2021-06-23T17:24:34ZGeorge KadianakisProvide control port commands to ADD/REMOVE/VIEW v3 client-authWe need control port commands so that TB can add/remove/view client auth credentials.
Furthermore, the 'add' command should be able to decrypt any existing non-decryptable descriptors in the cache (see legacy/trac#30382).We need control port commands so that TB can add/remove/view client auth credentials.
Furthermore, the 'add' command should be able to decrypt any existing non-decryptable descriptors in the cache (see legacy/trac#30382).Tor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/30378HSv2 regression: Not possible to add HidServAuth line using SETCONF without r...2021-07-09T17:22:00ZGeorge KadianakisHSv2 regression: Not possible to add HidServAuth line using SETCONF without restartIt's not possible to add a HidServAuth line using SETCONF and the control port with rebooting. This is most probably a regression.
Also see comment:49:ticket:14389.It's not possible to add a HidServAuth line using SETCONF and the control port with rebooting. This is most probably a regression.
Also see comment:49:ticket:14389.https://gitlab.torproject.org/tpo/core/tor/-/issues/30373Most headers non-compliant with spec2020-06-27T13:50:16ZirlMost headers non-compliant with spec`Keyword` is imported from dir-spec and
```
KeyValue ::= Keyword "=" Value
Keyword = KeywordChar+
KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
```
but... most headers have underscores in them.
My parser wasn't strict ...`Keyword` is imported from dir-spec and
```
KeyValue ::= Keyword "=" Value
Keyword = KeywordChar+
KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
```
but... most headers have underscores in them.
My parser wasn't strict enough to catch this the first time. ):
I suggest this is fixed with a specification update to reflect reality rather than creating complexity we have to maintain forever parsing two sets of keys.Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30365prop289: Update tor-spec.txt with authenticated SENDME spec2020-06-27T13:50:16ZDavid Gouletdgoulet@torproject.orgprop289: Update tor-spec.txt with authenticated SENDME specBasically either merge proposal 289 into tor-spec.txt or create sendme-spec.txt which should then be referenced within tor-spec.txt.Basically either merge proposal 289 into tor-spec.txt or create sendme-spec.txt which should then be referenced within tor-spec.txt.Tor: 0.4.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/30364prop289: Add consensus param to use or not SENDME v1 for one-hop directory do...2020-06-27T13:50:16ZDavid Gouletdgoulet@torproject.orgprop289: Add consensus param to use or not SENDME v1 for one-hop directory downloadSee proposal 289 section 4.5 which is about adding a consensus param that controls the minimum version to use when doing one-hop directory connections.See proposal 289 section 4.5 which is about adding a consensus param that controls the minimum version to use when doing one-hop directory connections.Tor: 0.4.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/30363prop289: Implement FlowCtrl protover value2020-06-27T13:50:16ZDavid Gouletdgoulet@torproject.orgprop289: Implement FlowCtrl protover valueSee prop289 section 4.3.See prop289 section 4.3.Tor: 0.4.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/30361CID 1444908: MISSING_LOCK / CID 1444769: TAINTED_SCALAR2020-06-27T13:50:16ZGeorge KadianakisCID 1444908: MISSING_LOCK / CID 1444769: TAINTED_SCALARGot two new coverity issues:
```
*** CID 1444908: Concurrent data access violations (MISSING_LOCK)
/src/test/rng_test_helpers.c: 190 in testing_enable_prefilled_rng()
184 {
185 tor_assert(buflen > 0);
186 rng_mutex = t...Got two new coverity issues:
```
*** CID 1444908: Concurrent data access violations (MISSING_LOCK)
/src/test/rng_test_helpers.c: 190 in testing_enable_prefilled_rng()
184 {
185 tor_assert(buflen > 0);
186 rng_mutex = tor_mutex_new();
187
188 prefilled_rng_buffer = tor_memdup(buffer, buflen);
189 prefilled_rng_buflen = buflen;
>>> CID 1444908: Concurrent data access violations (MISSING_LOCK)
>>> Accessing "prefilled_rng_idx" without holding lock "tor_mutex_t.mutex". Elsewhere, "prefilled_rng_idx" is accessed with
>>> "tor_mutex_t.mutex" held 3 out of 4 times (1 of these accesses strongly imply that it is necessary).
190 prefilled_rng_idx = 0;
191
192 MOCK(crypto_rand, crypto_rand_prefilled);
193 MOCK(crypto_strongest_rand_, mock_crypto_strongest_rand);
194 }
195
** CID 1444769: Insecure data handling (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 1444769: Insecure data handling (TAINTED_SCALAR)
/src/feature/nodelist/microdesc.c: 540 in microdesc_cache_reload()
534 }
535
536 journal_content = read_file_to_str(cache->journal_fname,
537 RFTS_IGNORE_MISSING, &st);
538 if (journal_content) {
539 cache->journal_len = (size_t) st.st_size;
>>> CID 1444769: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted variable "journal_content" to a tainted sink.
540 warn_if_nul_found(journal_content, cache->journal_len, 0,
541 "reading microdesc journal");
542 added = microdescs_add_to_cache(cache, journal_content,
543 journal_content+st.st_size,
544 SAVED_IN_JOURNAL, 0, -1, NULL);
545 if (added) {
```}Tor: 0.4.1.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/30352Tor fails to recover if it was started with incorrect date settings2022-06-17T16:14:07ZTracTor fails to recover if it was started with incorrect date settingsAfter power failure, I accidently set date to 05.02.2019 instead of 02.05.2019.
It is ok that Tor can't work with such misconfiguration.
But problem is that it was not able to work even after correct date was restored.
Last lines in log ...After power failure, I accidently set date to 05.02.2019 instead of 02.05.2019.
It is ok that Tor can't work with such misconfiguration.
But problem is that it was not able to work even after correct date was restored.
Last lines in log are:
```
May 02 01:57:41.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
May 02 02:01:09.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
May 02 02:01:09.000 [notice] Our circuit 0 (id: 63) died due to an invalid selected path, purpose General-purpose client. This may be a torrc configuration issue, or a bug.
May 02 02:05:47.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
May 02 02:10:27.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
May 02 02:15:08.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
May 02 02:20:16.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
```
Related ticket: legacy/trac#8766.
**Trac**:
**Username**: Vorthttps://gitlab.torproject.org/tpo/core/tor/-/issues/30349Document member-hiding conventions for structs2022-06-17T14:06:50ZTaylor YuDocument member-hiding conventions for structsWe should document whatever conventions we choose for hiding struct members, probably in doc/HACKING. Also we should make tools for searching for violations, e.g., code that directly accesses private members without using the appropriate...We should document whatever conventions we choose for hiding struct members, probably in doc/HACKING. Also we should make tools for searching for violations, e.g., code that directly accesses private members without using the appropriate macros. (A fairly simple Coccinelle script should work for this.)https://gitlab.torproject.org/tpo/core/tor/-/issues/30348Update padding negotiation with preference menu, response delays2022-06-24T16:07:30ZMike PerryUpdate padding negotiation with preference menu, response delaysAs we add more padding machines across different Tor versions, padding negotiation will become more and more likely to fail. We could send a preference list to the relay instead, so that if any of the machines we could use are supported,...As we add more padding machines across different Tor versions, padding negotiation will become more and more likely to fail. We could send a preference list to the relay instead, so that if any of the machines we could use are supported, they would be chosen in preference order.
We could also add a delay field asking the relay to delay before responding, as an alternate way to deal with concerns in legacy/trac#30172.https://gitlab.torproject.org/tpo/core/tor/-/issues/30345Move remaining dirauth files into dirauth module2020-06-27T13:50:17ZNick MathewsonMove remaining dirauth files into dirauth moduleWe have a few files in feature/dirauth that are still built when the dirauth module is disabled. Let's fix that.We have a few files in feature/dirauth that are still built when the dirauth module is disabled. Let's fix that.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30344conn_read_callback is called on connections that are marked for closed2020-07-14T22:24:00ZRob Jansenconn_read_callback is called on connections that are marked for closedThere is a bug causing busy loops in Libevent and infinite loops in the Shadow simulator. In my Shadow simulations, I have observed that `conn_read_callback` is getting called on a connection that is marked for close.
This is similar to...There is a bug causing busy loops in Libevent and infinite loops in the Shadow simulator. In my Shadow simulations, I have observed that `conn_read_callback` is getting called on a connection that is marked for close.
This is similar to legacy/trac#5263, and as described there, I believe it is a bug for `conn_read_callback` to be called on sockets that are marked for close.
The bug is problematic in Shadow when the marked connection also wants to flush, but attempting to write the outbuf inside `conn_close_if_marked` fails because the write would block (because the kernel write buffer is already full). Because it still wants to flush, the connection does not get closed, but the connection remains readable causing Libevent to continue looping on `conn_read_callback` until the socket buffer can actually write. This wastes CPU resources in Tor, and causes an infinite loop in Shadow because Shadow's discrete-event time does not advance during this loop.
I found the bug on 0.3.5.8, and it is probably present at least since then.
I think the conn should not be waiting for read events when it is marked. I'm not sure where in the code this assumption is first violated, but the following patch fixed the issue in my Shadow simulations:
```
diff --git a/src/core/mainloop/mainloop.c b/src/core/mainloop/mainloop.c
index 6e2b300..e82c77a 100644
--- a/src/core/mainloop/mainloop.c
+++ b/src/core/mainloop/mainloop.c
@@ -894,6 +894,21 @@ conn_read_callback(evutil_socket_t fd, short event, void *_conn)
}
assert_connection_ok(conn, time(NULL));
+ if (conn->marked_for_close && connection_is_reading(conn)) {
+ /* Libevent says we can read, but we are marked so we will never try
+ * to read again. We will try to close the connection below inside of
+ * close_closeable_connections(), but let's make sure not to cause
+ * Libevent to spin on conn_read_callback() while we wait for the
+ * socket to let us flush to it.*/
+ connection_stop_reading(conn);
+
+ /* Now, if we still have data to flush, then make sure Libevent tells
+ * us when the conn will allow us to write the bytes. */
+ if (connection_wants_to_flush(conn) && !connection_is_writing(conn)) {
+ connection_start_writing(conn);
+ }
+ }
+
if (smartlist_len(closeable_connection_lst))
close_closeable_connections();
}
```Tor: 0.3.5.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/303429 dephects on prob_distr.c (April 2019)2020-06-27T13:50:17ZGeorge Kadianakis9 dephects on prob_distr.c (April 2019)Similar to legacy/trac#29805, coverity is again furious at prob distr:
We got a bunch of these:
```
_____________________________________________________________________________________________
*** CID 1444030: Incorrect expression ...Similar to legacy/trac#29805, coverity is again furious at prob distr:
We got a bunch of these:
```
_____________________________________________________________________________________________
*** CID 1444030: Incorrect expression (SIZEOF_MISMATCH)
/src/test/test_prob_distr.c: 1254 in test_stochastic_weibull_impl()
1248 }
1249
1250 static bool
1251 test_stochastic_weibull_impl(double lambda, double k)
1252 {
1253 const struct weibull dist = {
>>> CID 1444030: Incorrect expression (SIZEOF_MISMATCH)
>>> Adding "0UL /* 0 * sizeof (&dist - (struct weibull const *)&dist) */" to pointer "&weibull_ops" of type "struct dist_ops const *" is
>>> suspicious because adding an integral value to this pointer automatically scales that value by the size, 48 bytes, of the pointed-to type,
>>> "struct dist_ops const". Most likely, the multiplication by "sizeof (0L)" in this expression is extraneous and should be eliminated.
1254 .base = WEIBULL(dist),
1255 .lambda = lambda,
1256 .k = k,
1257 };
1258
1259 /*
```
and a bunch of these:
```
________________________________________________________________________________________________
*** CID 1415723: Incorrect expression (DIVIDE_BY_ZERO)
/src/feature/client/circpathbias.c: 194 in pathbias_get_scale_ratio()
188 (void) options;
189 /**
190 * The mult factor is the numerator for our scaling
191 * of circuit counts for our path bias window. It
192 * allows us to scale by fractions.
193 */
>>> CID 1415723: Incorrect expression (DIVIDE_BY_ZERO)
>>> In expression "networkstatus_get_param(NULL, "pb_multfactor", 1, 1, denominator) / (double)denominator", division by expression
>>> "denominator" which may be zero has undefined behavior.
194 return networkstatus_get_param(NULL, "pb_multfactor",
195 1, 1, denominator)/((double)denominator);
196 }
197
198 /** The minimum number of circuit usage attempts before we start
199 * thinking about warning about path use bias and dropping guards */
```Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30328Fix Coverity CID 14447692020-06-27T13:50:17ZAlexander Færøyahf@torproject.orgFix Coverity CID 1444769We should fix CID 1444769.We should fix CID 1444769.Tor: unspecifiedAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/30316Vote's 'bandwidth-file-headers' is in wrong order2020-06-27T13:50:17ZDamian JohnsonVote's 'bandwidth-file-headers' is in wrong orderHi network team. Moria1's present vote places its "bandwidth-file-headers" in the wrong location.
Tor's dir-spec says: "**Status documents contain a preamble, an authority section, a list of router status entries, and one or more footer...Hi network team. Moria1's present vote places its "bandwidth-file-headers" in the wrong location.
Tor's dir-spec says: "**Status documents contain a preamble, an authority section, a list of router status entries, and one or more footer signature, in that order.**"
The trouble is that our bandwidth-file-headers field is specified as being part of the preamble, whereas moria1 places it **after** its authority section. Header fields appear in the following order...
* flag-thresholds (preamble)
* params (preamble)
* dir-source (authority section)
* contact (authority section)
* shared-rand-participate (authority section)
* shared-rand-commit (authority section, multiple)
* shared-rand-previous-value (authority section)
* shared-rand-current-value (authority section)
* **bandwidth-file-headers (preamble)**
* dir-key-certificate-version (key certificate)
* ... etc...
As a result Stem does not parse this field: legacy/trac#30282Tor: 0.3.5.x-finalNick MathewsonNick Mathewson