You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
71 lines
3.6 KiB
71 lines
3.6 KiB
transfer.fsckObjects:: |
|
When `fetch.fsckObjects` or `receive.fsckObjects` are |
|
not set, the value of this variable is used instead. |
|
Defaults to false. |
|
+ |
|
When set, the fetch or receive will abort in the case of a malformed |
|
object or a link to a nonexistent object. In addition, various other |
|
issues are checked for, including legacy issues (see `fsck.<msg-id>`), |
|
and potential security issues like the existence of a `.GIT` directory |
|
or a malicious `.gitmodules` file (see the release notes for v2.2.1 |
|
and v2.17.1 for details). Other sanity and security checks may be |
|
added in future releases. |
|
+ |
|
On the receiving side, failing fsckObjects will make those objects |
|
unreachable, see "QUARANTINE ENVIRONMENT" in |
|
linkgit:git-receive-pack[1]. On the fetch side, malformed objects will |
|
instead be left unreferenced in the repository. |
|
+ |
|
Due to the non-quarantine nature of the `fetch.fsckObjects` |
|
implementation it can not be relied upon to leave the object store |
|
clean like `receive.fsckObjects` can. |
|
+ |
|
As objects are unpacked they're written to the object store, so there |
|
can be cases where malicious objects get introduced even though the |
|
"fetch" failed, only to have a subsequent "fetch" succeed because only |
|
new incoming objects are checked, not those that have already been |
|
written to the object store. That difference in behavior should not be |
|
relied upon. In the future, such objects may be quarantined for |
|
"fetch" as well. |
|
+ |
|
For now, the paranoid need to find some way to emulate the quarantine |
|
environment if they'd like the same protection as "push". E.g. in the |
|
case of an internal mirror do the mirroring in two steps, one to fetch |
|
the untrusted objects, and then do a second "push" (which will use the |
|
quarantine) to another internal repo, and have internal clients |
|
consume this pushed-to repository, or embargo internal fetches and |
|
only allow them once a full "fsck" has run (and no new fetches have |
|
happened in the meantime). |
|
|
|
transfer.hideRefs:: |
|
String(s) `receive-pack` and `upload-pack` use to decide which |
|
refs to omit from their initial advertisements. Use more than |
|
one definition to specify multiple prefix strings. A ref that is |
|
under the hierarchies listed in the value of this variable is |
|
excluded, and is hidden when responding to `git push` or `git |
|
fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for |
|
program-specific versions of this config. |
|
+ |
|
You may also include a `!` in front of the ref name to negate the entry, |
|
explicitly exposing it, even if an earlier entry marked it as hidden. |
|
If you have multiple hideRefs values, later entries override earlier ones |
|
(and entries in more-specific config files override less-specific ones). |
|
+ |
|
If a namespace is in use, the namespace prefix is stripped from each |
|
reference before it is matched against `transfer.hiderefs` patterns. |
|
For example, if `refs/heads/master` is specified in `transfer.hideRefs` and |
|
the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master` |
|
is omitted from the advertisements but `refs/heads/master` and |
|
`refs/namespaces/bar/refs/heads/master` are still advertised as so-called |
|
"have" lines. In order to match refs before stripping, add a `^` in front of |
|
the ref name. If you combine `!` and `^`, `!` must be specified first. |
|
+ |
|
Even if you hide refs, a client may still be able to steal the target |
|
objects via the techniques described in the "SECURITY" section of the |
|
linkgit:gitnamespaces[7] man page; it's best to keep private data in a |
|
separate repository. |
|
|
|
transfer.unpackLimit:: |
|
When `fetch.unpackLimit` or `receive.unpackLimit` are |
|
not set, the value of this variable is used instead. |
|
The default value is 100.
|
|
|