1. 25 Jun, 2012 1 commit
  2. 12 Dec, 2011 4 commits
    • Jeff King's avatar
      credential: make relevance of http path configurable · a78fbb4f
      Jeff King authored
      When parsing a URL into a credential struct, we carefully
      record each part of the URL, including the path on the
      remote host, and use the result as part of the credential
      This had two practical implications:
        1. Credential helpers which store a credential for later
           access are likely to use the "path" portion as part of
           the storage key. That means that a request to
           would not use the same credential that was stored in an
           earlier request for:
        2. The prompt shown to the user includes all relevant
           context, including the path.
      In most cases, however, users will have a single password
      per host. The behavior in (1) will be inconvenient, and the
      prompt in (2) will be overly long.
      This patch introduces a config option to toggle the
      relevance of http paths. When turned on, we use the path as
      before. When turned off, we drop the path component from the
      context: helpers don't see it, and it does not appear in the
      This is nothing you couldn't do with a clever credential
      helper at the start of your stack, like:
        [credential "http://"]
      	helper = "!f() { grep -v ^path= ; }; f"
      	helper = your_real_helper
      But doing this:
      	useHttpPath = false
      is way easier and more readable. Furthermore, since most
      users will want the "off" behavior, that is the new default.
      Users who want it "on" can set the variable (either for all
      credentials, or just for a subset using
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Jeff King's avatar
      credential: apply helper config · 11825072
      Jeff King authored
      The functionality for credential storage helpers is already
      there; we just need to give the users a way to turn it on.
      This patch provides a "credential.helper" configuration
      variable which allows the user to provide one or more helper
      Rather than simply matching credential.helper, we will also
      compare URLs in subsection headings to the current context.
      This means you can apply configuration to a subset of
      credentials. For example:
        [credential "https://example.com"]
      	helper = foo
      would match a request for "https://example.com/foo.git", but
      not one for "https://kernel.org/foo.git".
      This is overkill for the "helper" variable, since users are
      unlikely to want different helpers for different sites (and
      since helpers run arbitrary code, they could do the matching
      themselves anyway).
      However, future patches will add new config variables where
      this extra feature will be more useful.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Jeff King's avatar
      credential: add function for parsing url components · d3e847c1
      Jeff King authored
      All of the components of a credential struct can be found in
      a URL.  For example, the URL:
        http://foo:[email protected]/repo.git
      We want to be able to turn URLs into broken-down credential
      structs so that we know two things:
        1. Which parts of the username/password we still need
        2. What the context of the request is (for prompting or
           as a key for storing credentials).
      This code is based on http_auth_init in http.c, but needed a
      few modifications in order to get all of the components that
      the credential object is interested in.
      Once the http code is switched over to the credential API,
      then http_auth_init can just go away.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Jeff King's avatar
      introduce credentials API · abca927d
      Jeff King authored
      There are a few places in git that need to get a username
      and password credential from the user; the most notable one
      is HTTP authentication for smart-http pushing.
      Right now the only choices for providing credentials are to
      put them plaintext into your ~/.netrc, or to have git prompt
      you (either on the terminal or via an askpass program). The
      former is not very secure, and the latter is not very
      Unfortunately, there is no "always best" solution for
      password management. The details will depend on the tradeoff
      you want between security and convenience, as well as how
      git can integrate with other security systems (e.g., many
      operating systems provide a keychain or password wallet for
      single sign-on).
      This patch provides an abstract notion of credentials as a
      data item, and provides three basic operations:
        - fill (i.e., acquire from external storage or from the
        - approve (mark a credential as "working" for further
        - reject (mark a credential as "not working", so it can
          be removed from storage)
      These operations can be backed by external helper processes
      that interact with system- or user-specific secure storage.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>