summaryrefslogtreecommitdiff
path: root/credential.h
AgeCommit message (Collapse)AuthorFilesLines
2020-05-04credential: correct order of parameters for credential_matchLibravatar Carlo Marcelo Arenas Belón1-2/+2
Since the beginning in 118250728e (credential: apply helper config, 2011-12-10), the declaration for that function used a different order than the implementation. All callers use the same order than the implementation, so update the declaration in credential.h to match. Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-04credential: update description for credential_from_url_gentlyLibravatar Carlo Marcelo Arenas Belón1-2/+2
c44088ecc4 (credential: treat URL without scheme as invalid, 2020-04-18) changes the implementation for this function to return -1 if protocol is missing. Update blurb to match implementation. Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-25Git 2.26.1Libravatar Junio C Hamano1-1/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-17Git 2.25.3Libravatar Junio C Hamano1-1/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-12credential: detect unrepresentable values when parsing urlsLibravatar Jeff King1-0/+16
The credential protocol can't represent newlines in values, but URLs can embed percent-encoded newlines in various components. A previous commit taught the low-level writing routines to die() when encountering this, but we can be a little friendlier to the user by detecting them earlier and handling them gracefully. This patch teaches credential_from_url() to notice such components, issue a warning, and blank the credential (which will generally result in prompting the user for a username and password). We blank the whole credential in this case. Another option would be to blank only the invalid component. However, we're probably better off not feeding a partially-parsed URL result to a credential helper. We don't know how a given helper would handle it, so we're better off to err on the side of matching nothing rather than something unexpected. The die() call in credential_write() is _probably_ impossible to reach after this patch. Values should end up in credential structs only by URL parsing (which is covered here), or by reading credential protocol input (which by definition cannot read a newline into a value). But we should definitely keep the low-level check, as it's our final and most accurate line of defense against protocol injection attacks. Arguably it could become a BUG(), but it probably doesn't matter much either way. Note that the public interface of credential_from_url() grows a little more than we need here. We'll use the extra flexibility in a future patch to help fsck catch these cases.
2020-03-05Merge branch 'bc/wildcard-credential'Libravatar Junio C Hamano1-1/+2
A configuration element used for credential subsystem can now use wildcard pattern to specify for which set of URLs the entry applies. * bc/wildcard-credential: credential: allow wildcard patterns when matching config credential: use the last matching username in the config t0300: add tests for some additional cases t1300: add test for urlmatch with multiple wildcards mailmap: add an additional email address for brian m. carlson
2020-02-20credential: use the last matching username in the configLibravatar brian m. carlson1-1/+2
Everywhere else in the codebase, we use the rule that the last matching configuration option is the one that takes effect. This is helpful because it allows more specific configuration settings (e.g., per-repo configuration) to override less specific settings (e.g., per-user configuration). However, in the credential code, we didn't honor this setting, and instead picked the first setting we had, and stuck with it. This was likely to ensure we picked the value from the URL, which we want to honor over the configuration. It's possible to do both, though, so let's check if the value is the one we've gotten over our protocol connection, which if present will have come from the URL, and keep it if so. Otherwise, let's overwrite the value with the latest version we've got from the configuration, so we keep the last configuration value. Signed-off-by: brian m. carlson <bk2204@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-14doc: move credential helper info into gitcredentials(7)Libravatar Jeff King1-90/+0
The details of how credential helpers can be called or implemented were originally covered in Documentation/technical/. Those are topics that end users might care about (and we even referenced them in the credentials manpage), but those docs typically don't ship as part of the end user documentation, making them less useful. This situation got slightly worse recently in f3b9055624 (credential: move doc to credential.h, 2019-11-17), where we moved them into the C header file, making them even harder to find. So let's move put this information into the gitcredentials(7) documentation, which is meant to describe the overall concepts of our credential handling. This was already pointing to the API docs for these concepts, so we can just include it inline instead. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-18credential: move doc to credential.hLibravatar Heba Waly1-0/+236
Move the documentation from Documentation/technical/api-credentials.txt to credential.h as it's easier for the developers to find the usage information beside the code instead of looking for it in another doc file. Documentation/technical/api-credentials.txt is removed because the information it has is now redundant and it'll be hard to keep it up to date and synchronized with the documentation in the header file. Documentation/git-credential.txt and Documentation/gitcredentials.txt now link to credential.h instead of Documentation/technical/api-credentials.txt for details about the credetials API. Signed-off-by: Heba Waly <heba.waly@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-04credential: let helpers tell us to quitLibravatar Jeff King1-0/+1
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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-25git credential fill: output the whole 'struct credential'Libravatar Matthieu Moy1-0/+1
Instead of outputing only the username and password, print all the attributes, even those that already appeared in the input. This is closer to what the C API does, and allows one to take the exact output of "git credential fill" as input to "git credential approve" or "git credential reject". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11credential: make relevance of http path configurableLibravatar Jeff King1-1/+2
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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11credential: apply helper configLibravatar Jeff King1-1/+4
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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11credential: add function for parsing url componentsLibravatar Jeff King1-0/+1
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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11introduce credentials APILibravatar Jeff King1-0/+28
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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>