Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:45Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34382Don't require M_SYSCALL in sandbox.c2020-06-13T15:53:45ZNick MathewsonDon't require M_SYSCALL in sandbox.cIn sandbox.c, we have a platform-dependent M_SYSCALL macro that is used to extract the syscall from a ucontext_t pointer.
But we only use this value for debugging. Perhaps instead we should make it optional, so that platforms where we ...In sandbox.c, we have a platform-dependent M_SYSCALL macro that is used to extract the syscall from a ucontext_t pointer.
But we only use this value for debugging. Perhaps instead we should make it optional, so that platforms where we don't have it defined can still build with m_syscall.
See also #32904 and #30987Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32957Tor: remove support for the pre-0.3.5 directory structure2020-06-13T15:49:57ZteorTor: remove support for the pre-0.3.5 directory structureOur git scripts and some of our test scripts still support Tor's pre-0.3.5 directory structure.
Now that 0.2.9 is unsupported, we can remove this code.
We should be able to find it by grepping for "0.2.9", "029", "src/or", "src/common"...Our git scripts and some of our test scripts still support Tor's pre-0.3.5 directory structure.
Now that 0.2.9 is unsupported, we can remove this code.
We should be able to find it by grepping for "0.2.9", "029", "src/or", "src/common", "0.3.5", or "035".Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32753Tor should lower-case its BridgeDistribution string2020-06-13T15:49:08ZRoger DingledineTor should lower-case its BridgeDistribution stringSee comment:8 in #32547, where phw tells a bridge operator that they need to set BridgeDistribution to "none", because using "None" is not right.
That isn't a good user experience, and it's easy to fix.
One option is that inside check_...See comment:8 in #32547, where phw tells a bridge operator that they need to set BridgeDistribution to "none", because using "None" is not right.
That isn't a good user experience, and it's easy to fix.
One option is that inside check_bridge_distribution_setting() when we do `if (!strcmp(bd, RECOGNIZED[i]))` we should do strcasecmp instead. That is, don't complain if it's a recognized value and the only issue is that it's not all lowercase.
But a better option imo is that we lowercase it in place first, so that if the user types None, bridgedb still sees none.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32673'buf_read_from_tls()' can return the wrong error code2020-06-13T15:48:52Zopara'buf_read_from_tls()' can return the wrong error codeThe [function](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/buffers_tls.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n63) `buf_read_from_tls(...)` returns an integer. This integer can either be `<=0` (in which case it correspo...The [function](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/buffers_tls.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n63) `buf_read_from_tls(...)` returns an integer. This integer can either be `<=0` (in which case it corresponds to a `TOR_TLS_` status) or a positive number (in which case it corresponds to the number of bytes read). This return value is [used in](https://gitweb.torproject.org/tor.git/tree/src/core/mainloop/connection.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n3749) `connection_buf_read_from_socket()` in a large `switch(result)` statement.
At the beginning of `buf_read_from_tls(...)`, it returns `-1` on the lines:
```
IF_BUG_ONCE(buf->datalen >= INT_MAX)
return -1;
IF_BUG_ONCE(buf->datalen >= INT_MAX - at_most)
return -1;
```
This value of `-1` is the [same as](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/tortls.h?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n48) `TOR_TLS_WANTWRITE`. This causes the switch statement in `connection_buf_read_from_socket()` to interpret the return value as `TOR_TLS_WANTWRITE`, which is not correct for the `buf->datalen >= INT_MAX` bug. I suggest returning `TOR_TLS_ERROR_MISC` instead of `-1`. Note that this would close the connection.
I don't think you'll see incorrect behavior due to this, but it might be a good idea to fix.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32672Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version()2020-06-13T15:53:43ZteorReject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version()We should modify dirserv_rejects_tor_version() to keep it up to date with our supported versions:
* After 1 January 2020, we should reject all versions less than 0.3.5.
* After 2 February 2020, we should reject the 0.4.0 series, but allo...We should modify dirserv_rejects_tor_version() to keep it up to date with our supported versions:
* After 1 January 2020, we should reject all versions less than 0.3.5.
* After 2 February 2020, we should reject the 0.4.0 series, but allow the 0.3.5 series
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Current
After these dates, we should get arma to test this change, then merge it.
After we merge, we should create a ticket in 0.4.4 to reject 0.4.1.Tor: 0.4.2.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32661Document that we avoid changing src/ext2020-06-13T15:48:47ZteorDocument that we avoid changing src/extWe only change src/ext when necessary for integration with tor, or portability across platforms.
There was some confusion about this in #32626, so I'd like to update one or more of the following documents:
* src/mainpage.md
* src/ext/RE...We only change src/ext when necessary for integration with tor, or portability across platforms.
There was some confusion about this in #32626, so I'd like to update one or more of the following documents:
* src/mainpage.md
* src/ext/README
* doc/HACKING/CodeStructure.md
We might also want to change our merge policy, but that's a longer process.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32217Make git-push-all.sh skip branches that match upstream, in all modes2020-06-13T15:47:17ZteorMake git-push-all.sh skip branches that match upstream, in all modesThis makes my backport pushes slightly faster.
It also helps make sure I'm only merging to branches I am expecting to merge to.
Also fix some bugs.This makes my backport pushes slightly faster.
It also helps make sure I'm only merging to branches I am expecting to merge to.
Also fix some bugs.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32216Make git-push-all.sh skip branches that match upstream, in all modes2020-06-13T15:47:17ZteorMake git-push-all.sh skip branches that match upstream, in all modesThis makes my backport pushes slightly faster.
It also helps make sure I'm only merging to branches I am expecting to merge to.This makes my backport pushes slightly faster.
It also helps make sure I'm only merging to branches I am expecting to merge to.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32060CID 1454761: wrong type passed to unlock_cb_buf()?2020-06-13T15:46:34ZteorCID 1454761: wrong type passed to unlock_cb_buf()?Maybe it should be `void *cb_buf[]`
```
CID 1454761: Incorrect expression (SIZEOF_MISMATCH)
/src/lib/err/backtrace.c: 107 in unlock_cb_buf()
101 }
102
103 /** Unlock the static stack pointer buffer. */
104 static void...Maybe it should be `void *cb_buf[]`
```
CID 1454761: Incorrect expression (SIZEOF_MISMATCH)
/src/lib/err/backtrace.c: 107 in unlock_cb_buf()
101 }
102
103 /** Unlock the static stack pointer buffer. */
104 static void
105 unlock_cb_buf(void *cb_buf)
106 {
CID 1454761: Incorrect expression (SIZEOF_MISMATCH)
Passing argument "cb_buf" of type "void *" and argument "2048UL /* 256 * sizeof (void *) */" to function "memset" is suspicious.
107 memset(cb_buf, 0, SIZEOF_CB_BUF);
108 pthread_mutex_unlock(&cb_buf_mutex);
109 }
```Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31948CID 1454593: passing negative value to memset2020-06-13T15:46:19ZNick MathewsonCID 1454593: passing negative value to memsetCoverity says:
```
________________________________________________________________________________________________________
*** CID 1454593: Memory - illegal accesses (NO_EFFECT)
/src/test/test_util.c: 6200 in test_util_map_anon_nofor...Coverity says:
```
________________________________________________________________________________________________________
*** CID 1454593: Memory - illegal accesses (NO_EFFECT)
/src/test/test_util.c: 6200 in test_util_map_anon_nofork()
6194 int pipefd[2] = {-1, -1};
6195 unsigned inherit=0;
6196
6197 tor_munmap_anonymous(ptr, sz);
6198 ptr = tor_mmap_anonymous(sz, ANONMAP_NOINHERIT, &inherit);
6199 tt_ptr_op(ptr, OP_NE, 0);
>>> CID 1454593: Memory - illegal accesses (NO_EFFECT)
>>> Argument "-48" in "memset" loses precision in "memset(ptr, -48, sz)".
6200 memset(ptr, TEST_VALUE, sz);
6201
6202 tt_int_op(0, OP_EQ, pipe(pipefd));
6203 pid_t child = fork();
6204 if (child == 0) {
6205 /* We're in the child. */
```Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31939log spam: Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf...2020-06-13T15:46:17ZTaylor Yulog spam: Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT_MAX - at_most) failed.Nonfatal assert log spamming as seen in #31036.
```
Jun 26 07:01:30.000 [warn] {BUG} tor_bug_occurred_(): Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT
#_MAX - at_most) failed. (on Tor 0.4.0.5 )
```...Nonfatal assert log spamming as seen in #31036.
```
Jun 26 07:01:30.000 [warn] {BUG} tor_bug_occurred_(): Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(buf->datalen >= INT
#_MAX - at_most) failed. (on Tor 0.4.0.5 )
```
(I assume the `#` in the middle of `INT_MAX` is a paste/transcription artifact, but then again it might not be.)Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31897util/map_anon_nofork test fails on SunOS2020-06-13T15:46:09ZTracutil/map_anon_nofork test fails on SunOSI get the following error on SunOS:
uname -a
SunOS oibuild 5.11 illumos-e7a617a7b6 i86pc i386 i86pc
```
....
FAIL: src/test/test
===================
util/load_win_lib: SKIPPED
util/log_mallinfo: SKIPPED
util/map_anon_nofork:
FAIL ...I get the following error on SunOS:
uname -a
SunOS oibuild 5.11 illumos-e7a617a7b6 i86pc i386 i86pc
```
....
FAIL: src/test/test
===================
util/load_win_lib: SKIPPED
util/log_mallinfo: SKIPPED
util/map_anon_nofork:
FAIL /export/home/svschmel/oi-userland/components/network/tor/tor-0.4.1.6/src/test/test_util.c:6223: assert(buf[0] OP_EQ 0xd0): -48 vs 208
[map_anon_nofork FAILED]
1/1360 TESTS FAILED. (2 skipped)
FAIL src/test/test (exit status: 1)
....
```
**Trac**:
**Username**: svschmelTor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31854In tests and log.c, stop using ~0 a log domain mask2020-06-13T15:46:02ZNick MathewsonIn tests and log.c, stop using ~0 a log domain maskThere are a few places in the tests where we use ~0 or ~0u to indicate a log domain mask that covers all domains. We also do this in log.c.
But back in #31080, we made the log_domain_mask_t into a 64-bit value, probably one defined by ...There are a few places in the tests where we use ~0 or ~0u to indicate a log domain mask that covers all domains. We also do this in log.c.
But back in #31080, we made the log_domain_mask_t into a 64-bit value, probably one defined by a macro like LD_ALL_DOMAINS.
Additionally, we should _not_ use ~(uint64_t)0 for the definition of this value, since we don't want to include LD_NO_MOCK, LD_NOCB, and LD_NOFUNCNAME.
Found while looking at #31334; this should be done after #31334 is merged.
No backport needed, since we do not yet have any logging domains that use the high 32 bits of this type.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31839Improve logging documentation2020-06-13T15:45:57ZteorImprove logging documentationTor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31838Fix a typo in the practracker usage message2020-06-13T15:45:56ZteorFix a typo in the practracker usage messageI don't think this needs a changes file?I don't think this needs a changes file?Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31825Use the full name of optional modules, rather than an abbreviation2020-06-13T15:45:53ZteorUse the full name of optional modules, rather than an abbreviationSome Tor builders are confused by the optional module descriptions in Tor's configure script.
We should spell out abbreviations:
* dirauth = Directory AuthoritySome Tor builders are confused by the optional module descriptions in Tor's configure script.
We should spell out abbreviations:
* dirauth = Directory AuthorityTor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31657Rephrase "missing descriptors" notice log to be less confusing2020-06-13T15:45:21ZteorRephrase "missing descriptors" notice log to be less confusingSome operators are confused or alarmed by these logs:
```
Sep 05 03:22:50.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of our primary entry guards (total micro...Some operators are confused or alarmed by these logs:
```
Sep 05 03:22:50.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 6515/6541).
Sep 05 03:22:50.000 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 6515/6541).
```
We should rephrase them or document that:
* tor tries to keep active 3 primary guards for anonymity and safety
* we'll try to get new microdescs soon
* tor usually recovers quickly from this issueTor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31639When Travis updates the homebrew cache in their images, stop updating it in ....2020-06-13T13:31:11ZteorWhen Travis updates the homebrew cache in their images, stop updating it in .travis.ymlIn #30928, we added a homebrew update to .travis.yml for shellcheck.
#30279 also uses an updated tor for the IPv6 v3 single onion service job.
This ticket removes that update.In #30928, we added a homebrew update to .travis.yml for shellcheck.
#30279 also uses an updated tor for the IPv6 v3 single onion service job.
This ticket removes that update.https://gitlab.torproject.org/legacy/trac/-/issues/31612Update the function comment in format_number_sigsafe()2020-06-13T15:45:03ZteorUpdate the function comment in format_number_sigsafe()The function comment refers to a calling function that doesn't exist any more. Now, multiple functions call format_number_sigsafe().The function comment refers to a calling function that doesn't exist any more. Now, multiple functions call format_number_sigsafe().Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31554Restrict "make test-stem" to tests that actually use tor2020-06-13T15:44:51ZteorRestrict "make test-stem" to tests that actually use torIn #30694, we restricted the travis stem job to tests that actually use tor.
But we should lower that change to "make test-stem".
Gaba, this is sponsor 27 can, because it makes refactoring easier to test.In #30694, we restricted the travis stem job to tests that actually use tor.
But we should lower that change to "make test-stem".
Gaba, this is sponsor 27 can, because it makes refactoring easier to test.Tor: 0.3.5.x-finalteorteor