]>
Commit | Line | Data |
---|---|---|
7281c196 ÆAB |
1 | transfer.credentialsInUrl:: |
2 | A configured URL can contain plaintext credentials in the form | |
3 | `<protocol>://<user>:<password>@<domain>/<path>`. You may want | |
4 | to warn or forbid the use of such configuration (in favor of | |
5 | using linkgit:git-credential[1]). This will be used on | |
6 | linkgit:git-clone[1], linkgit:git-fetch[1], linkgit:git-push[1], | |
7 | and any other direct use of the configured URL. | |
8 | + | |
9 | Note that this is currently limited to detecting credentials in | |
cf6cac20 | 10 | `remote.<name>.url` configuration; it won't detect credentials in |
7281c196 ÆAB |
11 | `remote.<name>.pushurl` configuration. |
12 | + | |
13 | You might want to enable this to prevent inadvertent credentials | |
14 | exposure, e.g. because: | |
15 | + | |
c9dba103 | 16 | * The OS or system where you're running git may not provide a way or |
7281c196 ÆAB |
17 | otherwise allow you to configure the permissions of the |
18 | configuration file where the username and/or password are stored. | |
19 | * Even if it does, having such data stored "at rest" might expose you | |
20 | in other ways, e.g. a backup process might copy the data to another | |
21 | system. | |
22 | * The git programs will pass the full URL to one another as arguments | |
bcb6cdfc | 23 | on the command-line, meaning the credentials will be exposed to other |
97509a34 | 24 | unprivileged users on systems that allow them to see the full |
7281c196 ÆAB |
25 | process list of other users. On linux the "hidepid" setting |
26 | documented in procfs(5) allows for configuring this behavior. | |
27 | + | |
28 | If such concerns don't apply to you then you probably don't need to be | |
cf6cac20 | 29 | concerned about credentials exposure due to storing sensitive |
7281c196 ÆAB |
30 | data in git's configuration files. If you do want to use this, set |
31 | `transfer.credentialsInUrl` to one of these values: | |
32 | + | |
33 | * `allow` (default): Git will proceed with its activity without warning. | |
34 | * `warn`: Git will write a warning message to `stderr` when parsing a URL | |
35 | with a plaintext credential. | |
36 | * `die`: Git will write a failure message to `stderr` when parsing a URL | |
37 | with a plaintext credential. | |
38 | ||
4a5bad07 NTND |
39 | transfer.fsckObjects:: |
40 | When `fetch.fsckObjects` or `receive.fsckObjects` are | |
41 | not set, the value of this variable is used instead. | |
42 | Defaults to false. | |
43 | + | |
44 | When set, the fetch or receive will abort in the case of a malformed | |
45 | object or a link to a nonexistent object. In addition, various other | |
46 | issues are checked for, including legacy issues (see `fsck.<msg-id>`), | |
47 | and potential security issues like the existence of a `.GIT` directory | |
48 | or a malicious `.gitmodules` file (see the release notes for v2.2.1 | |
49 | and v2.17.1 for details). Other sanity and security checks may be | |
50 | added in future releases. | |
51 | + | |
52 | On the receiving side, failing fsckObjects will make those objects | |
53 | unreachable, see "QUARANTINE ENVIRONMENT" in | |
54 | linkgit:git-receive-pack[1]. On the fetch side, malformed objects will | |
55 | instead be left unreferenced in the repository. | |
56 | + | |
57 | Due to the non-quarantine nature of the `fetch.fsckObjects` | |
6d169227 | 58 | implementation it cannot be relied upon to leave the object store |
4a5bad07 NTND |
59 | clean like `receive.fsckObjects` can. |
60 | + | |
61 | As objects are unpacked they're written to the object store, so there | |
62 | can be cases where malicious objects get introduced even though the | |
63 | "fetch" failed, only to have a subsequent "fetch" succeed because only | |
64 | new incoming objects are checked, not those that have already been | |
65 | written to the object store. That difference in behavior should not be | |
66 | relied upon. In the future, such objects may be quarantined for | |
67 | "fetch" as well. | |
68 | + | |
69 | For now, the paranoid need to find some way to emulate the quarantine | |
70 | environment if they'd like the same protection as "push". E.g. in the | |
71 | case of an internal mirror do the mirroring in two steps, one to fetch | |
72 | the untrusted objects, and then do a second "push" (which will use the | |
73 | quarantine) to another internal repo, and have internal clients | |
74 | consume this pushed-to repository, or embargo internal fetches and | |
75 | only allow them once a full "fsck" has run (and no new fetches have | |
76 | happened in the meantime). | |
77 | ||
78 | transfer.hideRefs:: | |
79 | String(s) `receive-pack` and `upload-pack` use to decide which | |
80 | refs to omit from their initial advertisements. Use more than | |
81 | one definition to specify multiple prefix strings. A ref that is | |
82 | under the hierarchies listed in the value of this variable is | |
83 | excluded, and is hidden when responding to `git push` or `git | |
84 | fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for | |
85 | program-specific versions of this config. | |
86 | + | |
87 | You may also include a `!` in front of the ref name to negate the entry, | |
88 | explicitly exposing it, even if an earlier entry marked it as hidden. | |
89 | If you have multiple hideRefs values, later entries override earlier ones | |
90 | (and entries in more-specific config files override less-specific ones). | |
91 | + | |
92 | If a namespace is in use, the namespace prefix is stripped from each | |
53a66ec3 KA |
93 | reference before it is matched against `transfer.hiderefs` patterns. In |
94 | order to match refs before stripping, add a `^` in front of the ref name. If | |
95 | you combine `!` and `^`, `!` must be specified first. | |
96 | + | |
4a5bad07 NTND |
97 | For example, if `refs/heads/master` is specified in `transfer.hideRefs` and |
98 | the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master` | |
53a66ec3 KA |
99 | is omitted from the advertisements. If `uploadpack.allowRefInWant` is set, |
100 | `upload-pack` will treat `want-ref refs/heads/master` in a protocol v2 | |
101 | `fetch` command as if `refs/namespaces/foo/refs/heads/master` did not exist. | |
102 | `receive-pack`, on the other hand, will still advertise the object id the | |
103 | ref is pointing to without mentioning its name (a so-called ".have" line). | |
4a5bad07 NTND |
104 | + |
105 | Even if you hide refs, a client may still be able to steal the target | |
106 | objects via the techniques described in the "SECURITY" section of the | |
107 | linkgit:gitnamespaces[7] man page; it's best to keep private data in a | |
108 | separate repository. | |
109 | ||
110 | transfer.unpackLimit:: | |
111 | When `fetch.unpackLimit` or `receive.unpackLimit` are | |
112 | not set, the value of this variable is used instead. | |
113 | The default value is 100. | |
81bd5490 JS |
114 | |
115 | transfer.advertiseSID:: | |
116 | Boolean. When true, client and server processes will advertise their | |
117 | unique session IDs to their remote counterpart. Defaults to false. | |
7cce9074 ÆAB |
118 | |
119 | transfer.bundleURI:: | |
120 | When `true`, local `git clone` commands will request bundle | |
121 | information from the remote server (if advertised) and download | |
122 | bundles before continuing the clone through the Git protocol. | |
123 | Defaults to `false`. |