1. 28 Nov, 2018 19 commits
  2. 21 Nov, 2018 1 commit
    • transport: allow cred/cert callbacks to return GIT_PASSTHROUGH · a2e6e0ea
      Allow credential and certificate checking callbacks to return
      GIT_PASSTHROUGH, indicating that they do not want to act.
      Introduce this to support in both the http and ssh callbacks.
      Additionally, enable the same mechanism for certificate validation.
      
      This is most useful to disambiguate any meaning in the publicly exposed
      credential and certificate functions (`git_transport_smart_credentials`
      and `git_transport_smart_certificate_check`) but it may be more
      generally useful for callers to be able to defer back to libgit2.
      Edward Thomson committed
  3. 15 Nov, 2018 1 commit
  4. 09 Nov, 2018 1 commit
    • transport/http: Include non-default ports in Host header · 83b35181
      When the port is omitted, the server assumes the default port for the
      service is used (see
      https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host). In
      cases where the client provided a non-default port, it should be passed
      along.
      
      This hasn't been an issue so far as the git protocol doesn't include
      server-generated URIs. I encountered this when implementing Rust
      registry support for Sonatype Nexus. Rust's registry uses a git
      repository for the package index. Clients look at a file in the root of
      the package index to find the base URL for downloading the packages.
      Sonatype Nexus looks at the incoming HTTP request (Host header and URL)
      to determine the client-facing URL base as it may be running behind a
      load balancer or reverse proxy. This client-facing URL base is then used
      to construct the package download base URL. When libgit2 fetches the
      index from Nexus on a non-default port, Nexus trusts the incorrect Host
      header and generates an incorrect package download base URL.
      Rick Altherr committed
  5. 07 Nov, 2018 1 commit
    • smart transport: only clear url on hard reset · 9ad96367
      After creating a transport for a server, we expect to be able to call
      `connect`, then invoke subsequent `action` calls.  We provide the URL to
      these `action` calls, although our built-in transports happen to ignore
      it since they've already parsed it into an internal format that they
      intend to use (`gitno_connection_data`).
      
      In ca2eb460, we began clearing the URL
      field after a connection, meaning that subsequent calls to transport
      `action` callbacks would get a NULL URL, which went undetected since the
      builtin transports ignore the URL when they're already connected
      (instead of re-parsing it into an internal format).
      
      Downstream custom transport implementations (eg, LibGit2Sharp) did
      notice this change, however.
      
      Since `reset_stream` is called even when we're not closing the
      subtransport, update to only clear the URL when we're closing the
      subtransport.  This ensures that `action` calls will get the correct URL
      information even after a connection.
      Edward Thomson committed
  6. 18 Oct, 2018 1 commit
  7. 13 Oct, 2018 1 commit
  8. 06 Oct, 2018 1 commit
  9. 03 Oct, 2018 11 commits
    • smart_pkt: do not accept callers passing in no line length · 1bc5b05c
      Right now, we simply ignore the `linelen` parameter of
      `git_pkt_parse_line` in case the caller passed in zero. But in fact, we
      never want to assume anything about the provided buffer length and
      always want the caller to pass in the available number of bytes.
      And in fact, checking all the callers, one can see that the funciton is
      never being called in case where the buffer length is zero, and thus we
      are safe to remove this check.
      Patrick Steinhardt committed
    • smart_pkt: return parsed length via out-parameter · c05790a8
      The `parse_len` function currently directly returns the parsed length of
      a packet line or an error code in case there was an error. Instead,
      convert this to our usual style of using the return value as error code
      only and returning the actual value via an out-parameter. Thus, we can
      now convert the output parameter to an unsigned type, as the size of a
      packet cannot ever be negative.
      
      While at it, we also move the check whether the input buffer is long
      enough into `parse_len` itself. We don't really want to pass around
      potentially non-NUL-terminated buffers to functions without also passing
      along the length, as this is dangerous in the unlikely case where other
      callers for that function get added. Note that we need to make sure
      though to not mess with `GIT_EBUFS` error codes, as these indicate not
      an error to the caller but that he needs to fetch more data.
      Patrick Steinhardt committed
    • smart_pkt: reorder and rename parameters of `git_pkt_parse_line` · 0b3dfbf4
      The parameters of the `git_pkt_parse_line` function are quite confusing.
      First, there is no real indicator what the `out` parameter is actually
      all about, and it's not really clear what the `bufflen` parameter refers
      to. Reorder and rename the parameters to make this more obvious.
      Patrick Steinhardt committed
    • smart_pkt: fix buffer overflow when parsing "unpack" packets · 5fabaca8
      When checking whether an "unpack" packet returned the "ok" status or
      not, we use a call to `git__prefixcmp`. In case where the passed line
      isn't properly NUL terminated, though, this may overrun the line buffer.
      Fix this by using `git__prefixncmp` instead.
      Patrick Steinhardt committed
    • smart_pkt: fix "ng" parser accepting non-space character · b5ba7af2
      When parsing "ng" packets, we blindly assume that the character
      immediately following the "ng" prefix is a space and skip it. As the
      calling function doesn't make sure that this is the case, we can thus
      end up blindly accepting an invalid packet line.
      
      Fix the issue by using `git__prefixncmp`, checking whether the line
      starts with "ng ".
      Patrick Steinhardt committed
    • smart_pkt: fix buffer overflow when parsing "ok" packets · a9f1ca09
      There are two different buffer overflows present when parsing "ok"
      packets. First, we never verify whether the line already ends after
      "ok", but directly go ahead and also try to skip the expected space
      after "ok". Second, we then go ahead and use `strchr` to scan for the
      terminating newline character. But in case where the line isn't
      terminated correctly, this can overflow the line buffer.
      
      Fix the issues by using `git__prefixncmp` to check for the "ok " prefix
      and only checking for a trailing '\n' instead of using `memchr`. This
      also fixes the issue of us always requiring a trailing '\n'.
      
      Reported by oss-fuzz, issue 9749:
      
      Crash Type: Heap-buffer-overflow READ {*}
      Crash Address: 0x6310000389c0
      Crash State:
        ok_pkt
        git_pkt_parse_line
        git_smart__store_refs
      
      Sanitizer: address (ASAN)
      Patrick Steinhardt committed
    • smart_pkt: fix buffer overflow when parsing "ACK" packets · bc349045
      We are being quite lenient when parsing "ACK" packets. First, we didn't
      correctly verify that we're not overrunning the provided buffer length,
      which we fix here by using `git__prefixncmp` instead of
      `git__prefixcmp`. Second, we do not verify that the actual contents make
      any sense at all, as we simply ignore errors when parsing the ACKs OID
      and any unknown status strings. This may result in a parsed packet
      structure with invalid contents, which is being silently passed to the
      caller. This is being fixed by performing proper input validation and
      checking of return codes.
      Patrick Steinhardt committed
    • smart_pkt: adjust style of "ref" packet parsing function · 5edcf5d1
      While the function parsing ref packets doesn't have any immediately
      obvious buffer overflows, it's style is different to all the other
      parsing functions. Instead of checking buffer length while we go, it
      does a check up-front. This causes the code to seem a lot more magical
      than it really is due to some magic constants. Refactor the function to
      instead make use of the style of other packet parser and verify buffer
      lengths as we go.
      Patrick Steinhardt committed
    • smart_pkt: check whether error packets are prefixed with "ERR " · 786426ea
      In the `git_pkt_parse_line` function, we determine what kind of packet
      a given packet line contains by simply checking for the prefix of that
      line. Except for "ERR" packets, we always only check for the immediate
      identifier without the trailing space (e.g. we check for an "ACK"
      prefix, not for "ACK "). But for "ERR" packets, we do in fact include
      the trailing space in our check. This is not really much of a problem at
      all, but it is inconsistent with all the other packet types and thus
      causes confusion when the `err_pkt` function just immediately skips the
      space without checking whether it overflows the line buffer.
      
      Adjust the check in `git_pkt_parse_line` to not include the trailing
      space and instead move it into `err_pkt` for consistency.
      Patrick Steinhardt committed
    • smart_pkt: explicitly avoid integer overflows when parsing packets · 40fd84cc
      When parsing data, progress or error packets, we need to copy the
      contents of the rest of the current packet line into the flex-array of
      the parsed packet. To keep track of this array's length, we then assign
      the remaining length of the packet line to the structure. We do have a
      mismatch of types here, as the structure's `len` field is a signed
      integer, while the length that we are assigning has type `size_t`.
      
      On nearly all platforms, this shouldn't pose any problems at all. The
      line length can at most be 16^4, as the line's length is being encoded
      by exactly four hex digits. But on a platforms with 16 bit integers,
      this assignment could cause an overflow. While such platforms will
      probably only exist in the embedded ecosystem, we still want to avoid
      this potential overflow. Thus, we now simply change the structure's
      `len` member to be of type `size_t` to avoid any integer promotion.
      Patrick Steinhardt committed
    • smart_pkt: honor line length when determining packet type · 4a5804c9
      When we parse the packet type of an incoming packet line, we do not
      verify that we don't overflow the provided line buffer. Fix this by
      using `git__prefixncmp` instead and passing in `len`. As we have
      previously already verified that `len <= linelen`, we thus won't ever
      overflow the provided buffer length.
      Patrick Steinhardt committed
  10. 21 Aug, 2018 1 commit
  11. 17 Aug, 2018 1 commit
  12. 30 Jul, 2018 1 commit