GitLab

In channel_tls_process_netinfo_cell() we have a section that says

      if (!(chan->conn->handshake_state->authenticated)) {
        tor_assert(tor_digest_is_zero(
                  (const char*)(chan->conn->handshake_state->
                      authenticated_rsa_peer_id)));
        tor_assert(tor_mem_is_zero(
                  (const char*)(chan->conn->handshake_state->
                                authenticated_ed25519_peer_id.pubkey), 32));
        /* If the client never authenticated, it's a tor client or bridge
         * relay, and we must not use it for EXTEND requests (nor could we, as
         * there are no authenticated peer IDs) */
        channel_mark_client(TLS_CHAN_TO_BASE(chan));

That's great and awesome -- it's a clear solid definition of client: a client is somebody who did the client handshake with us, not the relay handshake.

But then in command.c we have this weird clause:

  if (connection_or_digest_is_known_relay(chan->identity_digest)) {
    rep_hist_note_circuit_handshake_requested(create_cell->handshake_type);
    // Needed for chutney: Sometimes relays aren't in the consensus yet, and
    // get marked as clients. This resets their channels once they appear.
    // Probably useful for normal operation wrt relay flapping, too.
    channel_clear_client(chan);
  } else {
    channel_mark_client(chan);
  }

This definition of client is much murkier: a client is anybody who, at this moment of receiving a create cell, had earlier presented an identity digest that isn't in our current consensus and that we don't have a cached descriptor for.

I think we should standardize on one definition, and I think we should pick the first one: it's clean and not full of false positives.