1. 07 Feb, 2020 1 commit
    • 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
  2. 06 Feb, 2020 1 commit
  3. 04 Feb, 2020 2 commits
  4. 01 Feb, 2020 1 commit
  5. 31 Jan, 2020 3 commits
    • fetchhead: strip credentials from remote URL · 93a9044f
      If fetching from an anonymous remote via its URL, then the URL gets
      written into the FETCH_HEAD reference. This is mainly done to give
      valuable context to some commands, like for example git-merge(1), which
      will put the URL into the generated MERGE_MSG. As a result, what gets
      written into FETCH_HEAD may become public in some cases. This is
      especially important considering that URLs may contain credentials, e.g.
      when cloning 'https://foo:bar@example.com/repo' we persist the complete
      URL into FETCH_HEAD and put it without any kind of sanitization into the
      MERGE_MSG. This is obviously bad, as your login data has now just leaked
      as soon as you do git-push(1).
      
      When writing the URL into FETCH_HEAD, upstream git does strip
      credentials first. Let's do the same by trying to parse the remote URL
      as a "real" URL, removing any credentials and then re-formatting the
      URL. In case this fails, e.g. when it's a file path or not a valid URL,
      we just fall back to using the URL as-is without any sanitization. Add
      tests to verify our behaviour.
      Patrick Steinhardt committed
    • Merge pull request #5375 from pks-t/pks/test-ci · a1bff63b
      azure-pipelines: properly expand negotiate passwords
      Edward Thomson committed
    • azure-pipelines: properly expand negotiate passwords · 7aa99dd3
      To allow testing against a Kerberos instance, we have added variables
      for the Kerberos password to allow authentication against LIBGIT2.ORG in
      commit e5fb5fe5 (ci: perform SPNEGO tests, 2019-10-20). To set up the
      password, we assign
      
          "GITTEST_NEGOTIATE_PASSWORD=$(GITTEST_NEGOTIATE_PASSWORD)"
      
      in the environmentVariables section which is then passed through to a
      template. As the template does build-time expansion of the environment
      variables, it will expand the above line verbosely, and due to the
      envVar section not doing any further expansion the password variable
      will end up with the value "$(GITTEST_NEGOTIATE_PASSWORD)" in the
      container's environment.
      
      Fix this fixed by doing expansion of GITTEST_NEGOTIATE_PASSWORD at
      build-time, as well.
      Patrick Steinhardt committed
  6. 30 Jan, 2020 3 commits
  7. 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
  8. 24 Jan, 2020 28 commits