With the things you mention, the promotion is more simply because they were bumped into first. Really, there's nothing bad about anything at all. Nothing is bad! Strange, huh? We were, actually, looking at the ABCs of Tor, or what do you mean? I forgot where in the tor source code I was. I guess I'll look around a little. I like how tor puts its `.h` files in the same folder as its `.c` files. That really helps me find what I'm looking for when my short term memory is spazzing out. It's harder when they're in different directories, somehow. ``` $ grep -r tor_run_main\( . ./app/main/main.c:tor_run_main(const tor_main_configuration_t *tor_cfg) ... $ less app/main/main.c ``` Again, tor_run_main is down at the bottom, but it's longer so you'll likely have to arrow up a little to see its header. ``` * Main entry point for the Tor process. Called from tor_main(), and by * anybody embedding Tor. */ ``` Isn't that a cool idea, embedding Tor? I wonder if they imagined something like the tor browser bundle when they made that feature. TBB doesn't embed Tor; it runs a subprocess. ``` int tor_run_main(const tor_main_configuration_t *tor_cfg) { ``` What a happy function signature =) Like the others we've looked at, this returns an `int`, which is the exit code to be passed back to the operating system. But here they've made all the options more meaningful than the `argc` and `argv` we saw back a ways, by placing them in a tor_main_configuration_t object. ``` int result = 0; #ifdef EVENT_SET_MEM_FUNCTIONS_IMPLEMENTED event_set_mem_functions(tor_malloc_, tor_realloc_, tor_free_); #endif ``` Looks like tor uses specific memory allocators. This is usually for tracking memory leaks and other frustrating errors that can often be used to take over your system if you make a habit of causing them. The fact that these functions are here shows the developers likely had that habit. It takes a lot of diligence to avoid. ``` subsystems_init(); ``` Cool! subsystems! This sounds fun to review. ``` init_protocol_warning_severity_level(); int argc = tor_cfg->argc + tor_cfg->argc_owned; char **argv = tor_calloc(argc, sizeof(char*)); memcpy(argv, tor_cfg->argv, tor_cfg->argc*sizeof(char*)); if (tor_cfg->argc_owned) memcpy(argv + tor_cfg->argc, tor_cfg->argv_owned, tor_cfg->argc_owned*sizeof(char*)); int done = 0; result = nt_service_parse_options(argc, argv, &done); if (POSSIBLE(done)) goto done; ``` This above chunk looks like just boilerplate setup and can basically be ignored. ``` pubsub_install(); ``` Cool! setting up a publish/subscribe process! Sounds interested to review to. What do we have on the queue to review now? `subsystems_init` and `pubsub_install`. These are both for setting up basic running stuff. ``` { int init_rv = tor_init(argc, argv); if (init_rv) { tor_free_all(0); result = (init_rv < 0) ? -1 : 0; goto done; } } ``` We can add `tor_init` to that list: tor_init, subsystems_init, pubsub_install ``` pubsub_connect(); ``` Now we start getting an idea of the internals of tor. It install some pubsub thing, and now its connecting with regard to it. I'm imagining there's either another thread, or a network connection, running at this point, and that something is ready to pass information This is the order of interesting functions so far: tor_init, subsystems_init, pubsub_install, pubsub_connect . ``` if (get_options()->Sandbox && get_options()->command == CMD_RUN_TOR) { sandbox_cfg_t* cfg = sandbox_init_filter(); if (sandbox_init(cfg)) { tor_free(argv); log_err(LD_BUG,"Failed to create syscall sandbox filter"); tor_free_all(0); return -1; } tor_make_getaddrinfo_cache_active(); // registering libevent rng #ifdef HAVE_EVUTIL_SECURE_RNG_SET_URANDOM_DEVICE_FILE evutil_secure_rng_set_urandom_device_file( (char*) sandbox_intern_string("/dev/urandom")); #endif } ``` I'm going to treat this above chunk as pretty much ignorable boilerplate for now. ``` switch (get_options()->command) { ``` It looks like, although usually we think of just booting up tor and using it, it can actually be a lot of different things when it is run, depending on what the user specifies. Here, the code is listing them all, and saying what to do for each one. ``` case CMD_RUN_TOR: nt_service_set_state(SERVICE_RUNNING); result = run_tor_main_loop(); break; ``` `run_tor_main_loop` now seems way more important than any of the interesting functions we have queued. ``` case CMD_KEYGEN: result = load_ed_keys(get_options(), time(NULL)) < 0; break; case CMD_KEY_EXPIRATION: init_keys(); result = log_cert_expiration(); break; ``` Cool! cryptographic keys! I'm not a cryptographer and don't know the math or most of the algorithms at all but I can probably identify a lot of cryptographically vulnerable apps out there, that are being touted as secure. I don't know if tor is one of them nowadays. You'd expect it to be, so we can likely infer things from what cryptography it uses. ``` case CMD_LIST_FINGERPRINT: result = do_list_fingerprint(); break; case CMD_HASH_PASSWORD: do_hash_password(); result = 0; break; ``` keys and passwords and things. It might be useful for me to review how these are used. ``` case CMD_VERIFY_CONFIG: if (quiet_level == QUIET_NONE) printf("Configuration was valid\n"); result = 0; break; ``` I vaguely remember possibly using this one some. Verify that config file. ``` case CMD_DUMP_CONFIG: result = do_dump_config(); break; ``` Man, it's been so long. ``` case CMD_RUN_UNITTESTS: /* only set by test.c */ case CMD_IMMEDIATE: /* Handled in config.c */ default: log_warn(LD_BUG,"Illegal command number %d: internal error.", get_options()->command); result = -1; } ``` ``` tor_cleanup(); done: tor_free(argv); return result; } ``` This is basic cleanup. So, basically first tor runs tor_init, subsystems_init, pubsub_install, pubsub_connect, to setup. Then it runs run_tor_main_loop() and that's probably what it's doing most of the time. ``` src]$ grep -r run_tor_main_loop . ./app/main/main.c:run_tor_main_loop(void) ``` The next file we'd look in I suppose would be main.c . Really, the comments right around the very first file directed us to main.c, too; it's kind of a gamble around what bits of information you gather as you explore the code; which path you take. Maybe the next episode, possibly a look at main.c, will be a few years from now, who knows. But that doesn't mean it won't happen. On 10/13/20, Punk-BatSoup-Stasi 2.0 <punks@tfwno.gf> wrote:
On Tue, 13 Oct 2020 11:51:30 -0400 Karl <gmkarl@gmail.com> wrote:
I propose we talk about these things in the context of the tor source code or somesuch.
why don't you learn the ABC about tor? Or are you promoting tor because you're a pentagon agent? Just like you promoted BSV which suggests you're an accomplice of the criminal and highly anti-freedom asshole craigh wright.