USA 2020 Elections: Thread

[Karl]

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 at tfwno.gf> wrote:
> On Tue, 13 Oct 2020 11:51:30 -0400
> Karl <gmkarl at 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.
>
> 	
>