summaryrefslogtreecommitdiff
path: root/t/t4123-apply-shrink.sh
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2011-12-10 05:31:11 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2011-12-11 23:16:24 -0800
commitabca927dbef2c310056b8a1a8be5561212b3243a (patch)
tree97ca8e6995555078ba560db471d9b6a31f591f2e /t/t4123-apply-shrink.sh
parentt5550: fix typo (diff)
downloadtgif-abca927dbef2c310056b8a1a8be5561212b3243a.tar.xz
introduce credentials API
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>
Diffstat (limited to 't/t4123-apply-shrink.sh')
0 files changed, 0 insertions, 0 deletions