On 10/12/20, Zenaan Harkness <zen@freedbms.net> wrote: [unclear stuff that looks like part of an ongoing military psyop]
Let no man come between you and God. [more unclear stuff that looks like part of an ongoing military psyop]
Zenaan, you don't understand God. Anonymity networks are God. Do you understand? Anonymity networks are God. Now, you understand God. Let's look into the tor source code just a little. If we need roles, I can be the corporate goonie, and zenaan can be the oppressed open source hacker. Zenaan, if you weren't there, a way to get the tor source code is: ``` $ git clone https://git.torproject.org/tor.git ... $ cd tor ``` Now, you're in the tor source code folder! As a corporate goonie, I'm pretending to watch everything you do, coming in occasionally to make really difficult changes to your project while pretending to contribute. You're all confused from these occasional psyops, and you just want to make tor work. You have to understand it piece by piece to move through it in your confusion. If you're really lucky, you find a way to work with me, the corporate goonie, so that the work is easy and you actually get paid. ``` tor]$ less src/feature/api/tor_api.c ``` Last episode, we left off that `tor_api.c` was a likely way to find the main execution of the tor daemon. You have to hit 'space' until the screen stops moving, to get to the `tor_main` function at the bottom. ``` /* Main entry point for the Tor process. Called from main(). * * This function is distinct from main() only so we can link main.c into * the unittest binary without conflicting with the unittests' main. * * Some embedders have historically called this function; but that usage is * deprecated: they should use tor_run_main() instead. */ int tor_main(int argc, char *argv[]) { tor_main_configuration_t *cfg = tor_main_configuration_new(); if (!cfg) { puts("INTERNAL ERROR: Allocation failure. Cannot proceed"); return 1; } if (tor_main_configuration_set_command_line(cfg, argc, argv) < 0) { puts("INTERNAL ERROR: Can't set command line. Cannot proceed."); return 1; } int rv = tor_run_main(cfg); tor_main_configuration_free(cfg); return rv; } ``` We love this stuff! There are pretty much only a couple things happening here. ``` tor_main_configuration_t *cfg = tor_main_configuration_new(); if (!cfg) { puts("INTERNAL ERROR: Allocation failure. Cannot proceed"); return 1; } ``` This produces a new configuration object, to store the tor configuration in. ``` if (tor_main_configuration_set_command_line(cfg, argc, argv) < 0) { puts("INTERNAL ERROR: Can't set command line. Cannot proceed."); return 1; } ``` This likely processes the parameters passed to the program, and inserts them into the configuration object. ``` int rv = tor_run_main(cfg); ``` This passes off the behavior to the `tor_run_main` set of code, and lets it handle everything else. `rv` is the result of its execution, and will be returned to the operating system after tor shuts down. All the rest of tor is in some other file. I often use `grep` to find sourcefiles. ``` $ grep -r 'tor_run_main(' . ./ChangeLog: - Always call tor_free_all() when leaving tor_run_main(). When we ./ChangeLog: - Always call tor_free_all() when leaving tor_run_main(). When we ./ReleaseNotes: - Always call tor_free_all() when leaving tor_run_main(). When we ./ReleaseNotes: - Always call tor_free_all() when leaving tor_run_main(). When we ./src/app/main/main.c:tor_run_main(const tor_main_configuration_t *tor_cfg) ``` `tor_run_main`, the next code to look at, is in src/app/main/main.c . Just one step of reviewing the tor source code! Now, wasn't that easy? Be well.