Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:51:20Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33284Make the pre-commit hook call the user's hooks, not the repository hooks2020-06-13T15:51:20ZteorMake the pre-commit hook call the user's hooks, not the repository hooksWe should stop executing untrusted scripts.We should stop executing untrusted scripts.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32778Initialise pubsub in Windows NT service mode2020-06-13T15:49:15ZcypherpunksInitialise pubsub in Windows NT service modei don't know what this error is about. Seen in logs many thousands of many of this log lines (650k), even if they tell to not warn about it again.
```
Dec 17 01:17:40.000 [warn] {HANDSHAKE} 20190 connections have failed:
Dec 17 01:17:40....i don't know what this error is about. Seen in logs many thousands of many of this log lines (650k), even if they tell to not warn about it again.
```
Dec 17 01:17:40.000 [warn] {HANDSHAKE} 20190 connections have failed:
Dec 17 01:17:40.000 [warn] {HANDSHAKE} 20190 connections died in state connect()ing with SSL state (No SSL object)
Dec 17 01:17:40.000 [warn] {BUG} tor_bug_occurred_(): Bug: pubsub_publish.c:37: pubsub_pub_: Non-fatal assertion !(! d) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.5 )
Dec 17 01:17:40.000 [warn] {BUG} Bug: Tor 0.4.2.5: Non-fatal assertion !(! d) failed in pubsub_pub_ at pubsub_publish.c:37. (Stack trace not available) (on Tor 0.4.2.5 )
Dec 17 01:17:40.000 [warn] {BUG} tor_bug_occurred_(): Bug: pubsub_publish.c:37: pubsub_pub_: Non-fatal assertion !(! d) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.5 )
Dec 17 01:17:40.000 [warn] {BUG} Bug: Tor 0.4.2.5: Non-fatal assertion !(! d) failed in pubsub_pub_ at pubsub_publish.c:37. (Stack trace not available) (on Tor 0.4.2.5 )
Dec 17 01:17:40.000 [warn] {CONTROL} Problem bootstrapping. Stuck at 0% (starting): Starting. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 20192; recommendation warn; host CE3FE883C6C9EF475EA097DC3E33A6F32B852DA1 at 78.129.218.56:443)
```Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31898Occasional crash during shutdown when using Tor API2020-06-13T15:46:10ZMatthew FinkelOccasional crash during shutdown when using Tor APIThis is using a JNI wrapper.
I can probably create a test case for easier debugging. It seems like this is a race condition within the new pubsub system. I can reproduce this with an example program that configures Tor via the API and ...This is using a JNI wrapper.
I can probably create a test case for easier debugging. It seems like this is a race condition within the new pubsub system. I can reproduce this with an example program that configures Tor via the API and sends a `SIGNAL TERM` shortly after tor begins running and the control socket becomes available.
```
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f8bcc822535 in __GI_abort () at abort.c:79
#2 0x00007f8b94b01dbe in tor_raw_abort_ () at src/lib/err/torerr.c:227
#3 0x00007f8b94b016d0 in crash_handler (sig=<optimized out>, si=<optimized out>, ctx_=<optimized out>) at src/lib/err/backtrace.c:175
#4 <signal handler called>
#5 0x00007f8b94ae0ae4 in max_in_sl (sl=<optimized out>, sl=<optimized out>, dflt=0) at src/lib/dispatch/dispatch_new.c:36
#6 dispatch_new (cfg=0x7f8b64033520) at src/lib/dispatch/dispatch_new.c:121
#7 0x00007f8b94ade9ac in pubsub_builder_finalize (builder=0x7f8b64029eb0, items_out=0x7f8b94c193b8 <the_pubsub_items>) at src/lib/pubsub/pubsub_build.c:293
#8 0x00007f8b9496666c in tor_mainloop_connect_pubsub (builder=0x7f8b64029eb0) at src/core/mainloop/mainloop_pubsub.c:56
#9 0x00007f8b94952741 in pubsub_install () at src/app/main/main.c:1246
#10 tor_run_main (tor_cfg=<optimized out>) at src/app/main/main.c:1297
#11 0x00007f8b9495034c in RunMain (env=0x7f8bc4250b18, thisObj=0x7f8b9431d9b8) at src/feature/api/TorApi.cc:179
#12 0x00007f8b949502dd in Java_api_TorApi_runMain (env=0x7f8bc4250b18, thisObj=0x7f8b9431d9b8) at src/feature/api/TorApi.cc:279
#13 0x00007f8bac8d4990 in ?? ()
#14 0x00007f8bac8ce450 in ?? ()
#15 0x0000000718c7c3a8 in ?? ()
#16 0x00007f8b9431d950 in ?? ()
#17 0x0000000000000000 in ?? ()
```
Bisecting found `a8c0f4ddfe3f0a63bd499959c8d921346aa9766e is the first bad commit`.
The fault is at the first dereference (i don't know if it's `*u` or `*maxptr`). I'm guessing the memory was already freed for exit by the time this procedure is called.
```
29 static int
30 max_in_sl(const smartlist_t *sl, int dflt)
31 {
32 uint16_t *maxptr = NULL;
33 SMARTLIST_FOREACH_BEGIN(sl, uint16_t *, u) {
34 if (!maxptr)
35 maxptr = u;
36 else if (*u > *maxptr)
37 maxptr = u;
38 } SMARTLIST_FOREACH_END(u);
39
40 return maxptr ? *maxptr : dflt;
41 }
```
Tor was configured with `--Log "notice stdout" --AvoidDiskWrites 1 --SocksPort unix:${HOME}/private_tor/test_socks --DisableNetwork 0`.
This shouldn't be a common edge case, but I stumbled upon it while testing something else.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://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/31080Stop using the same value for LD_NO_MOCK and LD_MESG2020-06-13T15:46:03ZteorStop using the same value for LD_NO_MOCK and LD_MESGLD_NO_MOCK and LD_MESG have the same value, which is a bug in 0.4.1.1-alpha and later.
We'll need to make log_domain_mask_t into a u64, and change the values of the domain flags so they go down from 63 (not 31).
We'll also need to chan...LD_NO_MOCK and LD_MESG have the same value, which is a bug in 0.4.1.1-alpha and later.
We'll need to make log_domain_mask_t into a u64, and change the values of the domain flags so they go down from 63 (not 31).
We'll also need to change the corresponding type in Rust to u64. Maybe we should define a type, rather than using u64 everywhere.
This is a bug on #28226, which is Sponsor 31 must, so I'm marking this ticket as sponsor 31 must.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30979pre-push hook runs practracker unconditionally2020-06-13T15:44:22ZNick Mathewsonpre-push hook runs practracker unconditionallyOur pre-push hook script runs practracker whenever it exists. But we only want to run practracker on branches that are targeted for master.
I think perhaps we should change it to try making check-local? Or perhaps it could check for ...Our pre-push hook script runs practracker whenever it exists. But we only want to run practracker on branches that are targeted for master.
I think perhaps we should change it to try making check-local? Or perhaps it could check for the existence of some other file that we could use to indicate whether we want practracker to run.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31462Remove duplicate call to practracker in pre-commit hook2020-06-13T15:44:22ZteorRemove duplicate call to practracker in pre-commit hook#30051 added practracker to the pre-push and pre-commit hooks, but the pre-push hook already calls the pre-commit hook.
I'm just opening this ticket for the bug number, the fix PR is in #30979.
gaba, I think tooling can be part of spon...#30051 added practracker to the pre-push and pre-commit hooks, but the pre-push hook already calls the pre-commit hook.
I'm just opening this ticket for the bug number, the fix PR is in #30979.
gaba, I think tooling can be part of sponsor 31?Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31040Stop showing git scripts changes, unless the base is master2020-06-13T15:43:18ZteorStop showing git scripts changes, unless the base is masterIn #29588, we made the pre-merge script log changes to the git scripts.
But it logs (the wrong) changes when I'm merging into maint-0.4.1 or earlier.
Let's just make it log changes when it's merging into master?In #29588, we made the pre-merge script log changes to the git scripts.
But it logs (the wrong) changes when I'm merging into maint-0.4.1 or earlier.
Let's just make it log changes when it's merging into master?Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30992circpadding machines have shutdown sync issues (with intro circ NACKs and oth...2020-06-13T15:43:02ZGeorge Kadianakiscircpadding machines have shutdown sync issues (with intro circ NACKs and other cases)When client-side intro circuits get NACKed they re-extend to a different intro point using the same circuit.
This seems to mess up the circsetup machines and we get "padding came from wrong hop" log warns.When client-side intro circuits get NACKed they re-extend to a different intro point using the same circuit.
This seems to mess up the circsetup machines and we get "padding came from wrong hop" log warns.Tor: 0.4.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/30956Publish bridge ServerTransportPlugin lines, even when ExtraInfoStatistics are...2020-06-13T15:42:53ZteorPublish bridge ServerTransportPlugin lines, even when ExtraInfoStatistics are offIn #29018, we disabled all extrainfo contents when ExtraInfoStatistics is off.
But we need to publish the ServerTransportPlugin lines for bridges, even when their statistics are off.
See https://trac.torproject.org/projects/tor/ticket/...In #29018, we disabled all extrainfo contents when ExtraInfoStatistics is off.
But we need to publish the ServerTransportPlugin lines for bridges, even when their statistics are off.
See https://trac.torproject.org/projects/tor/ticket/30441#comment:13 for details.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30674Find out why ubsan/asan CI didn't catch #306292020-06-13T15:41:53ZNick MathewsonFind out why ubsan/asan CI didn't catch #30629Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30646HSFETCH always returning 512 Bad argument2020-06-13T15:41:51ZTracHSFETCH always returning 512 Bad argumentDoing a "HSFETCH" on a v2 or v3 service always seems to return "512 Bad arguments to HSFETCH: Empty body"
i.e
```
telnet localhost 9055
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
AUTHENTICATE
250 OK
HSFETCH fa...Doing a "HSFETCH" on a v2 or v3 service always seems to return "512 Bad arguments to HSFETCH: Empty body"
i.e
```
telnet localhost 9055
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
AUTHENTICATE
250 OK
HSFETCH facebookcorewwwi
512 Bad arguments to HSFETCH: Empty body
```
Works fine for version 0.4.0.5
**Trac**:
**Username**: csucuTor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30629We seem to be reading some freed events on exit2020-06-13T15:41:46ZRoger DingledineWe seem to be reading some freed events on exitRun your Tor master as a client under valgrind:
```
$ valgrind --leak-check=full src/app/tor
```
and wait for it to bootstrap to 100%. Then ctrl-c it.
On exit, valgrind will give you a pile of complaints like
```
==4119== Invalid read o...Run your Tor master as a client under valgrind:
```
$ valgrind --leak-check=full src/app/tor
```
and wait for it to bootstrap to 100%. Then ctrl-c it.
On exit, valgrind will give you a pile of complaints like
```
==4119== Invalid read of size 8
==4119== at 0x4C1DB9C: ??? (in /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6.0.2)
==4119== by 0x4C21A78: event_free (in /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6.0.2)
==4119== by 0x2ADA19: tor_event_free_ (compat_libevent.c:76)
==4119== by 0x2ADA19: mainloop_event_free_ (compat_libevent.c:461)
==4119== by 0x17748B: tor_mainloop_free_all (mainloop.c:2523)
==4119== by 0x1665FB: subsystems_shutdown_downto (subsysmgr.c:185)
==4119== by 0x165FB4: tor_free_all (shutdown.c:162)
==4119== by 0x164B54: tor_run_main (main.c:1360)
==4119== by 0x1620F9: tor_main (tor_api.c:164)
==4119== by 0x161CB8: main (tor_main.c:32)
==4119== Address 0x5489ec0 is 432 bytes inside a block of size 664 free'd
==4119== at 0x48369AB: free (vg_replace_malloc.c:530)
==4119== by 0x2ADB20: tor_libevent_free_all (compat_libevent.c:490)
==4119== by 0x165FAF: tor_free_all (shutdown.c:160)
==4119== by 0x164B54: tor_run_main (main.c:1360)
==4119== by 0x1620F9: tor_main (tor_api.c:164)
==4119== by 0x161CB8: main (tor_main.c:32)
==4119== Block was alloc'd at
==4119== at 0x483577F: malloc (vg_replace_malloc.c:299)
==4119== by 0x310F47: tor_malloc_ (malloc.c:45)
==4119== by 0x4C1E9B3: event_mm_calloc_ (in /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6.0.2)
==4119== by 0x4C224D9: event_base_new_with_config (in /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6.0.2)
==4119== by 0x2AD284: tor_libevent_initialize (compat_libevent.c:158)
==4119== by 0x28E879: init_libevent (config.c:8031)
==4119== by 0x28E879: options_act_reversible (config.c:1466)
==4119== by 0x28E879: set_options (config.c:934)
==4119== by 0x290721: options_init_from_string (config.c:5529)
==4119== by 0x290CA9: options_init_from_torrc (config.c:5293)
==4119== by 0x1632A6: tor_init (main.c:619)
==4119== by 0x163B13: tor_run_main (main.c:1297)
==4119== by 0x1620F9: tor_main (tor_api.c:164)
==4119== by 0x161CB8: main (tor_main.c:32)
```
maint-0.4.0 does not have this bug, and tor-0.4.1.1-alpha does.
A git bisect brought me to commit 6eb1b8da0ab2, which is about periodic events so it looks promising. It's from #30293.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30620HS DDos on circuits? Can't have access to my hidden service2020-06-13T15:41:43ZTracHS DDos on circuits? Can't have access to my hidden serviceI do run a HS and i am getting attacked by a ddos. It was on layer7, then tcp, and now i think it's currently going in tor.
Tor debugs is been like 3MB weight in less than one second, with that query spammed:
circuit_build_times_add_ti...I do run a HS and i am getting attacked by a ddos. It was on layer7, then tcp, and now i think it's currently going in tor.
Tor debugs is been like 3MB weight in less than one second, with that query spammed:
circuit_build_times_add_time(): Adding circuit build time (random value)
3MB of that.
If i manage to start tor service i get:
May 25 21:21:19.000 [warn] Possible replay detected! An INTRODUCE2 cell with thesame ENCRYPTED section was seen 2 seconds ago. Dropping cell.
May 25 21:21:20.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 126 buildtimes.
May 25 21:21:41.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes.
May 25 21:22:06.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes.
May 25 21:22:33.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes.
May 25 21:23:33.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes.
May 25 21:23:46.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 368 buildtimes.
May 25 21:24:30.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes.
May 25 21:24:37.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 261 buildtimes.
May 25 21:24:45.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 296 buildtimes.
May 25 21:24:49.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 152 buildtimes.
May 25 21:25:17.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 942 buildtimes.
May 25 21:25:22.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 117 buildtimes.
May 25 21:25:29.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 132 buildtimes.
May 25 21:25:34.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 161 buildtimes.
May 25 21:25:40.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 118 buildtimes.
May 25 21:25:45.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 117 buildtimes.
May 25 21:25:50.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 149 buildtimes.
May 25 21:26:05.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 613 buildtimes.
May 25 21:26:12.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 205 buildtimes.
May 25 21:26:17.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 117 buildtimes.
Things like that all the time.
How to get around that?
**Trac**:
**Username**: HSdir123Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30615Factor random_uniform_01 into nondeterministic and deterministic parts, and a...2020-06-13T15:41:42ZriastradhFactor random_uniform_01 into nondeterministic and deterministic parts, and automatically test the deterministic partThe `random_uniform_01` code is not automatically tested by any _deterministic_ tests -- it is tested only by the _stochastic_ tests in the slow test suite. However, there is a not-entirely-trivial deterministic computation inside it, w...The `random_uniform_01` code is not automatically tested by any _deterministic_ tests -- it is tested only by the _stochastic_ tests in the slow test suite. However, there is a not-entirely-trivial deterministic computation inside it, wired up to a (truncated) geometric(1/2) sampler and a uniform bit sampler. And it turns out that this deterministic computation _technically_ has a bug, although the bug triggers with probability <2^-900^ so it doesn't really matter. But it is nice to have deterministic tests for correct behaviour of the deterministic part of a random sampler, and nice for that deterministic part to not have bugs.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30614Use MAP_INHERIT_NONE/ZERO if available instead of crashing on assertion failure2020-06-13T15:41:42ZriastradhUse MAP_INHERIT_NONE/ZERO if available instead of crashing on assertion failureOn NetBSD, the way to ask a page range be zero'd or unmapped on fork is `minherit(addr, nbytes, MAP_INHERIT_ZERO)` or `minherit(addr, nbytes, MAP_INHERIT_NONE)`. However,
- map_anon.c does not actually check for or use `MAP_INHERIT_ZER...On NetBSD, the way to ask a page range be zero'd or unmapped on fork is `minherit(addr, nbytes, MAP_INHERIT_ZERO)` or `minherit(addr, nbytes, MAP_INHERIT_NONE)`. However,
- map_anon.c does not actually check for or use `MAP_INHERIT_ZERO` or `MAP_INHERIT_NONE`, so
- `FLAG_NOINHERIT` is undefined, so
- `tor_mmap_anonymous` fails to disinherit the mapping, so
- `crypto_fast_rng_new_from_seed` throws a fit.
```
slow/prob_distr/stochastic_log_logistic: [forking] May 25 03:56:58.091 [err] tor_assertion_failed_(): Bug: src/lib/crypt_ops/crypto_rand_fast.c:184: crypto_fast_rng_new_from_seed: Assertion inherit != INHERIT_RES_KEEP failed; aborting. (on Tor 0.4.1.1-alpha-dev 29955f13e5bc8e61)
May 25 03:56:58.091 [err] Bug: Assertion inherit != INHERIT_RES_KEEP failed in crypto_fast_rng_new_from_seed at src/lib/crypt_ops/crypto_rand_fast.c:184: . (Stack trace not available) (on Tor 0.4.1.1-alpha-dev 29955f13e5bc8e61)
[Lost connection!]
```
The attached patch checks for and uses `MAP_INHERIT_ZERO` and `MAP_INHERIT_NONE`. **However, it does not adjust the code path that gets confused if `tor_mmap_anonymous` fails to disinherit the mapping,** which might be worth doing too, perhaps earlier on by detecting and noisily reporting a lack of support for cutting off the hereditary concentration of wealth, or at least secrets, in society before it's too late.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30580Tor rejects all POSTDESCRIPTOR controller requests2020-06-13T15:41:38ZteorTor rejects all POSTDESCRIPTOR controller requestsIn #30091, we replaced this code:
```
if (!strcasecmpstart(option, "purpose=")) {
option += strlen("purpose=");
purpose = router_purpose_from_string(option);
if (purpose == ROUTER_PURPOSE_UNKNOWN) {
connecti...In #30091, we replaced this code:
```
if (!strcasecmpstart(option, "purpose=")) {
option += strlen("purpose=");
purpose = router_purpose_from_string(option);
if (purpose == ROUTER_PURPOSE_UNKNOWN) {
connection_printf_to_buf(conn, "552 Unknown purpose \"%s\"\r\n",
option);
goto done;
}
}
```
With this code:
```
line = config_line_find_case(args->kwargs, "purpose");
if (line) {
purpose = router_purpose_from_string(line->value);
connection_printf_to_buf(conn, "552 Unknown purpose \"%s\"\r\n",
line->value);
goto done;
}
```
There's no purpose check any more (`if (purpose == ROUTER_PURPOSE_UNKNOWN) {`), so Tor rejects all POSTDESCRIPTOR requests.
I'm assigning this bug to nickm and cc'ing catalyst, because they were the author and reviewer.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30750Cosmetic looks label alpha dev ico metrics terminal NYX2019-06-05T17:31:39ZTracCosmetic looks label alpha dev ico metrics terminal NYXHello, you can return description label **NEW** in NYX and nice icon lab in metrics relay site or think differently? We running alpha dev relays bridge and hs service and new labels _unrecommended_ in terminal look aren't nice.
Please ...Hello, you can return description label **NEW** in NYX and nice icon lab in metrics relay site or think differently? We running alpha dev relays bridge and hs service and new labels _unrecommended_ in terminal look aren't nice.
Please consider testers and researchers.
It's just a cosmetic looks for NYX and metrics.
Previously was label Tor 0.4.1.1-alpha-dev (NEW)
**Trac**:
**Username**: agnox