diff options
author | Ævar Arnfjörð Bjarmason <avarab@gmail.com> | 2022-06-15 10:44:12 (GMT) |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2022-06-15 18:40:11 (GMT) |
commit | 7281c196b1166f1c00df33948c67b0ef81ba63a9 (patch) | |
tree | 2275ad64240b68deb80082d52cd5a805a452c72b /Documentation | |
parent | 4a169da280aa6d22bdf0cf5baea65f47bd363a3a (diff) | |
download | git-7281c196b1166f1c00df33948c67b0ef81ba63a9.zip git-7281c196b1166f1c00df33948c67b0ef81ba63a9.tar.gz git-7281c196b1166f1c00df33948c67b0ef81ba63a9.tar.bz2 |
transfer doc: move fetch.credentialsInUrl to "transfer" config namespace
Rename the "fetch.credentialsInUrl" configuration variable introduced
in 6dcbdc0d661 (remote: create fetch.credentialsInUrl config,
2022-06-06) to "transfer".
There are existing exceptions, but generally speaking the
"<namespace>.<var>" configuration should only apply to command
described in the "namespace" (and its sub-commands, so e.g. "clone.*"
or "fetch.*" might also configure "git-remote-https").
But in the case of "fetch.credentialsInUrl" we've got a configuration
variable that configures the behavior of all of "clone", "push" and
"fetch", someone adjusting "fetch.*" configuration won't expect to
have the behavior of "git push" altered, especially as we have the
pre-existing "{transfer,fetch,receive}.fsckObjects", which configures
different parts of the transfer dialog.
So let's move this configuration variable to the "transfer" namespace
before it's exposed in a release. We could add all of
"{transfer,fetch,pull}.credentialsInUrl" at some other time, but once
we have "fetch" configure "pull" such an arrangement would would be a
confusing mess, as we'd at least need to have "fetch" configure
"push" (but not the other way around), or change existing behavior.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/RelNotes/2.37.0.txt | 2 | ||||
-rw-r--r-- | Documentation/config/fetch.txt | 36 | ||||
-rw-r--r-- | Documentation/config/transfer.txt | 38 |
3 files changed, 39 insertions, 37 deletions
diff --git a/Documentation/RelNotes/2.37.0.txt b/Documentation/RelNotes/2.37.0.txt index 39ca360..9902a74 100644 --- a/Documentation/RelNotes/2.37.0.txt +++ b/Documentation/RelNotes/2.37.0.txt @@ -54,7 +54,7 @@ UI, Workflows & Features * Update the doctype written in gitweb output to xhtml5. - * The "fetch.credentialsInUrl" configuration variable controls what + * The "transfer.credentialsInUrl" configuration variable controls what happens when a URL with embedded login credential is used on either "fetch" or "push". Credentials are currently only detected in `remote.<name>.url` config, not `remote.<name>.pushurl`. diff --git a/Documentation/config/fetch.txt b/Documentation/config/fetch.txt index 8279610..cd65d23 100644 --- a/Documentation/config/fetch.txt +++ b/Documentation/config/fetch.txt @@ -96,39 +96,3 @@ fetch.writeCommitGraph:: merge and the write may take longer. Having an updated commit-graph file helps performance of many Git commands, including `git merge-base`, `git push -f`, and `git log --graph`. Defaults to false. - -fetch.credentialsInUrl:: - A configured URL can contain plaintext credentials in the form - `<protocol>://<user>:<password>@<domain>/<path>`. You may want - to warn or forbid the use of such configuration (in favor of - using linkgit:git-credential[1]). -+ -Note that this is currently limited to detecting credentials in -`remote.<name>.url` configuration, it won't detect credentials in -`remote.<name>.pushurl` configuration. -+ -You might want to enable this to prevent inadvertent credentials -exposure, e.g. because: -+ -* The OS or system where you're running git may not provide way way or - otherwise allow you to configure the permissions of the - configuration file where the username and/or password are stored. -* Even if it does, having such data stored "at rest" might expose you - in other ways, e.g. a backup process might copy the data to another - system. -* The git programs will pass the full URL to one another as arguments - on the command-line, meaning the credentials will be exposed to oher - users on OS's or systems that allow other users to see the full - process list of other users. On linux the "hidepid" setting - documented in procfs(5) allows for configuring this behavior. -+ -If such concerns don't apply to you then you probably don't need to be -concerned about credentials exposure due to storing that sensitive -data in git's configuration files. If you do want to use this, set -`fetch.credentialsInUrl` to one of these values: -+ -* `allow` (default): Git will proceed with its activity without warning. -* `warn`: Git will write a warning message to `stderr` when parsing a URL - with a plaintext credential. -* `die`: Git will write a failure message to `stderr` when parsing a URL - with a plaintext credential. diff --git a/Documentation/config/transfer.txt b/Documentation/config/transfer.txt index b49429e..b4475c0 100644 --- a/Documentation/config/transfer.txt +++ b/Documentation/config/transfer.txt @@ -1,3 +1,41 @@ +transfer.credentialsInUrl:: + A configured URL can contain plaintext credentials in the form + `<protocol>://<user>:<password>@<domain>/<path>`. You may want + to warn or forbid the use of such configuration (in favor of + using linkgit:git-credential[1]). This will be used on + linkgit:git-clone[1], linkgit:git-fetch[1], linkgit:git-push[1], + and any other direct use of the configured URL. ++ +Note that this is currently limited to detecting credentials in +`remote.<name>.url` configuration, it won't detect credentials in +`remote.<name>.pushurl` configuration. ++ +You might want to enable this to prevent inadvertent credentials +exposure, e.g. because: ++ +* The OS or system where you're running git may not provide way way or + otherwise allow you to configure the permissions of the + configuration file where the username and/or password are stored. +* Even if it does, having such data stored "at rest" might expose you + in other ways, e.g. a backup process might copy the data to another + system. +* The git programs will pass the full URL to one another as arguments + on the command-line, meaning the credentials will be exposed to oher + users on OS's or systems that allow other users to see the full + process list of other users. On linux the "hidepid" setting + documented in procfs(5) allows for configuring this behavior. ++ +If such concerns don't apply to you then you probably don't need to be +concerned about credentials exposure due to storing that sensitive +data in git's configuration files. If you do want to use this, set +`transfer.credentialsInUrl` to one of these values: ++ +* `allow` (default): Git will proceed with its activity without warning. +* `warn`: Git will write a warning message to `stderr` when parsing a URL + with a plaintext credential. +* `die`: Git will write a failure message to `stderr` when parsing a URL + with a plaintext credential. + transfer.fsckObjects:: When `fetch.fsckObjects` or `receive.fsckObjects` are not set, the value of this variable is used instead. |