Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:26:45Zhttps://gitlab.torproject.org/legacy/trac/-/issues/26388Update tor copyright headers to year 20182020-06-13T15:26:45Zrl1987Update tor copyright headers to year 2018Now it says:
```
* Copyright (c) 2007-2017, The Tor Project, Inc. */
```
Should be updated to 2018. We have updateCopyright.pl for this.Now it says:
```
* Copyright (c) 2007-2017, The Tor Project, Inc. */
```
Should be updated to 2018. We have updateCopyright.pl for this.Tor: 0.3.4.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/26351Update to June GeoIP2 database2020-06-13T15:26:34ZKarsten LoesingUpdate to June GeoIP2 database[My geoip-2018-06-07 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-06-07) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other branch...[My geoip-2018-06-07 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-06-07) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other branches that are still maintained.
(Note to self when I use this ticket as template for next month: 0.3.1 is end of life on 1 July 2018.)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26272gcc 7 fails on -Wunused-const-variable for Zstd headers2020-06-13T15:26:13Zteorgcc 7 fails on -Wunused-const-variable for Zstd headersWhen using gcc 7 on macOS:
```
$ gcc-7 --version
gcc-7 (Homebrew GCC 7.3.0) 7.3.0
```
I see the following errors:
```
In file included from ../src/common/compress_zstd.c:29:0:
/usr/local/Cellar/zstd/1.3.4//include/zstd.h:593:29: error: ...When using gcc 7 on macOS:
```
$ gcc-7 --version
gcc-7 (Homebrew GCC 7.3.0) 7.3.0
```
I see the following errors:
```
In file included from ../src/common/compress_zstd.c:29:0:
/usr/local/Cellar/zstd/1.3.4//include/zstd.h:593:29: error: 'ZSTD_defaultCMem' defined but not used [-Werror=unused-const-variable=]
static ZSTD_customMem const ZSTD_defaultCMem = { NULL, NULL, NULL }; /**< this constant defers to stdlib's functions */
^~~~~~~~~~~~~~~~
/usr/local/Cellar/zstd/1.3.4//include/zstd.h:404:21: error: 'ZSTD_skippableHeaderSize' defined but not used [-Werror=unused-const-variable=]
static const size_t ZSTD_skippableHeaderSize = 8; /* magic number + skippable frame length */
^~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/Cellar/zstd/1.3.4//include/zstd.h:403:21: error: 'ZSTD_frameHeaderSize_max' defined but not used [-Werror=unused-const-variable=]
static const size_t ZSTD_frameHeaderSize_max = ZSTD_FRAMEHEADERSIZE_MAX;
^~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/Cellar/zstd/1.3.4//include/zstd.h:402:21: error: 'ZSTD_frameHeaderSize_min' defined but not used [-Werror=unused-const-variable=]
static const size_t ZSTD_frameHeaderSize_min = ZSTD_FRAMEHEADERSIZE_MIN;
^~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/Cellar/zstd/1.3.4//include/zstd.h:401:21: error: 'ZSTD_frameHeaderSize_prefix' defined but not used [-Werror=unused-const-variable=]
static const size_t ZSTD_frameHeaderSize_prefix = ZSTD_FRAMEHEADERSIZE_PREFIX;
^~~~~~~~~~~~~~~~~~~~~~~~~~~
```Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26202Packaged apparmor settings break tor within LXD containers2020-06-13T15:25:59ZTracPackaged apparmor settings break tor within LXD containersThe packaged apparmor settings in the latest (0.3.3.6-1) .deb packages provided via torproject.org will stop the tor service from starting up in at least Xenial (16.04) and Bionic (18.04) containers on Ubuntu, using the latest LXD snap.
...The packaged apparmor settings in the latest (0.3.3.6-1) .deb packages provided via torproject.org will stop the tor service from starting up in at least Xenial (16.04) and Bionic (18.04) containers on Ubuntu, using the latest LXD snap.
The machine hosting the container will see this in its syslog/auditlog:
`May 25 14:16:01 localhost kernel: [84735.795087] audit: type=1400 audit(1527257761.902:653): apparmor="DENIED" operation="file_mmap" namespace="root//lxd-juju-ef908d-1_<var-snap-lxd-common-lxd>" profile="system_tor" name="/usr/bin/tor" pid=18256 comm="tor" requested_mask="m" denied_mask="m" fsuid=1000000 ouid=1000000`
The fix is a simple one-character change in the `/etc/apparmor.d/abstractions/tor` file installed by the tor package, where the line `/usr/bin/tor r,` simply needs to change to `/usr/bin/tor mr,`.
**Trac**:
**Username**: bTor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26196Abort in test_bridges.c2020-06-13T15:25:57ZTracAbort in test_bridges.cRunning `test.exe bridges/clear_bridge_list` causes this assertion:
```
bridges/clear_bridge_list: May 23 17:12:53.714 [err] tor_assertion_failed_():
Bug: container.h:70: smartlist_get: Assertion sl->num_used > idx failed;
```
AFA...Running `test.exe bridges/clear_bridge_list` causes this assertion:
```
bridges/clear_bridge_list: May 23 17:12:53.714 [err] tor_assertion_failed_():
Bug: container.h:70: smartlist_get: Assertion sl->num_used > idx failed;
```
AFAICS, since `sweep_bridge_list()` caused all entries in `bridgelist` to get deleted, an index of zero is illegal. Don't ask me why.
And since I compiled all `test/*.c` sources with `-DDEBUG_SMARTLIST`, this will trigger this abort(). I fail to see why this isn't done in the officially.
\\
PS1. I'm on Win-10, tor.exe + libs was built with MSVC 2017.
\\
PS2. Build tor.exe from master at 23 May 2018.
**Trac**:
**Username**: gvanemTor: 0.3.4.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/26158A little bug of circular path of Tor2020-06-13T15:25:51ZTracA little bug of circular path of TorIn order to defend the **circular-path** attacks, Tor relays detects the next hop and previous hop of a circuit through node-id and Ed25519-id.
However, when the Tor relay detects the previous node has the same Ed25519-id with next nod...In order to defend the **circular-path** attacks, Tor relays detects the next hop and previous hop of a circuit through node-id and Ed25519-id.
However, when the Tor relay detects the previous node has the same Ed25519-id with next node, it forgot to return -1, and continue to extend the circuit.
This might cause some loopholes for the circular-path.
```
/* Next, check if we're being asked to connect to the hop that the
* extend cell came from. There isn't any reason for that, and it can
* assist circular-path attacks. */
if (tor_memeq(ec.node_id,
TO_OR_CIRCUIT(circ)->p_chan->identity_digest,
DIGEST_LEN)) {
log_fn(LOG_PROTOCO[[Image()]]L_WARN, LD_PROTOCOL,
"Client asked me to extend back to the previous hop.");
return -1;
}
/* Check the previous hop Ed25519 ID too */
if (! ed25519_public_key_is_zero(&ec.ed_pubkey) &&
ed25519_pubkey_eq(&ec.ed_pubkey,
&TO_OR_CIRCUIT(circ)->p_chan->ed25519_identity)) {
log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL,
"Client asked me to extend back to the previous hop "
"(by Ed25519 ID).");
}
```
**Trac**:
**Username**: TBD.ChenTor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26116OpenSSL 1.1.1 changed the semantics of the password callback return value2020-06-13T15:25:45ZNick MathewsonOpenSSL 1.1.1 changed the semantics of the password callback return valueIn c82c3462267afdbbaa5, openssl changed its interpretation of getting a "0" result from a PEM password callback. Previously, this indicated an error, and the documentation said:
>The callback **must** return the number of characters i...In c82c3462267afdbbaa5, openssl changed its interpretation of getting a "0" result from a PEM password callback. Previously, this indicated an error, and the documentation said:
>The callback **must** return the number of characters in the passphrase or 0 if an error occurred.
But now, 0 means an empty passphrase, and -1 means that an error occurred.
To avoid strange bugs and compatibility issues, we should have our pem_no_password_cb function return -1 instead. (-1 was always a supported return value, even if it isn't documented.)Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/26104Update to May GeoIP2 database2020-06-13T15:25:41ZKarsten LoesingUpdate to May GeoIP2 database[My geoip-2018-05-01 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-05-01) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other branch...[My geoip-2018-05-01 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-05-01) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other branches that are still maintained.
(Note to self when I use this ticket as template for the next months: 0.3.1 is end of life on 1 July 2018.)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26072Malformed connected cell closes connection but code continues2020-06-13T15:25:35ZMike PerryMalformed connected cell closes connection but code continuesIn connection_edge_process_relay_cell_not_open(), there is a clause that closes the connection if the connected cell is malformed. However, it does not return from the function. Every other clause where the connection is closed does retu...In connection_edge_process_relay_cell_not_open(), there is a clause that closes the connection if the connected cell is malformed. However, it does not return from the function. Every other clause where the connection is closed does return.
This looks like a bug. I couldn't immediately find any issues with this, though. Perhaps an assert if the connection gets marked twice..Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/26069hs-v3: Descriptor signature parsing should have a trailing white-space2020-06-13T15:25:34ZDavid Gouletdgoulet@torproject.orghs-v3: Descriptor signature parsing should have a trailing white-spaceFrom ticket #25552, nickm's comment:
I've reviewed the PR. The biggest issue is related to the use of "\n" signature_str, which I believe should be "\n" signature_str " " instead.
We'll fix it in #25552 for 034 but we need to backport...From ticket #25552, nickm's comment:
I've reviewed the PR. The biggest issue is related to the use of "\n" signature_str, which I believe should be "\n" signature_str " " instead.
We'll fix it in #25552 for 034 but we need to backport it back to 030 when it was first introduced. It won't affect any tor version on the ability to parse service descriptors. It will just reinforce the security and correctness.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/26007Stop logging stack contents when reading a zero-length bandwidth file2020-06-13T15:25:22ZteorStop logging stack contents when reading a zero-length bandwidth fileWhen reading a zero-length bandwidth file, Tor directory authorities read an uninitialised buffer and log it at warning level.
There is no guarantee that the buffer contains a NUL byte.When reading a zero-length bandwidth file, Tor directory authorities read an uninitialised buffer and log it at warning level.
There is no guarantee that the buffer contains a NUL byte.Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/26006LibreSSL compilation warnings on all supported Tor versions2020-06-13T15:25:22ZNick MathewsonLibreSSL compilation warnings on all supported Tor versionsOn 0.2.9 and later, I see libressl compilation warnings.On 0.2.9 and later, I see libressl compilation warnings.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/25960Allow additional header lines in bandwidth measurements documents2020-06-13T15:25:07ZjugaAllow additional header lines in bandwidth measurements documentsAs commented by teor in: https://github.com/pastly/simple-bw-scanner/pull/112#issuecomment-385108911
> get it backported to 0.2.9 and later.
> I think Tor should only warn if:
> an incomplete line contains a "bw=" key
> an incompl...As commented by teor in: https://github.com/pastly/simple-bw-scanner/pull/112#issuecomment-385108911
> get it backported to 0.2.9 and later.
> I think Tor should only warn if:
> an incomplete line contains a "bw=" key
> an incomplete line contains a "node_id=" key
> an incomplete line occurs after the first complete lineTor: 0.3.5.x-finaljugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/25936have travis display test-suite.log from the right place when DISTCHECK=yes2020-06-13T15:24:55ZTaylor Yuhave travis display test-suite.log from the right place when DISTCHECK=yesAfter #25814, Travis CI sometimes won't find test-suite.log because `make distcheck` runs `make check` in a subdirectory. This causes problems when there's a failure that's specific to `make distcheck`, like in [this example](https://tr...After #25814, Travis CI sometimes won't find test-suite.log because `make distcheck` runs `make check` in a subdirectory. This causes problems when there's a failure that's specific to `make distcheck`, like in [this example](https://travis-ci.org/torproject/tor/jobs/371634830).
We should create a new make target that shows test-suite.log from the correct place. (It's easier if it's a make target because then we have `$(distdir)` available.)Tor: 0.3.4.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/25912CID 1435130: Incorrect expression (COPY_PASTE_ERROR)2020-06-13T15:24:48ZGeorge KadianakisCID 1435130: Incorrect expression (COPY_PASTE_ERROR)Seems like #23693 caused the following coverity warning:
```
** CID 1435130: Incorrect expression (COPY_PASTE_ERROR)
/src/or/router.c: 153 in dup_onion_keys()
___________________________________________________________________________...Seems like #23693 caused the following coverity warning:
```
** CID 1435130: Incorrect expression (COPY_PASTE_ERROR)
/src/or/router.c: 153 in dup_onion_keys()
________________________________________________________________________________________________________
*** CID 1435130: Incorrect expression (COPY_PASTE_ERROR)
/src/or/router.c: 153 in dup_onion_keys()
147 tor_assert(key);
148 tor_assert(last);
149 tor_mutex_acquire(key_lock);
150 if (onionkey)
151 *key = crypto_pk_copy_full(onionkey);
152 else
>>> CID 1435130: Incorrect expression (COPY_PASTE_ERROR)
>>> "last" in "*last = NULL" looks like a copy-paste error.
153 *last = NULL;
154 if (lastonionkey)
155 *last = crypto_pk_copy_full(lastonionkey);
156 else
157 *last = NULL;
158 tor_mutex_release(key_lock);
```
Perhaps this new `*last = NULL;` should have been `*key = NULL`.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25818Investigate using coveralls with travis2020-06-13T15:24:28ZNick MathewsonInvestigate using coveralls with travisCoveralls can let us know when pull requests would change test coverage, and by how much.Coveralls can let us know when pull requests would change test coverage, and by how much.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/25718Update to April GeoIP2 database2020-06-13T15:24:10ZKarsten LoesingUpdate to April GeoIP2 database[My geoip-2018-04-03 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-04-03) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and other branch...[My geoip-2018-04-03 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-04-03) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and other branches that are still maintained.
(Note to self when I use this ticket as template for next month: 0.2.5 is end of life on 1 May 2018, and 0.3.1 is end of life on 1 July 2018.)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25629fix CID 14309322020-06-13T15:23:41ZTaylor Yufix CID 1430932Coverity found a null pointer reference in nodelist_add_microdesc().
This is almost certainly impossible assuming that the routerstatus_t
returned by router_get_consensus_status_by_descriptor_digest() always
corresponds to an entry in th...Coverity found a null pointer reference in nodelist_add_microdesc().
This is almost certainly impossible assuming that the routerstatus_t
returned by router_get_consensus_status_by_descriptor_digest() always
corresponds to an entry in the nodelist.Tor: 0.3.3.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/25617unable to resolve DNS requests from control port, regression2020-06-13T15:23:39Zstarlightunable to resolve DNS requests from control port, regression```
setevents addrmap
250 OK
resolve blog.torproject.org
250 OK
650 ADDRMAP blog.torproject.org <error> "2018-03-25 08:39:54" error=yes EXPIRES="2018-03-25 12:39:54" CACHED="NO"
```
```
Mar 25 08:39:55 Tor[]: Refusing to connect to hos...```
setevents addrmap
250 OK
resolve blog.torproject.org
250 OK
650 ADDRMAP blog.torproject.org <error> "2018-03-25 08:39:54" error=yes EXPIRES="2018-03-25 12:39:54" CACHED="NO"
```
```
Mar 25 08:39:55 Tor[]: Refusing to connect to hostname [scrubbed] because Port has NoDNSRequest set.
```Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/25469Update to March GeoIP2 database2020-06-13T15:22:54ZKarsten LoesingUpdate to March GeoIP2 database[My geoip-2018-03-08 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-03-08) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other re...[My geoip-2018-03-08 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-03-08) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.Tor: 0.2.9.x-final