1. 10 Nov, 2017 1 commit
  2. 25 Oct, 2017 1 commit
  3. 24 Oct, 2017 1 commit
  4. 23 Oct, 2017 1 commit
  5. 17 Oct, 2017 1 commit
  6. 05 Oct, 2017 2 commits
  7. 07 Sep, 2017 1 commit
  8. 03 Aug, 2017 1 commit
  9. 01 Aug, 2017 2 commits
  10. 26 Jul, 2017 3 commits
  11. 25 Jul, 2017 4 commits
  12. 17 Jul, 2017 2 commits
    • Isis Lovecruft's avatar
      Add a changes file for bug22636. · 7b4585e2
      Isis Lovecruft authored
      7b4585e2
    • Isis Lovecruft's avatar
      Fix and expand upon our Travis CI configuration. · 68722a1d
      Isis Lovecruft authored
       * CHANGE .travis.yml so that commands for different purposes (e.g. getting
         dependencies, building, testing) are in separate config lines and sections.
       * CHANGE .travis.yml to use their mechanism for installing dependencies via
         apt. [0]  This also allows us to not need sudo (the "sudo: false" line).
       * CHANGE Travis CI tests (the "script:" section) to build and run tests in the
         same manner as Jenkins (i.e. with --enable-fatal-warnings and
         --disable-silent-rules and run `make check`).
       * ADD Travis configuration to do all the target builds with both GCC and clang.
       * ADD make flags to build with both of the cores available.
       * ADD notifications for IRC, and configure email notifications (to the author
         of the commit) only if the branch was previously building successfully and
         the latest commit broke it.
       * ADD the ability to run the Travis build matrix for OSX as well, but leave it
         commented out by default (because it takes roughly ten times longer, due to a
         shortage of OSX build machines).
       * ADD Travis config option to cancel/fail the build early if one target has
         already failed ("fast_finish: true").
       * ADD comments to describe what our Travis config is doing and why it is
         configured that way.
      
      [0]: https://docs.travis-ci.com/user/installing-dependencies/#Installing-Packages-on-Container-Based-Infrastructure)
      68722a1d
  13. 13 Jul, 2017 1 commit
    • Patrick O'Doherty's avatar
      .travis.yml to run test suite · 071e9b56
      Patrick O'Doherty authored and Isis Lovecruft's avatar Isis Lovecruft committed
      Installs dependencies (including rust) and runs the existing test suite.
      
      TODO: Introduce build matrix utilizing the rust toolchain to run test
      suites both with and without the rust components.
      071e9b56
  14. 07 Jul, 2017 3 commits
  15. 05 Jul, 2017 2 commits
  16. 03 Jul, 2017 1 commit
  17. 27 Jun, 2017 3 commits
    • Nick Mathewson's avatar
      ccae9916
    • Nick Mathewson's avatar
      d56f6993
    • Nick Mathewson's avatar
      Fix an errant memset() into the middle of a struct in cell_pack(). · 8d2978b1
      Nick Mathewson authored
      This mistake causes two possible bugs. I believe they are both
      harmless IRL.
      
      BUG 1: memory stomping
      
      When we call the memset, we are overwriting two 0 bytes past the end
      of packed_cell_t.body. But I think that's harmless in practice,
      because the definition of packed_cell_t is:
      
      // ...
      typedef struct packed_cell_t {
        TOR_SIMPLEQ_ENTRY(packed_cell_t) next;
        char body[CELL_MAX_NETWORK_SIZE];
        uint32_t inserted_time;
      } packed_cell_t;
      
      So we will overwrite either two bytes of inserted_time, or two bytes
      of padding, depending on how the platform handles alignment.
      
      If we're overwriting padding, that's safe.
      
      If we are overwriting the inserted_time field, that's also safe: In
      every case where we call cell_pack() from connection_or.c, we ignore
      the inserted_time field. When we call cell_pack() from relay.c, we
      don't set or use inserted_time until right after we have called
      cell_pack(). SO I believe we're safe in that case too.
      
      BUG 2: memory exposure
      
      The original reason for this memset was to avoid the possibility of
      accidentally leaking uninitialized ram to the network. Now
      remember, if wide_circ_ids is false on a connection, we shouldn't
      actually be sending more than 512 bytes of packed_cell_t.body, so
      these two bytes can only leak to the network if there is another bug
      somewhere else in the code that sends more data than is correct.
      
      Fortunately, in relay.c, where we allocate packed_cell_t in
      packed_cell_new() , we allocate it with tor_malloc_zero(), which
      clears the RAM, right before we call cell_pack. So those
      packed_cell_t.body bytes can't leak any information.
      
      That leaves the two calls to cell_pack() in connection_or.c, which
      use stack-alocated packed_cell_t instances.
      
      In or_handshake_state_record_cell(), we pass the cell's contents to
      crypto_digest_add_bytes(). When we do so, we get the number of
      bytes to pass using the same setting of wide_circ_ids as we passed
      to cell_pack(). So I believe that's safe.
      
      In connection_or_write_cell_to_buf(), we also use the same setting
      of wide_circ_ids in both calls. So I believe that's safe too.
      
      I introduced this bug with 1c0e87f6
      back in 0.2.4.11-alpha; it is bug 22737 and CID 1401591
      8d2978b1
  18. 09 Jun, 2017 2 commits
  19. 08 Jun, 2017 8 commits