| 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 |
| 10 | `remote.<name>.url` configuration; it won't detect credentials in |
| 11 | `remote.<name>.pushurl` configuration. |
| 12 | + |
| 13 | You might want to enable this to prevent inadvertent credentials |
| 14 | exposure, e.g. because: |
| 15 | + |
| 16 | * The OS or system where you're running git may not provide a way or |
| 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 |
| 23 | on the command-line, meaning the credentials will be exposed to other |
| 24 | unprivileged users on systems that allow them to see the full |
| 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 |
| 29 | concerned about credentials exposure due to storing sensitive |
| 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 | |
| 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` |
| 58 | implementation it cannot be relied upon to leave the object store |
| 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 |
| 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 | + |
| 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` |
| 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). |
| 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. |
| 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. |
| 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`. |
| 124 | |
| 125 | transfer.advertiseObjectInfo:: |
| 126 | When `true`, the `object-info` capability is advertised by |
| 127 | servers. Defaults to false. |