Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:39:00Zhttps://gitlab.torproject.org/legacy/trac/-/issues/13221Misleading error messages about bind_ipv4_only and bind_ipv6_only?2020-06-13T14:39:00ZRoger DingledineMisleading error messages about bind_ipv4_only and bind_ipv6_only?```
if (bind_ipv4_only && tor_addr_family(&addr) == AF_INET6) {
log_warn(LD_CONFIG, "Could not interpret %sPort address as IPv6",
portname);
goto err;
}
```
Is this warn mixed up? Same with t...```
if (bind_ipv4_only && tor_addr_family(&addr) == AF_INET6) {
log_warn(LD_CONFIG, "Could not interpret %sPort address as IPv6",
portname);
goto err;
}
```
Is this warn mixed up? Same with the one below it.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18357HiddenServicePort IPv6 broken2020-06-13T14:54:36ZTracHiddenServicePort IPv6 brokenHi,
In reference to: #6551 and #12670.
I was not having much luck setting up a Hidden Service. I found later that worked when I used 127.0.0.1:80 instead of [::1]:80.
I then tested v6 and v4, side-by-side:
HiddenServicePort 80 127.0.0...Hi,
In reference to: #6551 and #12670.
I was not having much luck setting up a Hidden Service. I found later that worked when I used 127.0.0.1:80 instead of [::1]:80.
I then tested v6 and v4, side-by-side:
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 81 [::1]:80
Port 80 worked, 81 did not. I checked a few times with curl locally and with tor browser.
I'm running FreeBSD 10.2. Had a pretty slim configuration when I tried this. Verified with fetch and sockstat that indeed the service was listening on ::1 (::0/0, actually).
Thank you,
Teran
**Trac**:
**Username**: sega01Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/18982Tor should log 1-based hop numbers2020-06-13T14:57:04ZteorTor should log 1-based hop numbersThe control-spec says hops are 1-based, and we often log "first hop":
```
If HOP=HopNum is specified, Tor will choose the HopNumth hop in the
circuit as the exit node, rather than the last node in the circuit.
Hops are 1-indexed; g...The control-spec says hops are 1-based, and we often log "first hop":
```
If HOP=HopNum is specified, Tor will choose the HopNumth hop in the
circuit as the exit node, rather than the last node in the circuit.
Hops are 1-indexed; generally, it is not permitted to attach to hop 1.
```
But the following functions log 0-based hops:
* choose_good_middle_server
* onion_extend_cpath (which also logs a 1-based hop message as well)
We need to add 1 to the 0-based hop counts in these functions.
Credit to Xiaofan Li for discovering this issue.Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/19079clang -m32 -ftrapv seems buggy with 64-bit signed integer multiply2020-06-13T14:57:32ZNick Mathewsonclang -m32 -ftrapv seems buggy with 64-bit signed integer multiplyIf you try building with clang -m32 -ftrapv, you get a bunch of these warnings:
```
12:39:59 /home/jenkins/workspace/tor-ci-linux-master-clang/ARCHITECTURE/i386/SUITE/sid/src/or/dirvote.c:828: undefined reference to `__mulodi4'
12:39:59 ...If you try building with clang -m32 -ftrapv, you get a bunch of these warnings:
```
12:39:59 /home/jenkins/workspace/tor-ci-linux-master-clang/ARCHITECTURE/i386/SUITE/sid/src/or/dirvote.c:828: undefined reference to `__mulodi4'
12:39:59 /home/jenkins/workspace/tor-ci-linux-master-clang/ARCHITECTURE/i386/SUITE/sid/src/or/dirvote.c:828: undefined reference to `__mulodi4'
12:39:59 /home/jenkins/workspace/tor-ci-linux-master-clang/ARCHITECTURE/i386/SUITE/sid/src/or/dirvote.c:855: undefined reference to `__mulodi4'
12:39:59 /home/jenkins/workspace/tor-ci-linux-master-clang/ARCHITECTURE/i386/SUITE/sid/src/or/dirvote.c:930: undefined reference to `__mulodi4'
12:39:59 /home/jenkins/workspace/tor-ci-linux-master-clang/ARCHITECTURE/i386/SUITE/sid/src/or/dirvote.c:930: undefined reference to `__mulodi4'
12:39:59 src/or/libtor-testing.a(src_or_libtor_testing_a-dirvote.o):/home/jenkins/workspace/tor-ci-linux-master-clang/ARCHITECTURE/i386/SUITE/sid/src/or/dirvote.c:834: more undefined references to `__mulodi4' follow
```
Since -ftrapv is now on by default, that's a problem!
Others have seen errors like this before; for example see:
https://bugs.chromium.org/p/chromium/issues/detail?id=503229
and
https://llvm.org/bugs/show_bug.cgi?id=14469
I'm calling this must-fix-for-029, since otherwise we just broke 32-bit clang.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19203node_get_by_nickname() fails to give warning on unique-but-unnamed node.2020-06-13T14:58:04ZNick Mathewsonnode_get_by_nickname() fails to give warning on unique-but-unnamed node.There are two checks in node_get_by_nickname for listing an unnamed router by name. One checks for `(smartlist_len(matches)>1 && warn_if_unnamed)`, whereas the other one also checks for `(smartlist_len(matches)>1 && warn_if_unnamed)`. ...There are two checks in node_get_by_nickname for listing an unnamed router by name. One checks for `(smartlist_len(matches)>1 && warn_if_unnamed)`, whereas the other one also checks for `(smartlist_len(matches)>1 && warn_if_unnamed)`. Whoops.
The impact is that if there is one match, no warning will be produced, even though it arguably should (now that Naming is no longer a thing).
Found by GCC6 with -Wduplicated-cond as part of #19180.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19296Have tor-guts cover time-related util functions2020-06-13T14:58:18ZNick MathewsonHave tor-guts cover time-related util functionsTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19298Have tor-guts describe containers2020-06-13T14:58:19ZNick MathewsonHave tor-guts describe containersTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19299Document memory-related parts of src/common in tor-guts2020-06-13T14:58:20ZNick MathewsonDocument memory-related parts of src/common in tor-gutsTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19361Improve coverage on compat_*threads and workqueue2020-06-13T14:58:35ZNick MathewsonImprove coverage on compat_*threads and workqueueSee my branch `thread_coverage`. It solves some but not all of #16798See my branch `thread_coverage`. It solves some but not all of #16798Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19578Incorrect log message on mismatch ownership in check_private_dir2020-06-13T14:59:20ZNick MathewsonIncorrect log message on mismatch ownership in check_private_dirour variable shadowing in check_private_dir results in an incorrect log message.our variable shadowing in check_private_dir results in an incorrect log message.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19896Write a quick how-to for ht.h2020-06-13T15:00:10ZNick MathewsonWrite a quick how-to for ht.hGeorge wanted some tips about using ht.h. But he's not around IRC. I'll braindump here instead.George wanted some tips about using ht.h. But he's not around IRC. I'll braindump here instead.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20001Infer running and valid from presence in consensus2020-06-13T15:00:45ZNick MathewsonInfer running and valid from presence in consensusWe no longer include in the consensus any non-running nodes.
We are no longer _supposed_ to include in the consensus any non-Valid nodes.
Let us update Tor to infer these flags as true from their presence in the consensus. This could ...We no longer include in the consensus any non-running nodes.
We are no longer _supposed_ to include in the consensus any non-Valid nodes.
Let us update Tor to infer these flags as true from their presence in the consensus. This could work with prop#266 as another means to kill off obsolete clients.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20002Never include non-Valid nodes in consensus.2020-06-13T15:00:45ZNick MathewsonNever include non-Valid nodes in consensus.Right now, we don't include non-Running nodes. Let's make it so we never include non-Valid nodes either.Right now, we don't include non-Running nodes. Let's make it so we never include non-Valid nodes either.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20081potential memory corruption in or/buffers.c (not exploitable)2020-06-13T15:01:11ZGeorge Kadianakispotential memory corruption in or/buffers.c (not exploitable)Bug reported by _Guido Vranken_ through hackerone.
We believe it's not an exploitable issue, but it's still a bug worth fixing.
Here follows the report:
----
In `or/buffer.s.c`:
```
/** Return the allocation size we'd like to use to ...Bug reported by _Guido Vranken_ through hackerone.
We believe it's not an exploitable issue, but it's still a bug worth fixing.
Here follows the report:
----
In `or/buffer.s.c`:
```
/** Return the allocation size we'd like to use to hold <b>target</b>
* bytes. */
static inline size_t
preferred_chunk_size(size_t target)
{
size_t sz = MIN_CHUNK_ALLOC;
while (CHUNK_SIZE_WITH_ALLOC(sz) < target) {
sz <<= 1;
}
return sz;
}
```
```
#define MIN_CHUNK_ALLOC 256
#define CHUNK_SIZE_WITH_ALLOC(memlen) ((memlen) - CHUNK_HEADER_LEN)
```
CHUNK_HEADER_LEN is usually around 30 bytes or so.
The problem with `preferred_chunk_size` is that for a large `size_t target`, the function will return 0.
If you compile this program with `-m32`:
```
#include <stdio.h>
#include <stdint.h>
#define FLEXIBLE_ARRAY_MEMBER /**/
#define DEBUG_CHUNK_ALLOC
/** A single chunk on a buffer. */
typedef struct chunk_t {
struct chunk_t *next; /**< The next chunk on the buffer. */
size_t datalen; /**< The number of bytes stored in this chunk */
size_t memlen; /**< The number of usable bytes of storage in <b>mem</b>. */
#ifdef DEBUG_CHUNK_ALLOC
size_t DBG_alloc;
#endif
char *data; /**< A pointer to the first byte of data stored in <b>mem</b>. */
uint32_t inserted_time; /**< Timestamp in truncated ms since epoch
* when this chunk was inserted. */
char mem[FLEXIBLE_ARRAY_MEMBER]; /**< The actual memory used for storage in
* this chunk. */
} chunk_t;
#if defined(__GNUC__) && __GNUC__ > 3
#define STRUCT_OFFSET(tp, member) __builtin_offsetof(tp, member)
#else
#define STRUCT_OFFSET(tp, member) \
((off_t) (((char*)&((tp*)0)->member)-(char*)0))
#endif
#define MIN_CHUNK_ALLOC 256
#define CHUNK_HEADER_LEN STRUCT_OFFSET(chunk_t, mem[0])
#define CHUNK_SIZE_WITH_ALLOC(memlen) ((memlen) - CHUNK_HEADER_LEN)
static inline size_t
preferred_chunk_size(size_t target)
{
size_t sz = MIN_CHUNK_ALLOC;
while (CHUNK_SIZE_WITH_ALLOC(sz) < target) {
sz <<= 1;
}
return sz;
}
int main(void)
{
size_t i = 1024;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
printf("i is %08X, preferred_chunk_size is %08X\n", i, preferred_chunk_size(i)); i <<= 1;
return 0;
}
```
the output is:
```
i is 00000400, preferred_chunk_size is 00000800
i is 00000800, preferred_chunk_size is 00001000
i is 00001000, preferred_chunk_size is 00002000
i is 00002000, preferred_chunk_size is 00004000
i is 00004000, preferred_chunk_size is 00008000
i is 00008000, preferred_chunk_size is 00010000
i is 00010000, preferred_chunk_size is 00020000
i is 00020000, preferred_chunk_size is 00040000
i is 00040000, preferred_chunk_size is 00080000
i is 00080000, preferred_chunk_size is 00100000
i is 00100000, preferred_chunk_size is 00200000
i is 00200000, preferred_chunk_size is 00400000
i is 00400000, preferred_chunk_size is 00800000
i is 00800000, preferred_chunk_size is 01000000
i is 01000000, preferred_chunk_size is 02000000
i is 02000000, preferred_chunk_size is 04000000
i is 04000000, preferred_chunk_size is 08000000
i is 08000000, preferred_chunk_size is 10000000
i is 10000000, preferred_chunk_size is 20000000
i is 20000000, preferred_chunk_size is 40000000
i is 40000000, preferred_chunk_size is 80000000
i is 80000000, preferred_chunk_size is 00000000
```
The danger is that the return value of `preferred_chunk_size` is always used as a parameter to `tor_malloc` or `tor_realloc`. It is called at these places:
In `buf_pullup`:
```
210 newsize = CHUNK_SIZE_WITH_ALLOC(preferred_chunk_size(capacity));
211 newhead = chunk_grow(buf->head, newsize);
```
In `buf_new_with_capacity`:
```
283 /** Create and return a new buf with default chunk capacity <b>size</b>.
284 */
285 buf_t *
286 buf_new_with_capacity(size_t size)
287 {
288 buf_t *b = buf_new();
289 b->default_chunk_size = preferred_chunk_size(size);
290 return b;
291 }
```
In `buf_add_chunk_with_capacity`:
```
401 /** Append a new chunk with enough capacity to hold <b>capacity</b> bytes to
402 * the tail of <b>buf</b>. If <b>capped</b>, don't allocate a chunk bigger
403 * than MAX_CHUNK_ALLOC. */
404 static chunk_t *
405 buf_add_chunk_with_capacity(buf_t *buf, size_t capacity, int capped)
406 {
407 chunk_t *chunk;
408
409 if (CHUNK_ALLOC_SIZE(capacity) < buf->default_chunk_size) {
410 chunk = chunk_new_with_alloc_size(buf->default_chunk_size);
411 } else if (capped && CHUNK_ALLOC_SIZE(capacity) > MAX_CHUNK_ALLOC) {
412 chunk = chunk_new_with_alloc_size(MAX_CHUNK_ALLOC);
413 } else {
414 chunk = chunk_new_with_alloc_size(preferred_chunk_size(capacity));
415 }
```
`buf_new_with_capacity` is currently called nowhere except for tests.
`buf_add_chunk_with_capacity` is called at various places but currently not with the `apped` parameter set to 0.
However, `buf_pullup` is called at various places and the call to `preferred_chunk_size` is reachable. Whether it is reachable with a parameter large enough that it will return 0 I'm not sure about.
```
int
tor_main(int argc, char *argv[])
{
buf_t* buf;
char* string;
size_t string_len;
size_t i;
buf = buf_new();
string_len = 0x00001000;
string = tor_malloc(string_len);
for (i = 0; i < 507904; i++)
{
write_to_buf(string, string_len, buf);
}
write_to_buf(string, 0x3FFFFFA, buf);
free(string);
buf_pullup(buf, 0x90000000);
}
```
What will happen is that `buf_pullup` will call `hunk_grow`
```
140 static inline chunk_t *
141 chunk_grow(chunk_t *chunk, size_t sz)
142 {
143 off_t offset;
144 size_t memlen_orig = chunk->memlen;
145 tor_assert(sz > chunk->memlen);
146 offset = chunk->data - chunk->mem;
147 chunk = tor_realloc(chunk, CHUNK_ALLOC_SIZE(sz));
148 chunk->memlen = sz;
149 chunk->data = chunk->mem + offset;
```
`tor_realloc` will in effect be called with a size parameter of 0. Whether and how much legitimate heap memory `realloc` will allocate might be implementation-dependent. The point is that the
following lines might overwrite heap memory:
```
148 chunk->memlen = sz;
149 chunk->data = chunk->mem + offset;
```
since `hunk` is a memory area that has just been allocated to 0 (or 1, after correction) bytes.
The whole scenario is not very likely considering Tor's frugal memory consumption but it is nonetheless a programming fault in the buffers "API" that could lead to stability issues. Especially if you ever
expand the use of `buf_pullup`, `buf_new_with_capacity`, and/or uncapped `buf_add_chunk_with_capacity`, it'll be wise to hard-limit the amounts of right-shifts in `preferred_chunk_size` (a
single unintended negative integer -> size_t can be conducive in establishing an exploitation path).Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20168Clarify our #if{n}def by commenting what they are at the #elif/#else/#endif2020-06-13T15:01:33ZDavid Gouletdgoulet@torproject.orgClarify our #if{n}def by commenting what they are at the #elif/#else/#endifOk that's an easy one!
The idea is to improve our comments in the .h/.c files where we have a `#ifdef BLAH` and the corresponding `#endif` is at least a non negligible amount of lines after. Of course that goes without saying to also co...Ok that's an easy one!
The idea is to improve our comments in the .h/.c files where we have a `#ifdef BLAH` and the corresponding `#endif` is at least a non negligible amount of lines after. Of course that goes without saying to also comment the `#ifndef`. Pattern would look like this:
```
#ifdef BLAH
[some non negligible amount of lines]
#elif /* BLAH */
[some other amount of lines]
#endif /* BLAH */
```
According to nickm, the current situation is:
Our headers have 27 #endifs with a comment, and 435 without.
Good example is `or.h`:
```
#ifndef TOR_OR_H
[5000+ lines in between]
#endif /* TOR_OR_H */
```
This file `src/or/shared_random.h` is a good example of what it could look like.Tor: 0.3.2.x-finalcjbcjbhttps://gitlab.torproject.org/legacy/trac/-/issues/20241Fix compilation on osx sierra (10.12)2020-06-13T15:01:44ZNick MathewsonFix compilation on osx sierra (10.12)OSX Sierra (which came out last week) broke compilation in two ways:
* It added a getentropy() function, but only if you include sys/random.h (which nobody else seems to require).
* It added clock_gettime(), but uses a wider type ...OSX Sierra (which came out last week) broke compilation in two ways:
* It added a getentropy() function, but only if you include sys/random.h (which nobody else seems to require).
* It added clock_gettime(), but uses a wider type for tv_nsec than tv_usec (why? Where does apple run that provides an "int" that holds up to 1e6, but where you need a "long" to hold 1e9??).
* It added clock_gettime(), but didn't add pthread_condattr_setclock() (whereas everybody else supports neither or both).
My branch `osx_sierra_028` fixes both. I'm going to merge it to master as low-risk so I can keep doing development, and ask for review on getting it into 028.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20266Provide a shim for SSL_cipher_get_id in OpenSSL versions < 1.0.12020-06-13T15:01:49ZteorProvide a shim for SSL_cipher_get_id in OpenSSL versions < 1.0.1Tor fails to compile on OpenSSL 1.0.0, because we use SSL_cipher_get_id, which was introduced in OpenSSL 1.0.1.
We can access the id member of the cipher object instead, like this:
https://github.com/SlimRoms/android_external_chromium/c...Tor fails to compile on OpenSSL 1.0.0, because we use SSL_cipher_get_id, which was introduced in OpenSSL 1.0.1.
We can access the id member of the cipher object instead, like this:
https://github.com/SlimRoms/android_external_chromium/commit/731158395b8ae1105c69cc42dae6244385f6b4ffTor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20270"Descriptor is missing an ntor curve25519 onion key" message too noisy?2020-06-13T15:01:51ZRoger Dingledine"Descriptor is missing an ntor curve25519 onion key" message too noisy?On moria1, I have a lot of these:
```
Oct 01 18:01:05.421 [notice] Descriptor from router $E0671CF9CB593F27CD389CD4DD819BF9448EA834~ordb1 at 37.59.47.27 is missing an ntor curve25519 onion key.
Oct 01 18:01:20.530 [notice] Descriptor fro...On moria1, I have a lot of these:
```
Oct 01 18:01:05.421 [notice] Descriptor from router $E0671CF9CB593F27CD389CD4DD819BF9448EA834~ordb1 at 37.59.47.27 is missing an ntor curve25519 onion key.
Oct 01 18:01:20.530 [notice] Descriptor from router $179B10784BF8955C73313CCB195904AE133E5F53~ordb3 at 37.59.47.27 is missing an ntor curve25519 onion key.
Oct 01 18:03:21.653 [notice] Descriptor from router $993992BBD01E36D3ECF8BA0B802C158961BB257C~orchard at 106.186.18.242 is missing an ntor curve25519 onion key.
Oct 01 18:04:00.856 [notice] Descriptor from router $496FED39C1469567B333C3A418A07D5CF62DCD23~rationalist at 87.106.249.248 is missing an ntor curve25519 onion key.
Oct 01 18:14:14.418 [notice] Descriptor from router $184A39F7F891D46592216643CD74DDE50C6DAA75~FlandersRegional at 89.106.244.21 is missing an ntor curve25519 onion key.
Oct 01 18:15:16.620 [notice] Descriptor from router $1AFA214C8AE557640BD29A0A8D674F92EB20948D~Unnamdddd at 95.78.221.81 is missing an ntor curve25519 onion key.
Oct 01 18:23:29.590 [notice] Descriptor from router $40E632BED95FC71E5B622DBB9E336D89A6D52600~younix at 85.214.63.239 is missing an ntor curve25519 onion key.
```
teor thinks this wasn't really meant to be a notice-level log every time an obsolete relay tries to upload to me.
That said, I think the first two of these relays (ordb1 and ordb3) are actually that alternative nodejs Tor relay implementation, right?
So I think maybe I *do* want to hear about relays that I refused due to lack of an ntor curve onion key, but only the ones that had a satisfactory version string?Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20536Should tor keep on retrying, even if it has reached the failure limit?2020-06-13T15:02:49ZteorShould tor keep on retrying, even if it has reached the failure limit?In #20499, when relays reach the download failure limit, they stop downloading consensuses.
I think this behaviour is desirable for relays that will never get a good consensus (if they are too old, for example).
But for relays that hav...In #20499, when relays reach the download failure limit, they stop downloading consensuses.
I think this behaviour is desirable for relays that will never get a good consensus (if they are too old, for example).
But for relays that have a temporary issue, it is really unhelpful.
Perhaps tor should retry every few days no matter what?Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20824[prop271, controller] DROPGUARDS support for new guard backend2020-06-13T15:03:43ZNick Mathewson[prop271, controller] DROPGUARDS support for new guard backendOur new guard backend doesn't support DROPGUARDS. Personally, I think DROPGUARDS is a bad idea, and we ought to provide a method way for users who don't want their guards to follow them around. But we should keep this one working at leas...Our new guard backend doesn't support DROPGUARDS. Personally, I think DROPGUARDS is a bad idea, and we ought to provide a method way for users who don't want their guards to follow them around. But we should keep this one working at least until there's a better option.Tor: 0.3.0.x-finalNick MathewsonNick Mathewson