author | Jeff King <peff@peff.net> | |
Sat, 10 Dec 2011 10:31:11 +0000 (05:31 -0500) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Mon, 12 Dec 2011 07:16:24 +0000 (23:16 -0800) | ||
commit | abca927dbef2c310056b8a1a8be5561212b3243a | |
tree | 97ca8e6995555078ba560db471d9b6a31f591f2e | tree | snapshot |
parent | 89650285d8ef98173190a80f1d070a33092c9314 | commit | diff |
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>
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>
.gitignore | diff | blob | history | |
Documentation/technical/api-credentials.txt | [new file with mode: 0644] | blob |
Makefile | diff | blob | history | |
credential.c | [new file with mode: 0644] | blob |
credential.h | [new file with mode: 0644] | blob |
t/lib-credential.sh | [new file with mode: 0755] | blob |
t/t0300-credentials.sh | [new file with mode: 0755] | blob |
test-credential.c | [new file with mode: 0644] | blob |