@@ -8,7 +8,7 @@ git-credential - Retrieve and store user credentials
8
8
SYNOPSIS
9
9
--------
10
10
------------------
11
- 'git credential' (fill|approve|reject)
11
+ 'git credential' (fill|approve|reject|capability )
12
12
------------------
13
13
14
14
DESCRIPTION
@@ -41,6 +41,9 @@ If the action is `reject`, git-credential will send the description to
41
41
any configured credential helpers, which may erase any stored
42
42
credentials matching the description.
43
43
44
+ If the action is `capability`, git-credential will announce any capabilities
45
+ it supports to standard output.
46
+
44
47
If the action is `approve` or `reject`, no output should be emitted.
45
48
46
49
TYPICAL USE OF GIT CREDENTIAL
@@ -111,7 +114,9 @@ attribute per line. Each attribute is specified by a key-value pair,
111
114
separated by an `=` (equals) sign, followed by a newline.
112
115
113
116
The key may contain any bytes except `=`, newline, or NUL. The value may
114
- contain any bytes except newline or NUL.
117
+ contain any bytes except newline or NUL. A line, including the trailing
118
+ newline, may not exceed 65535 bytes in order to allow implementations to
119
+ parse efficiently.
115
120
116
121
Attributes with keys that end with C-style array brackets `[]` can have
117
122
multiple values. Each instance of a multi-valued attribute forms an
@@ -178,6 +183,61 @@ empty string.
178
183
Components which are missing from the URL (e.g., there is no
179
184
username in the example above) will be left unset.
180
185
186
+ `authtype`::
187
+ This indicates that the authentication scheme in question should be used.
188
+ Common values for HTTP and HTTPS include `basic`, `bearer`, and `digest`,
189
+ although the latter is insecure and should not be used. If `credential`
190
+ is used, this may be set to an arbitrary string suitable for the protocol in
191
+ question (usually HTTP).
192
+ +
193
+ This value should not be sent unless the appropriate capability (see below) is
194
+ provided on input.
195
+
196
+ `credential`::
197
+ The pre-encoded credential, suitable for the protocol in question (usually
198
+ HTTP). If this key is sent, `authtype` is mandatory, and `username` and
199
+ `password` are not used. For HTTP, Git concatenates the `authtype` value and
200
+ this value with a single space to determine the `Authorization` header.
201
+ +
202
+ This value should not be sent unless the appropriate capability (see below) is
203
+ provided on input.
204
+
205
+ `ephemeral`::
206
+ This boolean value indicates, if true, that the value in the `credential`
207
+ field should not be saved by the credential helper because its usefulness is
208
+ limited in time. For example, an HTTP Digest `credential` value is computed
209
+ using a nonce and reusing it will not result in successful authentication.
210
+ This may also be used for situations with short duration (e.g., 24-hour)
211
+ credentials. The default value is false.
212
+ +
213
+ The credential helper will still be invoked with `store` or `erase` so that it
214
+ can determine whether the operation was successful.
215
+ +
216
+ This value should not be sent unless the appropriate capability (see below) is
217
+ provided on input.
218
+
219
+ `state[]`::
220
+ This value provides an opaque state that will be passed back to this helper
221
+ if it is called again. Each different credential helper may specify this
222
+ once. The value should include a prefix unique to the credential helper and
223
+ should ignore values that don't match its prefix.
224
+ +
225
+ This value should not be sent unless the appropriate capability (see below) is
226
+ provided on input.
227
+
228
+ `continue`::
229
+ This is a boolean value, which, if enabled, indicates that this
230
+ authentication is a non-final part of a multistage authentication step. This
231
+ is common in protocols such as NTLM and Kerberos, where two rounds of client
232
+ authentication are required, and setting this flag allows the credential
233
+ helper to implement the multistage authentication step. This flag should
234
+ only be sent if a further stage is required; that is, if another round of
235
+ authentication is expected.
236
+ +
237
+ This value should not be sent unless the appropriate capability (see below) is
238
+ provided on input. This attribute is 'one-way' from a credential helper to
239
+ pass information to Git (or other programs invoking `git credential`).
240
+
181
241
`wwwauth[]`::
182
242
183
243
When an HTTP response is received by Git that includes one or more
@@ -189,7 +249,45 @@ attribute 'wwwauth[]', where the order of the attributes is the same as
189
249
they appear in the HTTP response. This attribute is 'one-way' from Git
190
250
to pass additional information to credential helpers.
191
251
192
- Unrecognised attributes are silently discarded.
252
+ `capability[]`::
253
+ This signals that Git, or the helper, as appropriate, supports the capability
254
+ in question. This can be used to provide better, more specific data as part
255
+ of the protocol. A `capability[]` directive must precede any value depending
256
+ on it and these directives _should_ be the first item announced in the
257
+ protocol.
258
+ +
259
+ There are two currently supported capabilities. The first is `authtype`, which
260
+ indicates that the `authtype`, `credential`, and `ephemeral` values are
261
+ understood. The second is `state`, which indicates that the `state[]` and
262
+ `continue` values are understood.
263
+ +
264
+ It is not obligatory to use the additional features just because the capability
265
+ is supported, but they should not be provided without the capability.
266
+
267
+ Unrecognised attributes and capabilities are silently discarded.
268
+
269
+ [[CAPA-IOFMT]]
270
+ CAPABILITY INPUT/OUTPUT FORMAT
271
+ ------------------------------
272
+
273
+ For `git credential capability`, the format is slightly different. First, a
274
+ `version 0` announcement is made to indicate the current version of the
275
+ protocol, and then each capability is announced with a line like `capability
276
+ authtype`. Credential helpers may also implement this format, again with the
277
+ `capability` argument. Additional lines may be added in the future; callers
278
+ should ignore lines which they don't understand.
279
+
280
+ Because this is a new part of the credential helper protocol, older versions of
281
+ Git, as well as some credential helpers, may not support it. If a non-zero
282
+ exit status is received, or if the first line doesn't start with the word
283
+ `version` and a space, callers should assume that no capabilities are supported.
284
+
285
+ The intention of this format is to differentiate it from the credential output
286
+ in an unambiguous way. It is possible to use very simple credential helpers
287
+ (e.g., inline shell scripts) which always produce identical output. Using a
288
+ distinct format allows users to continue to use this syntax without having to
289
+ worry about correctly implementing capability advertisements or accidentally
290
+ confusing callers querying for capabilities.
193
291
194
292
GIT
195
293
---
0 commit comments