git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: <git@vger.kernel.org>
Cc: Junio C Hamano <gitster@pobox.com>,
	Matthew John Cheetham <mjcheetham@outlook.com>,
	M Hickford <mirth.hickford@gmail.com>, Jeff King <peff@peff.net>,
	Patrick Steinhardt <ps@pks.im>
Subject: [PATCH v2 16/16] credential: add method for querying capabilities
Date: Wed, 17 Apr 2024 00:02:40 +0000	[thread overview]
Message-ID: <20240417000240.3611948-17-sandals@crustytoothpaste.net> (raw)
In-Reply-To: <20240417000240.3611948-1-sandals@crustytoothpaste.net>

Right now, there's no specific way to determine whether a credential
helper or git credential itself supports a given set of capabilities.
It would be helpful to have such a way, so let's let credential helpers
and git credential take an argument, "capability", which has it list the
capabilities and a version number on standard output.

Specifically choose a format that is slightly different from regular
credential output and assume that no capabilities are supported if a
non-zero exit status occurs or the data deviates from the format.  It is
common for users to write small shell scripts as the argument to
credential.helper, which will almost never be designed to emit
capabilities.  We want callers to gracefully handle this case by
assuming that they are not capable of extended support because that is
almost certainly the case, and specifying the error behavior up front
does this and preserves backwards compatibility in a graceful way.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
 Documentation/git-credential.txt | 28 +++++++++++++++++++++++++++-
 builtin/credential-cache.c       | 10 ++++++++++
 builtin/credential.c             |  6 ++++++
 credential.c                     | 11 +++++++++++
 credential.h                     |  6 ++++++
 5 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-credential.txt b/Documentation/git-credential.txt
index 3d3accc273..e41493292f 100644
--- a/Documentation/git-credential.txt
+++ b/Documentation/git-credential.txt
@@ -8,7 +8,7 @@ git-credential - Retrieve and store user credentials
 SYNOPSIS
 --------
 ------------------
-'git credential' (fill|approve|reject)
+'git credential' (fill|approve|reject|capability)
 ------------------
 
 DESCRIPTION
@@ -41,6 +41,9 @@ If the action is `reject`, git-credential will send the description to
 any configured credential helpers, which may erase any stored
 credentials matching the description.
 
+If the action is `capability`, git-credential will announce any capabilities
+it supports to standard output.
+
 If the action is `approve` or `reject`, no output should be emitted.
 
 TYPICAL USE OF GIT CREDENTIAL
@@ -263,6 +266,29 @@ is supported, but they should not be provided without the capability.
 
 Unrecognised attributes and capabilities are silently discarded.
 
+[[CAPA-IOFMT]]
+CAPABILITY INPUT/OUTPUT FORMAT
+------------------------------
+
+For `git credential capability`, the format is slightly different. First, a
+`version 0` announcement is made to indicate the current version of the
+protocol, and then each capability is announced with a line like `capability
+authtype`. Credential helpers may also implement this format, again with the
+`capability` argument. Additional lines may be added in the future; callers
+should ignore lines which they don't understand.
+
+Because this is a new part of the credential helper protocol, older versions of
+Git, as well as some credential helpers, may not support it.  If a non-zero
+exit status is received, or if the first line doesn't start with the word
+`version` and a space, callers should assume that no capabilities are supported.
+
+The intention of this format is to differentiate it from the credential output
+in an unambiguous way.  It is possible to use very simple credential helpers
+(e.g., inline shell scripts) which always produce identical output.  Using a
+distinct format allows users to continue to use this syntax without having to
+worry about correctly implementing capability advertisements or accidentally
+confusing callers querying for capabilities.
+
 GIT
 ---
 Part of the linkgit:git[1] suite
diff --git a/builtin/credential-cache.c b/builtin/credential-cache.c
index bba96d4ffd..f5c989e2b2 100644
--- a/builtin/credential-cache.c
+++ b/builtin/credential-cache.c
@@ -1,4 +1,5 @@
 #include "builtin.h"
+#include "credential.h"
 #include "gettext.h"
 #include "parse-options.h"
 #include "path.h"
@@ -127,6 +128,13 @@ static char *get_socket_path(void)
 	return socket;
 }
 
