Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-09-16T14:30:21Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26525Rename sandbox_getaddrinfo() functions.2021-09-16T14:30:21ZNick MathewsonRename sandbox_getaddrinfo() functions.From my branch for legacy/trac#26524:
```
+// XXXX rename these. They are named as though they were sandbox-only,
+// XXXX but in fact they're the only allowed entry point to getaddrinfo.
+// XXXX They don't invoke the sandbox code; the...From my branch for legacy/trac#26524:
```
+// XXXX rename these. They are named as though they were sandbox-only,
+// XXXX but in fact they're the only allowed entry point to getaddrinfo.
+// XXXX They don't invoke the sandbox code; they only have an internal cache.
```
These functions should be called something like tor_getaddrinfo...(), or tor_getaddrinfo_cache...()Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/26524Extract network utilities into a new library2021-09-16T14:30:20ZNick MathewsonExtract network utilities into a new libraryTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26510Make "bloomfilter set" code first-class2021-09-16T14:30:20ZNick MathewsonMake "bloomfilter set" code first-classOur bloom filter duplicated between address_set.c and digestset.c, and it's slightly different in both cases. We should extract a common implementation type, use siphash, and name it bloomfilt_set or approx_set or somethign.Our bloom filter duplicated between address_set.c and digestset.c, and it's slightly different in both cases. We should extract a common implementation type, use siphash, and name it bloomfilt_set or approx_set or somethign.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26494Resolve containers<->logs circular dependency2021-09-16T14:30:20ZNick MathewsonResolve containers<->logs circular dependencyRight now, libtor-logs and libtor-containers each use functions from one another. That should not stand. My preferred solution is to divide a smartlist-core from the rest of containers.Right now, libtor-logs and libtor-containers each use functions from one another. That should not stand. My preferred solution is to divide a smartlist-core from the rest of containers.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26446Split out the easier libraries from lib/common2021-09-16T14:30:20ZNick MathewsonSplit out the easier libraries from lib/commonNow that I've made a start (see legacy/trac#26442) it's time to split the rest of the common directory.
Some of the splitting will require disentangling individual files, but some is fairly easy. I'll do the easy part first.Now that I've made a start (see legacy/trac#26442) it's time to split the rest of the common directory.
Some of the splitting will require disentangling individual files, but some is fairly easy. I'll do the easy part first.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26442Start extracting libraries from src/common2021-09-16T14:30:20ZNick MathewsonStart extracting libraries from src/commonI want to disentangle the call graph and code organization, and the place to start seems like src/common.
I want to do an exploratory branch here before I dive in completely.I want to disentangle the call graph and code organization, and the place to start seems like src/common.
I want to do an exploratory branch here before I dive in completely.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26427Remove circularity surrounding functions called by tor_logv()2021-09-16T14:30:20ZNick MathewsonRemove circularity surrounding functions called by tor_logv()These functions should not be allowed to log failure fail when tor_logv calls them, because tor_logv is required for logging.
This will help us untangle some call cycles at the bottom of our callgraph, and thereby help with our library ...These functions should not be allowed to log failure fail when tor_logv calls them, because tor_logv is required for logging.
This will help us untangle some call cycles at the bottom of our callgraph, and thereby help with our library refactoringTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26426Remove dmalloc support2021-09-16T14:30:20ZNick MathewsonRemove dmalloc supportDmalloc hasn't had a new release since 2007, and I haven't seen anybody run it in ages. It's been superseded by stuff like gperftools and asan.Dmalloc hasn't had a new release since 2007, and I haven't seen anybody run it in ages. It's been superseded by stuff like gperftools and asan.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26270Move dirauth module code from src/or/dirauth to src/dirauth2021-09-16T14:30:20ZAlexander Færøyahf@torproject.orgMove dirauth module code from src/or/dirauth to src/dirauthDuring the modularization discussion at the network team Seattle hackfest we decided to move the dirauth module code from src/or/dirauth to src/dirauth.During the modularization discussion at the network team Seattle hackfest we decided to move the dirauth module code from src/or/dirauth to src/dirauth.Tor: 0.3.5.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/26142replace uses of U64_* and I64_* macros with their C99 stdint.h or inttypes.h ...2021-09-16T14:30:20ZTaylor Yureplace uses of U64_* and I64_* macros with their C99 stdint.h or inttypes.h equivalentsThere are many macros in compat.h that try to portably handle 64-bit integer values in `printf()` and `scanf()` calls. Now that we seem to require C99, we should use the equivalent macros from stdint.h or inttypes.h instead. For exampl...There are many macros in compat.h that try to portably handle 64-bit integer values in `printf()` and `scanf()` calls. Now that we seem to require C99, we should use the equivalent macros from stdint.h or inttypes.h instead. For example, `U64_FORMAT` is equivalent to `PRIu64` in inttypes.h.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26626Require stdint and inttypes; remove most (but not all) of torint.h; use stand...2021-09-16T14:29:03ZNick MathewsonRequire stdint and inttypes; remove most (but not all) of torint.h; use standard PRIuXX macrosWe've been requiring stdint.h for a while now -- trunnel headers all use it, and so does some of the hs_*.c code.
Let's assume that we have the standard c99 headers, and use their definitions of the stuff that they define. It isn't 200...We've been requiring stdint.h for a while now -- trunnel headers all use it, and so does some of the hs_*.c code.
Let's assume that we have the standard c99 headers, and use their definitions of the stuff that they define. It isn't 2003 any more :)Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26593Split even more things out of or.h2021-09-16T14:29:03ZNick MathewsonSplit even more things out of or.hTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26572Remove src/common/compat.[ch and src/common/util.c: Make util.h a stub2021-09-16T14:29:02ZNick MathewsonRemove src/common/compat.[ch and src/common/util.c: Make util.h a stubSee branch `remove_util_and_compat`. PR at https://github.com/torproject/tor/pull/193See branch `remove_util_and_compat`. PR at https://github.com/torproject/tor/pull/193Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26564Tor compilation fails when cross-compiling for macOS2021-09-16T14:29:02ZGeorg KoppenTor compilation fails when cross-compiling for macOSOur latest nightly build is failing when (cross)-compiling `tor` for macOS:
```
CC src/lib/process/env.o
src/lib/process/env.c:40:11: warning: implicit declaration of function '_NSGetEnviron' is invalid in C99 [-Wimplicit-functio...Our latest nightly build is failing when (cross)-compiling `tor` for macOS:
```
CC src/lib/process/env.o
src/lib/process/env.c:40:11: warning: implicit declaration of function '_NSGetEnviron' is invalid in C99 [-Wimplicit-function-declaration]
return *_NSGetEnviron();
^
src/lib/process/env.c:40:10: error: indirection requires pointer operand ('int' invalid)
return *_NSGetEnviron();
^~~~~~~~~~~~~~~~
1 warning and 1 error generated.
Makefile:7498: recipe for target 'src/lib/process/env.o' failed
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26558Remove nearly all of src/common/util.h and src/common/compat.h2021-09-16T14:29:02ZNick MathewsonRemove nearly all of src/common/util.h and src/common/compat.hI'll be honest here: When I started on this branch, its name was `freestyle_refactor`I'll be honest here: When I started on this branch, its name was `freestyle_refactor`Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26538Extract various string, encoding, and formatting logic from config2021-09-16T14:29:02ZNick MathewsonExtract various string, encoding, and formatting logic from configSee branch `format_refactor`, with PR at https://github.com/torproject/tor/pull/190See branch `format_refactor`, with PR at https://github.com/torproject/tor/pull/190Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26534Split file-access and filesystem-access stuff into its own library2021-09-16T14:29:02ZNick MathewsonSplit file-access and filesystem-access stuff into its own libraryOkay, this branch is `fs_refactor`.
It's based on my sandbox_refactor branch (see legacy/trac#26533) , so I made a PR at https://github.com/nmathewson/tor/pull/1 if you only want to see the changes since that branch.Okay, this branch is `fs_refactor`.
It's based on my sandbox_refactor branch (see legacy/trac#26533) , so I made a PR at https://github.com/nmathewson/tor/pull/1 if you only want to see the changes since that branch.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26533Extract sandbox module into its own library2021-09-16T14:29:02ZNick MathewsonExtract sandbox module into its own librarySee branch `sandbox_refactor` , with PR at https://github.com/torproject/tor/pull/188See branch `sandbox_refactor` , with PR at https://github.com/torproject/tor/pull/188Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27892Split the non-stats part of the stats module into different modules2021-09-16T14:28:09ZNick MathewsonSplit the non-stats part of the stats module into different modulesPart of rephist.c is about predicted ports, which aren't really stats.
Part of geoip.c is about stats, but part is about mapping IPs to countries, which isn't stats.
Let's fix this while we can.Part of rephist.c is about predicted ports, which aren't really stats.
Part of geoip.c is about stats, but part is about mapping IPs to countries, which isn't stats.
Let's fix this while we can.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27864Split router.c and routerkeys.c into separate modules2021-09-16T14:28:09ZNick MathewsonSplit router.c and routerkeys.c into separate modulesTor: 0.3.5.x-finalNick MathewsonNick Mathewson