1. 13 Jan, 2022 2 commits
  2. 06 Jan, 2022 1 commit
    • remote: introduce `git_remote_connect_options` · 6fc6eeb6
      The existing mechanism for providing options to remote fetch/push calls,
      and subsequently to transports, is unsatisfactory.  It requires an
      options structure to avoid breaking the API and callback signatures.
      
      1. Introduce `git_remote_connect_options` to satisfy those needs.
      
      2. Add a new remote connection API, `git_remote_connect_ext` that will
         take this new options structure.  Existing `git_remote_connect` calls
         will proxy to that.  `git_remote_fetch` and `git_remote_push` will
         proxy their fetch/push options to that as well.
      
      3. Define the interaction between `git_remote_connect` and fetch/push.
         Connect _may_ be called before fetch/push, but _need not_ be.  The
         semantics of which options would be used for these operations was
         not specified if you specify options for both connect _and_ fetch.
         Now these are defined that the fetch or push options will be used
         _if_ they were specified.  Otherwise, the connect options will be
         used if they were specified.  Otherwise, the library's defaults will
         be used.
      
      4. Update the transports to understand `git_remote_connect_options`.
         This is a breaking change to the systems API.
      Edward Thomson committed
  3. 17 Oct, 2021 1 commit
    • str: introduce `git_str` for internal, `git_buf` is external · f0e693b1
      libgit2 has two distinct requirements that were previously solved by
      `git_buf`.  We require:
      
      1. A general purpose string class that provides a number of utility APIs
         for manipulating data (eg, concatenating, truncating, etc).
      2. A structure that we can use to return strings to callers that they
         can take ownership of.
      
      By using a single class (`git_buf`) for both of these purposes, we have
      confused the API to the point that refactorings are difficult and
      reasoning about correctness is also difficult.
      
      Move the utility class `git_buf` to be called `git_str`: this represents
      its general purpose, as an internal string buffer class.  The name also
      is an homage to Junio Hamano ("gitstr").
      
      The public API remains `git_buf`, and has a much smaller footprint.  It
      is generally only used as an "out" param with strict requirements that
      follow the documentation.  (Exceptions exist for some legacy APIs to
      avoid breaking callers unnecessarily.)
      
      Utility functions exist to convert a user-specified `git_buf` to a
      `git_str` so that we can call internal functions, then converting it
      back again.
      Edward Thomson committed
  4. 02 Sep, 2021 2 commits
  5. 05 Aug, 2021 1 commit
    • http: don't require a password · 28841241
      Attempt authentication when a username is presented but a password is
      not; this can happen in particular when users are doing token
      authentication and specifying the token in the URL itself.  For example,
      `https://token@host/` is a valid URI and should be treated as a username
      of `token` with an empty password.
      Edward Thomson committed
  6. 27 Nov, 2020 1 commit
  7. 11 Oct, 2020 1 commit
  8. 07 Feb, 2020 2 commits
    • transports: use GIT_EAUTH for authentication failures · 216165ec
      When the failure is clearly an auth failure
      (as opposed to possibly an auth failure),
      use the error code GIT_EAUTH instead of GIT_ERROR.
      
      While we're here, fix a typo and improve an error message.
      
      Fixes #5389.
      Josh Bleecher Snyder committed
    • transports: http: fix custom headers not being applied · 46228d86
      In commit b9c5b15a (http: use the new httpclient, 2019-12-22), the HTTP
      code got refactored to extract a generic HTTP client that operates
      independently of the Git protocol. Part of refactoring was the creation
      of a new `git_http_request` struct that encapsulates the generation of
      requests. Our Git-specific HTTP transport was converted to use that in
      `generate_request`, but during the process we forgot to set up custom
      headers for the `git_http_request` and as a result we do not send out
      these headers anymore.
      
      Fix the issue by correctly setting up the request's custom headers and
      add a test to verify we correctly send them.
      Patrick Steinhardt committed
  9. 26 Jan, 2020 1 commit
    • credential: change git_cred to git_credential · 3f54ba8b
      We avoid abbreviations where possible; rename git_cred to
      git_credential.
      
      In addition, we have standardized on a trailing `_t` for enum types,
      instead of using "type" in the name.  So `git_credtype_t` has become
      `git_credential_t` and its members have become `GIT_CREDENTIAL` instead
      of `GIT_CREDTYPE`.
      
      Finally, the source and header files have been renamed to `credential`
      instead of `cred`.
      
      Keep previous name and values as deprecated, and include the new header
      files from the previous ones.
      Edward Thomson committed
  10. 24 Jan, 2020 6 commits
    • http: introduce GIT_ERROR_HTTP · e9cef7c4
      Disambiguate between general network problems and HTTP problems in error
      codes.
      Edward Thomson committed
    • http: send probe packets · 76fd406a
      When we're authenticating with a connection-based authentication scheme
      (NTLM, Negotiate), we need to make sure that we're still connected
      between the initial GET where we did the authentication and the POST
      that we're about to send.  Our keep-alive session may have not kept
      alive, but more likely, some servers do not authenticate the entire
      keep-alive connection and may have "forgotten" that we were
      authenticated, namely Apache and nginx.
      
      Send a "probe" packet, that is an HTTP POST request to the upload-pack
      or receive-pack endpoint, that consists of an empty git pkt ("0000").
      If we're authenticated, we'll get a 200 back.  If we're not, we'll get a
      401 back, and then we'll resend that probe packet with the first step of
      our authentication (asking to start authentication with the given
      scheme).  We expect _yet another_ 401 back, with the authentication
      challenge.
      
      Finally, we will send our authentication response with the actual POST
      data.  This will allow us to authenticate without draining the POST data
      in the initial request that gets us a 401.
      Edward Thomson committed
    • http: use the new httpclient · b9c5b15a
      Untangle the notion of the http transport from the actual http
      implementation.  The http transport now uses the httpclient.
      Edward Thomson committed
    • httpclient: support expect/continue · 7372573b
      Allow users to opt-in to expect/continue handling when sending a POST
      and we're authenticated with a "connection-based" authentication
      mechanism like NTLM or Negotiate.
      
      If the response is a 100, return to the caller (to allow them to post
      their body).  If the response is *not* a 100, buffer the response for
      the caller.
      
      HTTP expect/continue is generally safe, but some legacy servers
      have not implemented it correctly.  Require it to be opt-in.
      Edward Thomson committed
    • net: refactor gitno redirect handling · 471daeea
      Move the redirect handling into `git_net_url` for consistency.
      Edward Thomson committed
  11. 18 Jan, 2020 1 commit
  12. 13 Dec, 2019 1 commit
  13. 13 Sep, 2019 1 commit
  14. 23 Aug, 2019 2 commits
  15. 21 Aug, 2019 1 commit
    • http: allow dummy negotiation scheme to fail to act · 1c847169
      The dummy negotiation scheme is used for known authentication strategies
      that do not wish to act.  For example, when a server requests the
      "Negotiate" scheme but libgit2 is not built with Negotiate support, and
      will use the "dummy" strategy which will simply not act.
      
      Instead of setting `out` to NULL and returning a successful code, return
      `GIT_PASSTHROUGH` to indicate that it did not act and catch that error
      code.
      Edward Thomson committed
  16. 14 Jun, 2019 1 commit
    • Rename opt init functions to `options_init` · 0b5ba0d7
      In libgit2 nomenclature, when we need to verb a direct object, we name
      a function `git_directobject_verb`.  Thus, if we need to init an options
      structure named `git_foo_options`, then the name of the function that
      does that should be `git_foo_options_init`.
      
      The previous names of `git_foo_init_options` is close - it _sounds_ as
      if it's initializing the options of a `foo`, but in fact
      `git_foo_options` is its own noun that should be respected.
      
      Deprecate the old names; they'll now call directly to the new ones.
      Edward Thomson committed
  17. 10 Jun, 2019 15 commits
    • http: free auth context on failure · 7ea8630e
      When we send HTTP credentials but the server rejects them, tear down the
      authentication context so that we can start fresh.  To maintain this
      state, additionally move all of the authentication handling into
      `on_auth_required`.
      Edward Thomson committed
    • http: reconnect to proxy on connection close · 005b5bc2
      When we're issuing a CONNECT to a proxy, we expect to keep-alive to the
      proxy.  However, during authentication negotiations, the proxy may close
      the connection.  Reconnect if the server closes the connection.
      Edward Thomson committed
    • http: allow server to drop a keepalive connection · d171fbee
      When we have a keep-alive connection to the server, that server may
      legally drop the connection for any reason once a successful request and
      response has occurred.  It's common for servers to drop the connection
      after some amount of time or number of requests have occurred.
      Edward Thomson committed
    • http: stop on server EOF · 9af1de5b
      We stop the read loop when we have read all the data.  We should also
      consider the server's feelings.
      
      If the server hangs up on us, we need to stop our read loop.  Otherwise,
      we'll try to read from the server - and fail - ad infinitum.
      Edward Thomson committed
    • http: teach auth mechanisms about connection affinity · 539e6293
      Instead of using `is_complete` to decide whether we have connection or
      request affinity for authentication mechanisms, set a boolean on the
      mechanism definition itself.
      Edward Thomson committed
    • http: maintain authentication across connections · 3e0b4b43
      For request-based authentication mechanisms (Basic, Digest) we should
      keep the authentication context alive across socket connections, since
      the authentication headers must be transmitted with every request.
      
      However, we should continue to remove authentication contexts for
      mechanisms with connection affinity (NTLM, Negotiate) since we need to
      reauthenticate for every socket connection.
      Edward Thomson committed
    • http: simplify authentication mechanisms · ce72ae95
      Hold an individual authentication context instead of trying to maintain
      all the contexts; we can select the preferred context during the initial
      negotiation.
      
      Subsequent authentication steps will re-use the chosen authentication
      (until such time as it's rejected) instead of trying to manage multiple
      contexts when all but one will never be used (since we can only
      authenticate with a single mechanism at a time.)
      
      Also, when we're given a 401 or 407 in the middle of challenge/response
      handling, short-circuit immediately without incrementing the retry
      count.  The multi-step authentication is expected, and not a "retry" and
      should not be penalized as such.
      
      This means that we don't need to keep the contexts around and ensures
      that we do not unnecessarily fail for too many retries when we have
      challenge/response auth on a proxy and a server and potentially
      redirects in play as well.
      Edward Thomson committed
    • http: don't reset replay count after connection · 10718526
      A "connection" to a server is transient, and we may reconnect to a
      server in the midst of authentication failures (if the remote indicates
      that we should, via `Connection: close`) or in a redirect.
      Edward Thomson committed
    • http: validate server's authentication types · 79fc8281
      Ensure that the server supports the particular credential type that
      we're specifying.  Previously we considered credential types as an
      input to an auth mechanism - since the HTTP transport only supported
      default credentials (via negotiate) and username/password credentials
      (via basic), this worked.  However, if we are to add another mechanism
      that uses username/password credentials, we'll need to be careful to
      identify the types that are accepted.
      Edward Thomson committed
    • http: consume body on proxy auth failure · 5ad99210
      We must always consume the full parser body if we're going to
      keep-alive.  So in the authentication failure case, continue advancing
      the http message parser until it's complete, then we can retry the
      connection.
      
      Not doing so would mean that we have to tear the connection down and
      start over.  Advancing through fully (even though we don't use the data)
      will ensure that we can retry a connection with keep-alive.
      Edward Thomson committed
    • http: always consume body on auth failure · 75b20458
      When we get an authentication failure, we must consume the entire body
      of the response.  If we only read half of the body (on the assumption
      that we can ignore the rest) then we will never complete the parsing of
      the message.  This means that we will never set the complete flag, and
      our replay must actually tear down the connection and try again.
      
      This is particularly problematic for stateful authentication mechanisms
      (SPNEGO, NTLM) that require that we keep the connection alive.
      
      Note that the prior code is only a problem when the 401 that we are
      parsing is too large to be read in a single chunked read from the http
      parser.
      
      But now we will continue to invoke the http parser until we've got a
      complete message in the authentication failed scenario.  Note that we
      need not do anything with the message, so when we get an authentication
      failed, we'll stop adding data to our buffer, we'll simply loop in the
      parser and let it advance its internal state.
      Edward Thomson committed
    • http: examine keepalive status at message end · 9050c69c
      We cannot examine the keep-alive status of the http parser in
      `http_connect`; it's too late and the critical information about whether
      keep-alive is supported has been destroyed.
      
      Per the documentation for `http_should_keep_alive`:
      
      > If http_should_keep_alive() in the on_headers_complete or
      > on_message_complete callback returns 0, then this should be
      > the last message on the connection.
      
      Query then and set the state.
      Edward Thomson committed