1. 29 Mar, 2018 1 commit
    • Erik E Brady's avatar
      credential: ignore SIGPIPE when writing to credential helpers · a0d51e8d
      Erik E Brady authored
      The credential subsystem can trigger SIGPIPE when writing to an
      external helper if that helper closes its stdin before reading the
      whole input. Normally this is rare, since helpers would need to read
      that input to make a decision about how to respond, but:
      
      1. It's reasonable to configure a helper which only handles "get"
         while ignoring "store".  Such a handler might not read stdin
         for "store", thereby rapidly closing stdin upon helper exit.
      
      2. A broken or misbehaving helper might exit immediately. That's an
         error, but it's not reasonable for it to take down the parent Git
         process with SIGPIPE.
      
      Even with such a helper, seeing this problem should be rare. Getting
      SIGPIPE requires the helper racily exiting before we've written the
      fairly small credential output.
      Signed-off-by: default avatarErik E Brady <brady@cisco.com>
      Reviewed-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a0d51e8d
  2. 16 Jun, 2017 2 commits
  3. 15 Jun, 2017 1 commit
  4. 26 Feb, 2016 1 commit
    • Jeff King's avatar
      credential: let empty credential specs reset helper list · 24321375
      Jeff King authored
      Sine the credential.helper key is a multi-valued config
      list, there's no way to "unset" a helper once it's been set.
      So if your system /etc/gitconfig sets one, you can never
      avoid running it, but only add your own helpers on top.
      
      Since an empty value for credential.helper is nonsensical
      (it would just try to run "git-credential-"), we can assume
      nobody is using it. Let's define it to reset the helper
      list, letting you override lower-priority instances which
      have come before.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      24321375
  5. 15 Jan, 2016 1 commit
    • Junio C Hamano's avatar
      strbuf: introduce strbuf_getline_{lf,nul}() · 8f309aeb
      Junio C Hamano authored
      The strbuf_getline() interface allows a byte other than LF or NUL as
      the line terminator, but this is only because I wrote these
      codepaths anticipating that there might be a value other than NUL
      and LF that could be useful when I introduced line_termination long
      time ago.  No useful caller that uses other value has emerged.
      
      By now, it is clear that the interface is overly broad without a
      good reason.  Many codepaths have hardcoded preference to read
      either LF terminated or NUL terminated records from their input, and
      then call strbuf_getline() with LF or NUL as the third parameter.
      
      This step introduces two thin wrappers around strbuf_getline(),
      namely, strbuf_getline_lf() and strbuf_getline_nul(), and
      mechanically rewrites these call sites to call either one of
      them.  The changes contained in this patch are:
      
       * introduction of these two functions in strbuf.[ch]
      
       * mechanical conversion of all callers to strbuf_getline() with
         either '\n' or '\0' as the third parameter to instead call the
         respective thin wrapper.
      
      After this step, output from "git grep 'strbuf_getline('" would
      become a lot smaller.  An interim goal of this series is to make
      this an empty set, so that we can have strbuf_getline_crlf() take
      over the shorter name strbuf_getline().
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8f309aeb
  6. 04 Dec, 2014 1 commit
    • Jeff King's avatar
      credential: let helpers tell us to quit · 59b38652
      Jeff King authored
      When we are trying to fill a credential, we loop over the
      set of defined credential-helpers, then fall back to running
      askpass, and then finally prompt on the terminal. Helpers
      which cannot find a credential are free to tell us nothing,
      but they cannot currently ask us to stop prompting.
      
      This patch lets them provide a "quit" attribute, which asks
      us to stop the process entirely (avoiding running more
      helpers, as well as the askpass/terminal prompt).
      
      This has a few possible uses:
      
        1. A helper which prompts the user itself (e.g., in a
           dialog) can provide a "cancel" button to the user to
           stop further prompts.
      
        2. Some helpers may know that prompting cannot possibly
           work. For example, if their role is to broker a ticket
           from an external auth system and that auth system
           cannot be contacted, there is no point in continuing
           (we need a ticket to authenticate, and the user cannot
           provide one by typing it in).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      59b38652
  7. 20 Aug, 2014 1 commit
  8. 20 Jun, 2014 1 commit
    • Jeff King's avatar
      refactor skip_prefix to return a boolean · cf4fff57
      Jeff King authored
      The skip_prefix() function returns a pointer to the content
      past the prefix, or NULL if the prefix was not found. While
      this is nice and simple, in practice it makes it hard to use
      for two reasons:
      
        1. When you want to conditionally skip or keep the string
           as-is, you have to introduce a temporary variable.
           For example:
      
             tmp = skip_prefix(buf, "foo");
             if (tmp)
      	       buf = tmp;
      
        2. It is verbose to check the outcome in a conditional, as
           you need extra parentheses to silence compiler
           warnings. For example:
      
             if ((cp = skip_prefix(buf, "foo"))
      	       /* do something with cp */
      
      Both of these make it harder to use for long if-chains, and
      we tend to use starts_with() instead. However, the first line
      of "do something" is often to then skip forward in buf past
      the prefix, either using a magic constant or with an extra
      strlen(3) (which is generally computed at compile time, but
      means we are repeating ourselves).
      
      This patch refactors skip_prefix() to return a simple boolean,
      and to provide the pointer value as an out-parameter. If the
      prefix is not found, the out-parameter is untouched. This
      lets you write:
      
        if (skip_prefix(arg, "foo ", &arg))
      	  do_foo(arg);
        else if (skip_prefix(arg, "bar ", &arg))
      	  do_bar(arg);
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      cf4fff57
  9. 18 Jul, 2012 1 commit
  10. 25 Jun, 2012 1 commit
  11. 13 Dec, 2011 2 commits
  12. 12 Dec, 2011 5 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
      context.
      
      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
      
             https://example.com/foo.git
      
           would not use the same credential that was stored in an
           earlier request for:
      
             https://example.com/bar.git
      
        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
      prompt.
      
      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:
      
        [credential]
      	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
      credential.*.useHttpPath).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a78fbb4f
    • Jeff King's avatar
      credential: add credential.*.username · d5742425
      Jeff King authored
      Credential helpers can help users avoid having to type their
      username and password over and over. However, some users may
      not want a helper for their password, or they may be running
      a helper which caches for a short time. In this case, it is
      convenient to provide the non-secret username portion of
      their credential via config.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d5742425
    • 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
      strings.
      
      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 <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      11825072
    • 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:bar@example.com/repo.git
      
      contains:
      
        protocol=http
        host=example.com
        path=repo.git
        username=foo
        password=bar
      
      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 <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d3e847c1
    • 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
      convenient.
      
      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
          user)
      
        - approve (mark a credential as "working" for further
          storage)
      
        - 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 <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      abca927d