Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:04:44Zhttps://gitlab.torproject.org/legacy/trac/-/issues/21035Assertion in 0.2.9.8: monotime_coarse_get2020-06-13T15:04:44ZTracAssertion in 0.2.9.8: monotime_coarse_getDec 20 02:44:06.000 [notice] Tor 0.2.9.8 (git-01ab67e38b358ae9) opening log file.
Dec 20 02:44:06.630 [notice] Tor 0.2.9.8 (git-01ab67e38b358ae9) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
Dec 20 02:44:0...Dec 20 02:44:06.000 [notice] Tor 0.2.9.8 (git-01ab67e38b358ae9) opening log file.
Dec 20 02:44:06.630 [notice] Tor 0.2.9.8 (git-01ab67e38b358ae9) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
Dec 20 02:44:06.630 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 20 02:44:06.630 [notice] Read configuration file "/etc/tor/torrc".
Dec 20 02:44:06.633 [notice] Based on detected system memory, MaxMemInQueues is set to 6144 MB. You can override this by setting MaxMemInQueues by hand.
Dec 20 02:44:06.634 [notice] Opening Socks listener on 127.0.0.1:9050
Dec 20 02:44:06.634 [notice] Opening OR listener on 46.29.248.238:443
Dec 20 02:44:06.634 [notice] Opening Directory listener on 46.29.248.238:80
Dec 20 02:44:06.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Dec 20 02:44:06.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Dec 20 02:44:06.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Dec 20 02:44:06.000 [err] tor_assertion_failed_(): Bug: src/common/compat_time.c:359: monotime_coarse_get: Assertion r == 0 failed; aborting. (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: Assertion r == 0 failed in monotime_coarse_get at src/common/compat_time.c:359. Stack trace: (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(log_backtrace+0x42) [0x2b9dce1a5222] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0xa3) [0x2b9dce1bd6d3] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(monotime_coarse_get+0x59) [0x2b9dce1a9e59] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(tor_main+0x86) [0x2b9dce099d46] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(main+0x19) [0x2b9dce096b19] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xfd) [0x2b9dcf1e6d1d] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(+0xada29) [0x2b9dce096a29] (on Tor 0.2.9.8 01ab67e38b358ae9)
---------------------------
Environment: CentOS v6.8, OpenVZ virtualization, confirmed system time is accurate. No problem seen in same environment with Tor v0.2.8.11.
**Trac**:
**Username**: tmpname0901Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21031Please don't remove ClientDNSRejectInternalAddresses2020-06-13T15:08:11ZSebastian HahnPlease don't remove ClientDNSRejectInternalAddressesI have a private tor network that lives in 10.0.0.0/8, and removing this option would make that network unusable.I have a private tor network that lives in 10.0.0.0/8, and removing this option would make that network unusable.Tor: 0.3.2.x-finalSebastian HahnSebastian Hahnhttps://gitlab.torproject.org/legacy/trac/-/issues/20974Call no directory guard happy until its directory headers are received2020-06-13T15:04:24ZNick MathewsonCall no directory guard happy until its directory headers are receivedIn my prop271 code as it is, we call entry_guard_succeeded() from connection_dir_process_inbuf(). But apparently that can get called without data actually having been read. We should instead call the guard successful only when we get g...In my prop271 code as it is, we call entry_guard_succeeded() from connection_dir_process_inbuf(). But apparently that can get called without data actually having been read. We should instead call the guard successful only when we get good-looking headers from it.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20960Extend sybil-detection to authorities as well2020-06-13T15:04:20ZNick MathewsonExtend sybil-detection to authorities as wellIn get_possible_sybil_list(), we exempt addresses shared with directory authorities from sybil detection. This served a purpose long ago, when Roger had to run extra relays on the moria host all the time (for debugging purposes), but I ...In get_possible_sybil_list(), we exempt addresses shared with directory authorities from sybil detection. This served a purpose long ago, when Roger had to run extra relays on the moria host all the time (for debugging purposes), but I hope we're past those days.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20921Refactor global_origin_circuit_list code into separate functions.2020-06-13T15:04:11ZNick MathewsonRefactor global_origin_circuit_list code into separate functions.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20862Unittest fail on master: FAIL src/test/test_options.c:662: expected log to co...2020-06-13T15:03:54ZGeorge KadianakisUnittest fail on master: FAIL src/test/test_options.c:662: expected log to contain "Could not resolve local Address "On latest master (e6facbfe7abc50de374300ecd83873ead65b4b04) the following test fail occurs:
```
options/validate__authdir: [forking]
FAIL src/test/test_options.c:662: expected log to contain "Could not resolve local Address " "'this....On latest master (e6facbfe7abc50de374300ecd83873ead65b4b04) the following test fail occurs:
```
options/validate__authdir: [forking]
FAIL src/test/test_options.c:662: expected log to contain "Could not resolve local Address " "'this.should.not_exist.example.org'. Failing.\n" Captured logs:
1. warn: "Address \'this.should.not_exist.example.org\' resolves to private IP address \'172.19.52.3\'. Tor servers that use the default DirAuthorities must have public IP addresses.\n"
[validate__authdir FAILED]
```Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20826Restrict GUARDS set to EntryNodes when the set of guards is restrictive2020-06-13T15:03:44ZNick MathewsonRestrict GUARDS set to EntryNodes when the set of guards is restrictiveIn proposal 271, I suggested that when EntryNodes is a very restrictive set, we should use it, rather than GUARDS, to build our sample.
We already support having a separate guard selection here in the new guard code (see #19888), but we...In proposal 271, I suggested that when EntryNodes is a very restrictive set, we should use it, rather than GUARDS, to build our sample.
We already support having a separate guard selection here in the new guard code (see #19888), but we don't restrict the GUARDS input set in the way I had suggested yet.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://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 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/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/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/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/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/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/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/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/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/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/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/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 Mathewson