1. 27 Oct, 2020 7 commits
  2. 23 Oct, 2020 1 commit
    • Nick Mathewson's avatar
      Update required/recommended protocol lists more systematically · fd58e74d
      Nick Mathewson authored
      First I began with a set of candidates:
      
        The client's _required_ list starts with all the protocols
        supported by every release in 0.2.9-stable through current
        master.
      
        The client's _required_ list starts with all the protocols
        supported by every release in 0.3.5-stable through current
        master.
      
        Everybody's _recommended_ list starts with all the protocols
        supported by every release in 0.3.5-stable through current master.
      
      Then I removed the protocol versions that we do not actually want to
      require or recommend:
      
        DirCache=1 (deprecated)
        HSDir=1, HSIntro=1-3, HSRend=1 (deprecated)
        (All HS* protocol requirements for clients)
        Link=1-3 (deprecated)
        LinkAuth=1 (obsolete)
        Relay=1 (obsolete)
      fd58e74d
  3. 22 Oct, 2020 1 commit
    • Roger Dingledine's avatar
      Turn ConsensusParams into a Linelist · 00118355
      Roger Dingledine authored
      Make it possible to specify multiple ConsensusParams torrc
      lines.
      
      Now directory authority operators can for example put the
      main ConsensusParams config in one torrc file and then add to it
      from a different torrc file.
      
      Closes ticket 40164.
      00118355
  4. 21 Oct, 2020 1 commit
  5. 20 Oct, 2020 1 commit
  6. 19 Oct, 2020 2 commits
  7. 18 Oct, 2020 2 commits
    • Nick Mathewson's avatar
      Update required/recommended protocol versions. · d872c692
      Nick Mathewson authored
        Cons=1 is the old format of consensuses, without ed25519 keys. It
        is no longer required or recommended.
      
        Cons=2 is the new format of consensuses, with ed25519 keys. It
        is now required.
      
        (Similarly for Desc=1,2 and Microdesc=1,2)
      
      No supported client or relay versions should be affected by this
      change, since these versions are supported by clients and relays
      running 0.2.9 and later.  It will only take effect once enough
      authorities vote for it.
      
      Closes ticket 40162.
      d872c692
    • Nick Mathewson's avatar
      Split required/recommended protocol lists into multiple lines · 4298d877
      Nick Mathewson authored
      This should make diffs easier to read.
      4298d877
  8. 15 Oct, 2020 2 commits
  9. 08 Oct, 2020 1 commit
  10. 07 Oct, 2020 2 commits
  11. 06 Oct, 2020 1 commit
    • Alexander Færøy's avatar
      Expose TOR_PT_OUTBOUND_BIND_ADDRESS_{V4,V6} to Pluggable Transports. · 5f61e19d
      Alexander Færøy authored and David Goulet's avatar David Goulet committed
      This patch adds support for exposing the environment variables
      `TOR_PT_OUTBOUND_BIND_ADDRESS_V4` and `TOR_PT_OUTBOUND_BIND_ADDRESS_V6` to
      Pluggable Transport proccesses. These two values will contain the IPv4
      and IPv6 address that the user have specified in torrc that they wish
      the PT to use for all outgoing IP packets.
      
      It is important to note here that it is up to the indvidual Pluggable
      Transport if they are willing to honor these values or ignore them
      completely.
      
      One can test this feature using the following dummy PT written in POSIX
      shell script:
      
          #!/bin/sh
      
          echo "LOG SEVERITY=warning MESSAGE=\"Value for IPv4: ${TOR_PT_OUTBOUND_BIND_ADDRESS_V4}\""
          echo "LOG SEVERITY=warning MESSAGE=\"Value for IPv6: ${TOR_PT_OUTBOUND_BIND_ADDRESS_V6}\""
      
          while true ; do
              sleep 1
          done
      
      with the following entries in your torrc:
      
          OutboundBindAddressPT 203.0.113.4
          OutboundBindAddress 203.0.113.5
          OutboundBindAddressPT 2001:db8::4
          OutboundBindAddress 2001:db8::5
      
      See: https://bugs.torproject.org/5304
      5f61e19d
  12. 01 Oct, 2020 1 commit
  13. 28 Sep, 2020 1 commit
  14. 23 Sep, 2020 9 commits
  15. 22 Sep, 2020 2 commits
  16. 18 Sep, 2020 1 commit
    • Nick Mathewson's avatar
      Add flag for whether an OR conn "counts" for bootstrap tracking · 781ab9ee
      Nick Mathewson authored
      We set this flag if we've launched the connection in order to
      satisfy an origin circuit, or when we decide the connection _would_
      satisfy an origin circuit.  These are the only or_connections we
      want to consider for bootstrapping: other or_connections are opened
      because of client EXTEND requests, and they may succeed or fail
      because of the clients' confusion or misconfiguration.
      
      Closes #25061.
      781ab9ee
  17. 17 Sep, 2020 3 commits
    • Nick Mathewson's avatar
      Use the correct SIGNED_KEY_TYPE value for signing->link certs · 5d1d7afc
      Nick Mathewson authored
      Our code was using [01] as for the key type of signed->link certs,
      which was incorrect.  The value should be [03], to indicate that the
      value as the SHA256 of an x.509 cert.
      
      Fortunately, nothing cares about this value, so there shouldn't be
      compatibility issues.
      
      Fixes bug 40124; bugfix on 0.2.7.2-alpha.
      5d1d7afc
    • Nick Mathewson's avatar
      Fix wide lines · 22643272
      Nick Mathewson authored
      22643272
    • Nick Mathewson's avatar
      Rename tor_cert_create to tor_cert_create_ed25519 · c92e1926
      Nick Mathewson authored
      This is an automated commit, generated by this command:
      
      ./scripts/maint/rename_c_identifier.py \
              tor_cert_create tor_cert_create_ed25519
      
      It was generated with --no-verify, so it probably breaks some commit hooks.
      The commiter should be sure to fix them up in a subsequent commit.
      c92e1926
  18. 07 Sep, 2020 1 commit
    • George Kadianakis's avatar
      statistics: Properly count all rendezvous cells (avoid undercounting). · 85a1e6c6
      George Kadianakis authored
      tl;dr We were not counting cells flying from the client to the service, but we
      were counting cells flying from the service to the client.
      
      When a rendezvous cell arrives from the client to the RP, the RP forwards it to
      the service.
      
      For this to happen, the cell first passes through command_process_relay_cell()
      which normally does the statistics counting. However because the `rend_circ`
      circuit was not flagged with `circuit_carries_hs_traffic_stats` in
      rend_mid_rendezvous(), the cell is not counted there.
      
      Then the cell goes to circuit_receive_relay_cell() which has a special code
      block based on `rend_splice` specifically for rendezvous cells, and the cell
      gets directly passed to `rend_circ` via a direct call to
      circuit_receive_relay_cell(). The cell never passes through
      command_process_relay_cell() ever again and hence is never counted by our
      rephist module.
      
      The fix here is to flag the `rend_circ` circuit with
      `circuit_carries_hs_traffic_stats` so that the cell is counted as soon as it
      hits command_process_relay_cell().
      
      Furthermore we avoid double-counting cells since the special code block of
      circuit_receive_relay_cell() makes us count rendezvous cells only as they enter
      the RP and not as they exit it.
      
      Fixes #40117.
      85a1e6c6
  19. 25 Aug, 2020 1 commit