1. 31 Jan, 2019 1 commit
    • streams: fix callers potentially only writing partial data · 5265b31c
      Similar to the write(3) function, implementations of `git_stream_write`
      do not guarantee that all bytes are written. Instead, they return the
      number of bytes that actually have been written, which may be smaller
      than the total number of bytes. Furthermore, due to an interface design
      issue, we cannot ever write more than `SSIZE_MAX` bytes at once, as
      otherwise we cannot represent the number of bytes written to the caller.
      
      Unfortunately, no caller of `git_stream_write` ever checks the return
      value, except to verify that no error occurred. Due to this, they are
      susceptible to the case where only partial data has been written.
      
      Fix this by introducing a new function `git_stream__write_full`. In
      contrast to `git_stream_write`, it will always return either success or
      failure, without returning the number of bytes written. Thus, it is able
      to write all `SIZE_MAX` bytes and loop around `git_stream_write` until
      all data has been written. Adjust all callers except the BIO callbacks
      in our mbedtls and OpenSSL streams, which already do the right thing and
      require the amount of bytes written.
      Patrick Steinhardt committed
  2. 25 Jan, 2019 1 commit
  3. 24 Jan, 2019 1 commit
  4. 22 Jan, 2019 1 commit
  5. 17 Jan, 2019 1 commit
  6. 14 Jan, 2019 1 commit
  7. 06 Jan, 2019 2 commits
    • Windows is hard. · 321d19c1
      lhchavez committed
    • Fix a bunch of warnings · 7b453e7e
      This change fixes a bunch of warnings that were discovered by compiling
      with `clang -target=i386-pc-linux-gnu`. It turned out that the
      intrinsics were not necessarily being used in all platforms! Especially
      in GCC, since it does not support __has_builtin.
      
      Some more warnings were gleaned from the Windows build, but I stopped
      when I saw that some third-party dependencies (e.g. zlib) have warnings
      of their own, so we might never be able to enable -Werror there.
      lhchavez committed
  8. 01 Dec, 2018 1 commit
  9. 28 Nov, 2018 19 commits
  10. 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
  11. 15 Nov, 2018 1 commit
  12. 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
  13. 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
  14. 18 Oct, 2018 1 commit
  15. 13 Oct, 2018 1 commit
  16. 06 Oct, 2018 1 commit
  17. 03 Oct, 2018 5 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