+static void announce_capabilities(void)
+{
+	struct credential c = CREDENTIAL_INIT;
+	c.capa_authtype.request_initial = 1;
+	credential_announce_capabilities(&c, stdout);
+}
+
 int cmd_credential_cache(int argc, const char **argv, const char *prefix)
 {
 	char *socket_path = NULL;
@@ -160,6 +168,8 @@ int cmd_credential_cache(int argc, const char **argv, const char *prefix)
 		do_cache(socket_path, op, timeout, FLAG_RELAY);
 	else if (!strcmp(op, "store"))
 		do_cache(socket_path, op, timeout, FLAG_RELAY|FLAG_SPAWN);
+	else if (!strcmp(op, "capability"))
+		announce_capabilities();
 	else
 		; /* ignore unknown operation */
 
diff --git a/builtin/credential.c b/builtin/credential.c
index 3568e57025..5100d441f2 100644
--- a/builtin/credential.c
+++ b/builtin/credential.c
@@ -17,6 +17,12 @@ int cmd_credential(int argc, const char **argv, const char *prefix UNUSED)
 		usage(usage_msg);
 	op = argv[1];
 
+	if (!strcmp(op, "capability")) {
+		credential_set_all_capabilities(&c, CREDENTIAL_OP_INITIAL);
+		credential_announce_capabilities(&c, stdout);
+		return 0;
+	}
+
 	if (credential_read(&c, stdin, CREDENTIAL_OP_INITIAL) < 0)
 		die("unable to read credential from stdin");
 
diff --git a/credential.c b/credential.c
index ffaf31499e..758528b291 100644
--- a/credential.c
+++ b/credential.c
@@ -72,6 +72,17 @@ void credential_set_all_capabilities(struct credential *c,
 	credential_set_capability(&c->capa_state, op_type);
 }
 
+static void announce_one(struct credential_capability *cc, const char *name, FILE *fp) {
+	if (cc->request_initial)
+		fprintf(fp, "capability %s\n", name);
+}
+
+void credential_announce_capabilities(struct credential *c, FILE *fp) {
+	fprintf(fp, "version 0\n");
+	announce_one(&c->capa_authtype, "authtype", fp);
+	announce_one(&c->capa_state, "state", fp);
+}
+
 int credential_match(const struct credential *want,
 		     const struct credential *have, int match_password)
 {
diff --git a/credential.h b/credential.h
index f8df10937c..af8c287ff2 100644
--- a/credential.h
+++ b/credential.h
@@ -253,6 +253,12 @@ void credential_set_all_capabilities(struct credential *c,
  */
 void credential_clear_secrets(struct credential *c);
 
+/**
+ * Print a list of supported capabilities and version numbers to standard
+ * output.
+ */
+void credential_announce_capabilities(struct credential *c, FILE *fp);
+
 /**
  * Prepares the credential for the next iteration of the helper protocol by
  * updating the state headers to send with the ones read by the last iteration


      parent reply	other threads:[~2024-04-17  0:04 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-24  1:12 [PATCH 00/13] Support for arbitrary schemes in credentials brian m. carlson
2024-03-24  1:12 ` [PATCH 01/13] credential: add an authtype field brian m. carlson
2024-03-24  1:12 ` [PATCH 02/13] remote-curl: reset headers on new request brian m. carlson
2024-03-24  1:12 ` [PATCH 03/13] http: use new headers for each object request brian m. carlson
2024-03-27  8:02   ` Patrick Steinhardt
2024-03-24  1:12 ` [PATCH 04/13] credential: add a field for pre-encoded credentials brian m. carlson
2024-03-24  1:12 ` [PATCH 05/13] credential: gate new fields on capability brian m. carlson
2024-03-27  8:02   ` Patrick Steinhardt
2024-03-27 21:33     ` brian m. carlson
2024-04-02 10:04       ` Patrick Steinhardt
2024-04-04  0:39         ` brian m. carlson
2024-04-04  4:07           ` Patrick Steinhardt
2024-03-28 10:20   ` Jeff King
2024-03-28 16:13     ` Junio C Hamano
2024-03-28 16:29       ` Jeff King
2024-03-28 17:25         ` Junio C Hamano
2024-03-28 21:18     ` brian m. carlson
2024-03-24  1:12 ` [PATCH 06/13] docs: indicate new credential protocol fields brian m. carlson
2024-03-25 23:16   ` M Hickford
2024-03-25 23:37     ` brian m. carlson
2024-03-30 13:00       ` M Hickford
2024-03-31 21:43         ` brian m. carlson
2024-03-24  1:12 ` [PATCH 07/13] http: add support for authtype and credential brian m. carlson
2024-03-24  1:12 ` [PATCH 08/13] credential: add an argument to keep state brian m. carlson
2024-04-01 21:05   ` mirth hickford
2024-04-01 22:14     ` brian m. carlson
2024-03-24  1:12 ` [PATCH 09/13] credential: enable state capability brian m. carlson
2024-03-24  1:12 ` [PATCH 10/13] docs: set a limit on credential line length brian m. carlson
2024-03-24  1:12 ` [PATCH 11/13] t5563: refactor for multi-stage authentication brian m. carlson
2024-03-24  1:13 ` [PATCH 12/13] strvec: implement swapping two strvecs brian m. carlson
2024-03-27  8:02   ` Patrick Steinhardt
2024-03-27 21:22     ` Junio C Hamano
2024-03-27 21:34       ` brian m. carlson
2024-03-24  1:13 ` [PATCH 13/13] credential: add support for multistage credential rounds brian m. carlson
2024-03-28  8:00   ` M Hickford
2024-03-28 21:53     ` brian m. carlson
2024-04-01 20:51       ` M Hickford
2024-03-24  2:24 ` [PATCH 00/13] Support for arbitrary schemes in credentials Junio C Hamano
2024-03-24 15:21   ` brian m. carlson
2024-03-24 16:13     ` Junio C Hamano
2024-03-30  8:00 ` M Hickford
2024-03-30  8:16 ` M Hickford
2024-04-02 22:26 ` Calvin Wan
2024-04-04  1:01   ` brian m. carlson
2024-04-08 18:42     ` Jackson Toeniskoetter
2024-04-11  7:00       ` M Hickford
2024-04-12  0:09       ` brian m. carlson
2024-04-11  7:00 ` M Hickford
2024-04-12  0:13   ` brian m. carlson
2024-04-17  0:02 ` [PATCH v2 00/16] " brian m. carlson
2024-04-17  0:02   ` [PATCH v2 01/16] credential: add an authtype field brian m. carlson
2024-04-17  0:02   ` [PATCH v2 02/16] remote-curl: reset headers on new request brian m. carlson
2024-04-17  0:02   ` [PATCH v2 03/16] http: use new headers for each object request brian m. carlson
2024-04-17  0:02   ` [PATCH v2 04/16] credential: add a field for pre-encoded credentials brian m. carlson
2024-04-17  0:02   ` [PATCH v2 05/16] credential: gate new fields on capability brian m. carlson
2024-04-17  0:02   ` [PATCH v2 06/16] credential: add a field called "ephemeral" brian m. carlson
2024-04-17  0:02   ` [PATCH v2 07/16] docs: indicate new credential protocol fields brian m. carlson
2024-04-17  0:02   ` [PATCH v2 08/16] http: add support for authtype and credential brian m. carlson
2024-04-17  0:02   ` [PATCH v2 09/16] credential: add an argument to keep state brian m. carlson
2024-04-17  0:02   ` [PATCH v2 10/16] credential: enable state capability brian m. carlson
2024-04-17  0:02   ` [PATCH v2 11/16] docs: set a limit on credential line length brian m. carlson
2024-04-17  0:02   ` [PATCH v2 12/16] t5563: refactor for multi-stage authentication brian m. carlson
2024-04-17  0:02   ` [PATCH v2 13/16] credential: add support for multistage credential rounds brian m. carlson
2024-04-17  0:02   ` [PATCH v2 14/16] t: add credential tests for authtype brian m. carlson
2024-04-17  0:02   ` [PATCH v2 15/16] credential-cache: implement authtype capability brian m. carlson
2024-04-17  0:02   ` brian m. carlson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240417000240.3611948-17-sandals@crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mirth.hickford@gmail.com \
    --cc=mjcheetham@outlook.com \
    --cc=peff@peff.net \
    --cc=ps@pks.im \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).