The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:52:09Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27735Tors with cached consensuses can't upgrade to a version that stops supporting...2020-06-27T13:52:09ZteorTors with cached consensuses can't upgrade to a version that stops supporting a required protocolWhen Tor loads the cached consensus, it checks the protocols in that consensus, and then exits if it does not have any required protocols. These checks happen before signatures and expiry are checked. (And before trying to get a new cons...When Tor loads the cached consensus, it checks the protocols in that consensus, and then exits if it does not have any required protocols. These checks happen before signatures and expiry are checked. (And before trying to get a new consensus.)
This makes it impossible for a Tor with a cached consensus to stop supporting a protocol required in that consensus.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27734tor on OpenSSL claims not to support LinkAuth=12020-06-27T13:52:09Zteortor on OpenSSL claims not to support LinkAuth=1HAVE_WORKING_TOR_TLS_GET_TLSSECRETS is defined in tortls.h, which protover.c and test_protover.c do not include.
Therefore, every Tor on master now thinks it only supports LinkAuth=3:
```
#ifdef HAVE_WORKING_TOR_TLS_GET_TLSSECRETS
"...HAVE_WORKING_TOR_TLS_GET_TLSSECRETS is defined in tortls.h, which protover.c and test_protover.c do not include.
Therefore, every Tor on master now thinks it only supports LinkAuth=3:
```
#ifdef HAVE_WORKING_TOR_TLS_GET_TLSSECRETS
"LinkAuth=1,3 "
#else
"LinkAuth=3 "
#endif
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27731tor restart loop: "The missing protocols are: LinkAuth=1"2020-06-27T13:52:09Ztraumschuletor restart loop: "The missing protocols are: LinkAuth=1"Since the (automatic) apt upgrade to 0.3.5.0-alpha-dev-20180916T182348Z-1~d99.buster+1 tor restarted in a loop:
```
Sep 17 01:05:24.000 [err] {GENERAL} At least one protocol listed as required in the consensus is not supported by this v...Since the (automatic) apt upgrade to 0.3.5.0-alpha-dev-20180916T182348Z-1~d99.buster+1 tor restarted in a loop:
```
Sep 17 01:05:24.000 [err] {GENERAL} At least one protocol listed as required in the consensus is not supported by this version of Tor. You should upgrade. This version of Tor will not work as a clien
t on the Tor network. The missing protocols are: LinkAuth=1
Sep 17 01:05:26.000 [notice] Tor 0.3.5.0-alpha-dev opening log file.
Sep 17 01:05:26.531 [notice] Tor 0.3.5.0-alpha-dev running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.0h, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.5.
Sep 17 01:05:26.539 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Sep 17 01:05:26.539 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Sep 17 01:05:26.540 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Sep 17 01:05:26.540 [notice] Read configuration file "/etc/tor/torrc".
Sep 17 01:05:26.590 [notice] Opening Socks listener on 127.0.0.1:9050
Sep 17 01:05:26.591 [notice] Opened Socks listener on 127.0.0.1:9050
Sep 17 01:05:26.591 [notice] Opening HTTP tunnel listener on 127.0.0.1:9099
Sep 17 01:05:26.592 [notice] Opened HTTP tunnel listener on 127.0.0.1:9099
Sep 17 01:05:26.592 [notice] Opening Control listener on 127.0.0.1:9051
Sep 17 01:05:26.592 [notice] Opened Control listener on 127.0.0.1:9051
Sep 17 01:05:26.000 [warn] {GENERAL} Your log may contain sensitive information - you disabled SafeLogging, and you're logging more than "notice". Don't log unless it serves an important reason. Overwrite the log afterwards.
Sep 17 01:05:26.000 [info] {GENERAL} options_act_reversible(): Recomputed OOS thresholds: ConnLimit 1000, ConnLimit_ 65504, ConnLimit_high_thresh 65440, ConnLimit_low_thresh 49128
Sep 17 01:05:26.000 [info] {GENERAL} or_state_load(): Loaded state from "/var/lib/tor/state"
Sep 17 01:05:26.000 [info] {GUARD} sampled_guards_update_from_consensus(): Not updating the sample guard set; we have no live consensus.
Sep 17 01:05:26.000 [info] {GUARD} sample_reachable_filtered_entry_guards(): Trying to sample a reachable guard: We know of 0 in the USABLE_FILTERED set.
Sep 17 01:05:26.000 [info] {GUARD} sample_reachable_filtered_entry_guards(): (That isn't enough. Trying to expand the sample.)
Sep 17 01:05:26.000 [info] {GUARD} entry_guards_expand_sample(): Not expanding the sample guard set; we have no live consensus.
Sep 17 01:05:26.000 [info] {GUARD} sample_reachable_filtered_entry_guards(): (After filters [b], we have 0 guards to consider.)
Sep 17 01:05:26.000 [info] {CIRC} circuit_build_times_parse_state(): Adding 11 timeouts.
Sep 17 01:05:26.000 [info] {CIRC} circuit_build_times_parse_state(): Loaded 1000/1000 values from 48 lines in circuit time histogram
Sep 17 01:05:26.000 [info] {CIRC} circuit_build_times_get_xm(): Xm mode #0: 575 91
Sep 17 01:05:26.000 [info] {CIRC} circuit_build_times_get_xm(): Xm mode #1: 675 70
Sep 17 01:05:26.000 [info] {CIRC} circuit_build_times_get_xm(): Xm mode #2: 375 85
Sep 17 01:05:26.000 [info] {CIRC} circuit_build_times_set_timeout(): Set buildtimeout to low value 871.512173ms. Setting to 1500ms
Sep 17 01:05:26.000 [info] {CIRC} circuit_build_times_set_timeout(): Based on 1000 circuit times, it looks like we don't need to wait so long for circuits to finish. We will now assume a circuit is too slow to use after waiting 2 seconds.
Sep 17 01:05:26.000 [info] {CIRC} circuit_build_times_set_timeout(): Circuit timeout data: 1500.000000ms, 60000.000000ms, Xm: 534, a: 3.285680, r: 0.046000
Sep 17 01:05:26.000 [info] {FS} read_file_to_str(): Could not open "/var/lib/tor/router-stability": No such file or directory
Sep 17 01:05:26.000 [info] {GENERAL} init_cookie_authentication(): Generated auth cookie file in '"/var/run/tor/control.authcookie"'.
Sep 17 01:05:26.000 [info] {SCHED} scheduler_kist_set_full_mode(): Setting KIST scheduler with kernel support (KIST mode)
Sep 17 01:05:26.000 [info] {OR} cmux_ewma_set_options(): Enabled cell_ewma algorithm because of value in CircuitPriorityHalflifeMsec in consensus; scale factor is 0.793701 per 10 seconds
Sep 17 01:05:26.000 [notice] {GENERAL} Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Sep 17 01:05:27.000 [notice] {GENERAL} Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Sep 17 01:05:27.000 [info] {CIRC} add_predicted_port(): New port prediction added. Will continue predictive circ building for 2079 more seconds.
Sep 17 01:05:27.000 [info] {CRYPTO} crypto_openssl_late_init(): NOT using OpenSSL engine support.
Sep 17 01:05:27.000 [info] {CRYPTO} evaluate_evp_for_aes(): This version of OpenSSL has a known-good EVP counter-mode implementation. Using it.
Sep 17 01:05:27.000 [notice] {CONTROL} Bootstrapped 0%: Starting
Sep 17 01:05:27.000 [info] {DIR} trusted_dirs_load_certs_from_string(): Adding cached certificate for directory authority maatuska with signing key 10A69F531F8421310537EAC881F7DD354F251D31
Sep 17 01:05:27.000 [info] {DIR} trusted_dirs_load_certs_from_string(): Adding cached certificate for directory authority dannenberg with signing key CD1FD971855430880D3C31E0331C5C55800C2F79
Sep 17 01:05:27.000 [info] {DIR} trusted_dirs_load_certs_from_string(): Adding cached certificate for directory authority gabelmoo with signing key E1249D5F87EAD43CD4A48DF9CFCFE810BEEE5287
Sep 17 01:05:27.000 [info] {DIR} trusted_dirs_load_certs_from_string(): Adding cached certificate for directory authority bastet with signing key 88E1BDDC8E6363355910D086B37B562F81674DC1
Sep 17 01:05:27.000 [info] {DIR} trusted_dirs_load_certs_from_string(): Adding cached certificate for directory authority longclaw with signing key D632ADF38603F34EAFCB461C4DA5F67EF62BE7EC
Sep 17 01:05:27.000 [info] {DIR} trusted_dirs_load_certs_from_string(): Adding cached certificate for directory authority tor26 with signing key 719A962F8F7DC7F0A34A545E7A45368FF8A23D2A
Sep 17 01:05:27.000 [info] {DIR} trusted_dirs_load_certs_from_string(): Adding cached certificate for directory authority Faravahar with signing key 517095062288D1B5C7BD6517A677C586D996818B
Sep 17 01:05:27.000 [info] {DIR} trusted_dirs_load_certs_from_string(): Adding cached certificate for directory authority dizum with signing key 109A865D7DBE58367C120353CBE9947EE263695A
Sep 17 01:05:27.000 [info] {DIR} trusted_dirs_load_certs_from_string(): Adding cached certificate for directory authority moria1 with signing key 6E44451E3F1CEB435E4D95C1F8B12AA022BB34CF
Sep 17 01:05:28.000 [err] {GENERAL} At least one protocol listed as required in the consensus is not supported by this version of Tor. You should upgrade. This version of Tor will not work as a client on the Tor network. The missing protocols are: LinkAuth=1
[restart]
Sep 17 01:06:08.000 [info] {GENERAL} options_act_reversible(): Recomputed OOS thresholds: ConnLimit 1000, ConnLimit_ 65504, ConnLimit_high_thresh 65440, ConnLimit_low_thresh 49128
Sep 17 01:06:08.000 [info] {FS} tor_lockfile_lock(): Locking "/var/lib/tor/lock"
```
Downgrading fixed it. git HEAD is also affected, last working commit in master: 035166e7bf30645f6da9d39374f5e9c9efe867f8
```
dpkg -i /var/cache/apt/archives/tor_0.3.5.0-alpha-dev-20180915T011035Z-1~d99.buster+1_i386.deb
Tor version 0.3.5.0-alpha-dev (git-035166e7bf30645f).
```
First failing:
http://jqs44zhtxl2uo6gk.onion/tor.git/commit/?id=991bec67ee41fd7f3c12e9194d96491b51bedd50https://gitlab.torproject.org/tpo/core/tor/-/issues/27730CID 1439330: "st.st_size > 9223372036854775807L" is always false2020-06-27T13:52:09ZteorCID 1439330: "st.st_size > 9223372036854775807L" is always falseCoverity claims:
```
*** CID 1439330: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/src/lib/crypt_ops/crypto_rsa.c: 554 in crypto_pk_read_private_key_from_filename()
548 const char *...Coverity claims:
```
*** CID 1439330: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/src/lib/crypt_ops/crypto_rsa.c: 554 in crypto_pk_read_private_key_from_filename()
548 const char *keyfile)
549 {
550 struct stat st;
551 char *buf = read_file_to_str(keyfile, 0, &st);
552 if (!buf)
553 return -1;
CID 1439330: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
"st.st_size > 9223372036854775807L" is always false regardless of the values of its operands. This occurs as the logical operand of "if".
554 if (st.st_size > SSIZE_MAX)
555 return -1;
556
557 int rv = crypto_pk_read_private_key_from_string(env, buf,
558 (ssize_t)st.st_size);
559 memwipe(buf, 0, (size_t)st.st_size);
```
But st_size is off_t, and the POSIX standard doesn't require a particular size for off_t:
```
blkcnt_t and off_t shall be signed integer types.
```
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html#tag_13_67
In particular, some 32-bit pointer (SSIZE_MAX) operating systems may have a 64-bit file off_t. (I know that at least one BSD does, and I suspect that macOS and Linux also do in their 64-bit file size modes.)Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27728Signature mismatch for crypto_strongest_rand() in ed-donna code breaks -flto ...2020-06-27T13:52:10ZAlex XuSignature mismatch for crypto_strongest_rand() in ed-donna code breaks -flto compilation```
./src/lib/crypt_ops/crypto_rand.h:24:1: error: variable ‘crypto_strongest_rand’ redeclared as function
MOCK_DECL(void,crypto_strongest_rand,(uint8_t *out, size_t out_len));
^
./src/lib/crypt_ops/crypto_rand.h:24:1: error: variable ...```
./src/lib/crypt_ops/crypto_rand.h:24:1: error: variable ‘crypto_strongest_rand’ redeclared as function
MOCK_DECL(void,crypto_strongest_rand,(uint8_t *out, size_t out_len));
^
./src/lib/crypt_ops/crypto_rand.h:24:1: error: variable ‘crypto_strongest_rand’ redeclared as function
src/lib/crypt_ops/crypto_rand.c:338:1: note: previously declared here
MOCK_IMPL(void,
^
```Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27725Stealthy onions should appear to be offline2022-06-24T14:52:40ZtraumschuleStealthy onions should appear to be offlineWorking on legacy/trac#27680 and testing basic and stealth onion services i noticed that they behavior is the same. Instead i expected the stealthy one to look like it's offline. See also legacy/trac#23653
What i observed was for both a...Working on legacy/trac#27680 and testing basic and stealth onion services i noticed that they behavior is the same. Instead i expected the stealthy one to look like it's offline. See also legacy/trac#23653
What i observed was for both auth types (without correct auth cookie in the client):
When the descriptors weren't uploaded yet, the client failed immediately:
```
[warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
{REND} Closing stream for '<scrubbed>.onion': hidden service is unavailable (try again later).
```
After uploading the descriptors the connection timed out:
```
[notice] Tried for 120 seconds to get a connection to <scrubbed>:80. Giving up. (waiting for rendezvous desc)
```
Please let stealthy onions appear to be offline.https://gitlab.torproject.org/tpo/core/tor/-/issues/27722rust protover doesn't canonicalize adjacent and overlapping ranges2021-09-16T14:28:09ZTracrust protover doesn't canonicalize adjacent and overlapping ranges`protover.c` accepts both `"Foo=1-3,4-5"` and `"Foo=1-3,2-5"` and then canonicalizes them into `"Foo=1-5"` with `contract_protocol_list()`. Rust rejects the 2nd one as malformed.
**Trac**:
**Username**: cyberpunks`protover.c` accepts both `"Foo=1-3,4-5"` and `"Foo=1-3,2-5"` and then canonicalizes them into `"Foo=1-5"` with `contract_protocol_list()`. Rust rejects the 2nd one as malformed.
**Trac**:
**Username**: cyberpunkshttps://gitlab.torproject.org/tpo/core/tor/-/issues/27713uncrustify config file to autofix C code whitespace and indentation2020-07-28T23:04:26Zrl1987uncrustify config file to autofix C code whitespace and indentationSee: https://github.com/uncrustify/uncrustify
Making it correspond to things that `make check-spaces` checks for would be convenient for C developer working with Tor.See: https://github.com/uncrustify/uncrustify
Making it correspond to things that `make check-spaces` checks for would be convenient for C developer working with Tor.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27712Introduce Finite State Machine abstraction into Tor codebase2020-07-29T15:49:54Zrl1987Introduce Finite State Machine abstraction into Tor codebaseThis would make e.g. our SOCKS code easier to understand and maintain.This would make e.g. our SOCKS code easier to understand and maintain.https://gitlab.torproject.org/tpo/core/tor/-/issues/27711Hardened build fails in tortls_openssl.c2020-06-27T13:52:10Zrl1987Hardened build fails in tortls_openssl.c```
src/lib/tls/tortls_openssl.c: In function ‘tor_tls_release_socket’:
src/lib/tls/tortls_openssl.c:1172:5: error: value computed is not used [-Werror=unused-value]
BIO_set_close(rbio, BIO_NOCLOSE);
^
src/lib/tls/tortls_openss...```
src/lib/tls/tortls_openssl.c: In function ‘tor_tls_release_socket’:
src/lib/tls/tortls_openssl.c:1172:5: error: value computed is not used [-Werror=unused-value]
BIO_set_close(rbio, BIO_NOCLOSE);
^
src/lib/tls/tortls_openssl.c:1175:5: error: value computed is not used [-Werror=unused-value]
BIO_set_close(wbio, BIO_NOCLOSE);
^
cc1: all warnings being treated as errors
make: *** [src/lib/tls/src_lib_libtor_tls_a-tortls_openssl.o] Error 1
```
https://travis-ci.org/torproject/tor/jobs/428655734Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27709The compiler doesn't warn about tor_assert(a = b)2020-06-27T13:52:10ZNick MathewsonThe compiler doesn't warn about tor_assert(a = b)C's assignment expressions are notoriously easy to mis-type when you are trying to enter an equality expression instead. Most compilers will notice when you say something like `if (a = b)`, and make you add an extra set of parentheses. ...C's assignment expressions are notoriously easy to mis-type when you are trying to enter an equality expression instead. Most compilers will notice when you say something like `if (a = b)`, and make you add an extra set of parentheses. But we've done something with our tor_assert() macro so this doesn't happen. We should fix that.
Found from ahf's review of legacy/trac#27289
We should also make sure BUG doesn't have this problem.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27708Heap use-after-free on git master dbb0abc9f1a174efdb65d581f5dbe46dbad2ebb52020-06-27T13:52:10ZDavid Gouletdgoulet@torproject.orgHeap use-after-free on git master dbb0abc9f1a174efdb65d581f5dbe46dbad2ebb5I found this issue by setting an invalid `HiddenServiceDir` containing 2 level of directories for tor to create for which it can't do it leading to `options_act()` returning -1.
```
HiddenServiceDir /tmp/level1/level2
```
Here is the A...I found this issue by setting an invalid `HiddenServiceDir` containing 2 level of directories for tor to create for which it can't do it leading to `options_act()` returning -1.
```
HiddenServiceDir /tmp/level1/level2
```
Here is the ASAN output:
```
==10573==ERROR: AddressSanitizer: heap-use-after-free on address 0x61d000002948 at pc 0x55741b1f88d1 bp 0x7ffe0d70bc10 sp 0x7ffe0d70bc00
READ of size 8 at 0x61d000002948 thread T0
#0 0x55741b1f88d0 in or_options_free_ src/app/config/config.c:1005
#1 0x55741b2009af in config_free_all src/app/config/config.c:1034
#2 0x55741ad38034 in tor_free_all src/core/mainloop/main.c:3693
#3 0x55741ad38b6e in tor_run_main src/core/mainloop/main.c:4277
#4 0x55741ad2286b in tor_main src/feature/api/tor_api.c:164
#5 0x55741ad1d7cb in main src/app/main/tor_main.c:32
#6 0x7fc43440109a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
#7 0x55741ad219e9 in _start (/home/dgoulet/Documents/git/tor/src/app/tor+0x9119e9)
0x61d000002948 is located 200 bytes inside of 2264-byte region [0x61d000002880,0x61d000003158)
freed by thread T0 here:
#0 0x7fc43614cb70 in free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedb70)
#1 0x55741b23e3e7 in config_free_ src/app/config/confparse.c:871
#2 0x55741b1f8548 in or_options_free_ src/app/config/config.c:1026
#3 0x55741b22bbcc in options_init_from_string src/app/config/config.c:5487
#4 0x55741b22d540 in options_init_from_torrc src/app/config/config.c:5233
#5 0x55741ad37098 in tor_init src/core/mainloop/main.c:3540
#6 0x55741ad389c0 in tor_run_main src/core/mainloop/main.c:4275
#7 0x55741ad2286b in tor_main src/feature/api/tor_api.c:164
#8 0x55741ad1d7cb in main src/app/main/tor_main.c:32
#9 0x7fc43440109a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
previously allocated by thread T0 here:
#0 0x7fc43614cf30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
#1 0x55741b3b378a in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x55741b3b3821 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
#3 0x55741b22b294 in options_init_from_string src/app/config/config.c:5336
#4 0x55741b22d540 in options_init_from_torrc src/app/config/config.c:5233
#5 0x55741ad37098 in tor_init src/core/mainloop/main.c:3540
#6 0x55741ad389c0 in tor_run_main src/core/mainloop/main.c:4275
#7 0x55741ad2286b in tor_main src/feature/api/tor_api.c:164
#8 0x55741ad1d7cb in main src/app/main/tor_main.c:32
#9 0x7fc43440109a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
SUMMARY: AddressSanitizer: heap-use-after-free src/app/config/config.c:1005 in or_options_free_
```
Logs shows:
```
Sep 14 10:20:00.000 [warn] Error creating directory /tmp/level1/level2: No such file or directory
Sep 14 10:20:00.000 [warn] Error loading rendezvous service keys
Sep 14 10:20:00.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.3.5.0-alpha-dev dbb0abc9f1a174ef)
```
What I can tell is that if `options_act()` returns -1, we'll inevitably end up in this situation so this isn't HS only. Kind of difficult to follow the stacktrace as the use-after-free points to a free(). I know that the pointer there is NULL at that time...Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27707Improve some v3 onion logs2020-06-27T13:52:11ZGeorge KadianakisImprove some v3 onion logsI've been debugging lots of v3 logs lately and I noticed a few issues with them that can be improved:
1)
```
set_descriptor_revision_counter(): Encrypted revision counter 118682 to -403149886
```
no need for `%ld` there, it's an `uint64...I've been debugging lots of v3 logs lately and I noticed a few issues with them that can be improved:
1)
```
set_descriptor_revision_counter(): Encrypted revision counter 118682 to -403149886
```
no need for `%ld` there, it's an `uint64_t`.
2) On the client side when we fetch descriptors we have the following log message that displays the onion address and blinded key as a base64 instead of the typical base32. We should unify the format to make grep easier:
```
[info] directory_launch_v3_desc_fetch(): Descriptor fetch request for service khXWrMUXYYW1so9/CIWe5kI7+nxcSYO9zd4Edl2IIz8 with blinded key QvyLoKg/B6musSsNfL4vMk2wD2HpiDsTU3gM7kY41Sg to directory $C0B7413D690411DF5D2B0D838F56792312697122~minitor at 185.143.62.9
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27694what happens if we have both a firewall-bypass proxy and a pluggable transport?2020-07-28T23:01:36ZTaylor Yuwhat happens if we have both a firewall-bypass proxy and a pluggable transport?Tor Launcher seems to let you configure both a "proxy" and a "bridge" (typically a PT bridge). Does this do anything useful? arma thinks it might just catch fire. We might want to make this do something useful. e.g., what if you need...Tor Launcher seems to let you configure both a "proxy" and a "bridge" (typically a PT bridge). Does this do anything useful? arma thinks it might just catch fire. We might want to make this do something useful. e.g., what if you need to use an HTTP proxy to get out of your network, and obfs4 to connect to a relay?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27691reset bootstrap progress when enough things change2020-07-28T23:01:47ZTaylor Yureset bootstrap progress when enough things changeRight now, setting DisableNetwork=1 doesn't reset the bootstrap progress indicator. It probably should, because all network connections to bridges or relays will close. This will improve the user experience once we have legacy/trac#271...Right now, setting DisableNetwork=1 doesn't reset the bootstrap progress indicator. It probably should, because all network connections to bridges or relays will close. This will improve the user experience once we have legacy/trac#27103 in place, because then the earlier progress shown will be the initial network connection that everything else depends on.
We probably also want to reset the bootstrap progress when a configuration change causes us to disconnect from all our guards.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27690Update bandwidth-file-spec with scaling methods2020-06-27T13:52:11ZjugaUpdate bandwidth-file-spec with scaling methodsAs commented in legacy/trac#27338, and implemented in legacy/trac#27337 and legacy/trac#27336 we should update the spec with the scaling method we would use.
Since currently it's possible to generate the bandwidth files using different s...As commented in legacy/trac#27338, and implemented in legacy/trac#27337 and legacy/trac#27336 we should update the spec with the scaling method we would use.
Since currently it's possible to generate the bandwidth files using different scaling methods, we should first decide which one to use during the transition from torflow to sbws and which one we would use after the transition.Tor: 0.4.0.x-finaljugajugahttps://gitlab.torproject.org/tpo/core/tor/-/issues/27687rust protover accepts non ASCII in protocol names2020-06-27T13:52:11ZTracrust protover accepts non ASCII in protocol names
**Trac**:
**Username**: cyberpunks
**Trac**:
**Username**: cyberpunksTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27686OOM code should count space used in a circuit's half-closed list2020-06-27T13:52:11ZNick MathewsonOOM code should count space used in a circuit's half-closed listThe new code in legacy/trac#25573 should be integrated with the circuit OOM code.The new code in legacy/trac#25573 should be integrated with the circuit OOM code.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27685Memory leak in tortls/openssl/context_new2020-06-27T13:52:11ZNick MathewsonMemory leak in tortls/openssl/context_newNot sure how far to backport this one; let's see.Not sure how far to backport this one; let's see.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27684Memory leak in tortls/openssl/try_to_extract_certs_from_tls2020-06-27T13:52:11ZNick MathewsonMemory leak in tortls/openssl/try_to_extract_certs_from_tlsThere's a memory leak reported on the unit test `tortls/openssl/try_to_extract_certs_from_tls`. Not sure how far to backport; let's see.There's a memory leak reported on the unit test `tortls/openssl/try_to_extract_certs_from_tls`. Not sure how far to backport; let's see.Tor: 0.3.5.x-finalNick MathewsonNick Mathewson