1. 06 Jan, 2017 2 commits
    • smart_pkt: treat empty packet lines as error · 2fdef641
      The Git protocol does not specify what should happen in the case
      of an empty packet line (that is a packet line "0004"). We
      currently indicate success, but do not return a packet in the
      case where we hit an empty line. The smart protocol was not
      prepared to handle such packets in all cases, though, resulting
      in a `NULL` pointer dereference.
      
      Fix the issue by returning an error instead. As such kind of
      packets is not even specified by upstream, this is the right
      thing to do.
      Patrick Steinhardt committed
    • smart_pkt: verify packet length exceeds PKT_LEN_SIZE · 66e3774d
      Each packet line in the Git protocol is prefixed by a four-byte
      length of how much data will follow, which we parse in
      `git_pkt_parse_line`. The transmitted length can either be equal
      to zero in case of a flush packet or has to be at least of length
      four, as it also includes the encoded length itself. Not
      checking this may result in a buffer overflow as we directly pass
      the length to functions which accept a `size_t` length as
      parameter.
      
      Fix the issue by verifying that non-flush packets have at least a
      length of `PKT_LEN_SIZE`.
      Patrick Steinhardt committed
  2. 29 Dec, 2016 1 commit
  3. 07 Jun, 2016 1 commit
    • transports: smart: fix potential invalid memory dereferences · 7d02019a
      When we receive a packet of exactly four bytes encoding its
      length as those four bytes it can be treated as an empty line.
      While it is not really specified how those empty lines should be
      treated, we currently ignore them and do not return an error when
      trying to parse it but simply advance the data pointer.
      
      Callers invoking `git_pkt_parse_line` are currently not prepared
      to handle this case as they do not explicitly check this case.
      While they could always reset the passed out-pointer to `NULL`
      before calling `git_pkt_parse_line` and determine if the pointer
      has been set afterwards, it makes more sense to update
      `git_pkt_parse_line` to set the out-pointer to `NULL` itself when
      it encounters such an empty packet. Like this it is guaranteed
      that there will be no invalid memory references to free'd
      pointers.
      
      As such, the issue has been fixed such that `git_pkt_parse_line`
      always sets the packet out pointer to `NULL` when an empty packet
      has been received and callers check for this condition, skipping
      such packets.
      Patrick Steinhardt committed
  4. 23 Feb, 2016 2 commits
  5. 18 Feb, 2016 1 commit
  6. 17 Aug, 2015 1 commit
  7. 12 Jul, 2015 1 commit
  8. 13 Feb, 2015 4 commits
  9. 21 May, 2014 1 commit
  10. 21 Apr, 2014 1 commit
  11. 30 Oct, 2013 1 commit
    • protocol: basic support for multi_ack_detailed · 2f8c481c
      This tells the server that we speak it, but we don't make use of its
      extra information to determine if there's a better place to stop
      negotiating.
      
      In a somewhat-related change, reorder the capabilities so we ask for
      them in the same order as git does.
      
      Also take this opportunity to factor out a fairly-indented portion of
      the negotiation logic.
      Carlos Martín Nieto committed
  12. 04 Oct, 2013 1 commit
  13. 12 Mar, 2013 1 commit
  14. 08 Jan, 2013 1 commit
  15. 29 Nov, 2012 1 commit
  16. 28 Nov, 2012 1 commit
  17. 01 Nov, 2012 1 commit
  18. 30 Sep, 2012 1 commit
  19. 24 Aug, 2012 1 commit
  20. 30 Jul, 2012 2 commits
  21. 13 Jul, 2012 1 commit
    • pkt: correctly advertise capabilitites · 7b8c9e12
      The correct way to advertise out capabilities is by appending them to
      the first 'want' line, using SP as separator, instead of NUL as the
      server does. Inconsistent documentation lead to the use of NUL in
      libgit2.
      
      Fix this so we can request much more efficient packs from the
      remote which reduces the indexing time considerably.
      Carlos Martín Nieto committed
  22. 19 May, 2012 1 commit
  23. 17 May, 2012 2 commits
  24. 08 May, 2012 1 commit
  25. 30 Apr, 2012 2 commits
  26. 28 Apr, 2012 1 commit
  27. 25 Apr, 2012 1 commit
  28. 17 Apr, 2012 1 commit
  29. 11 Apr, 2012 1 commit
  30. 02 Mar, 2012 1 commit
    • Clean up GIT_UNUSED macros on all platforms · 854eccbb
      It turns out that commit 31e9cfc4cbcaf1b38cdd3dbe3282a8f57e5366a5
      did not fix the GIT_USUSED behavior on all platforms.  This commit
      walks through and really cleans things up more thoroughly, getting
      rid of the unnecessary stuff.
      
      To remove the use of some GIT_UNUSED, I ended up adding a couple
      of new iterators for hashtables that allow you to iterator just
      over keys or just over values.
      
      In making this change, I found a bug in the clar tests (where we
      were doing *count++ but meant to do (*count)++ to increment the
      value).  I fixed that but then found the test failing because it
      was not really using an empty repo.  So, I took some of the code
      that I wrote for iterator testing and moved it to clar_helpers.c,
      then made use of that to make it easier to open fixtures on a
      per test basis even within a single test file.
      Russell Belfer committed
  31. 13 Feb, 2012 1 commit
  32. 08 Dec, 2011 1 commit
    • Use git_buf for path storage instead of stack-based buffers · 97769280
      This converts virtually all of the places that allocate GIT_PATH_MAX
      buffers on the stack for manipulating paths to use git_buf objects
      instead.  The patch is pretty careful not to touch the public API
      for libgit2, so there are a few places that still use GIT_PATH_MAX.
      
      This extends and changes some details of the git_buf implementation
      to add a couple of extra functions and to make error handling easier.
      
      This includes serious alterations to all the path.c functions, and
      several of the fileops.c ones, too.  Also, there are a number of new
      functions that parallel existing ones except that use a git_buf
      instead of a stack-based buffer (such as git_config_find_global_r
      that exists alongsize git_config_find_global).
      
      This also modifies the win32 version of p_realpath to allocate whatever
      buffer size is needed to accommodate the realpath instead of hardcoding
      a GIT_PATH_MAX limit, but that change needs to be tested still.
      Russell Belfer committed