Documentation/config/transfer.txt

   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.