]>
Commit | Line | Data |
---|---|---|
4a5bad07 NTND |
1 | transfer.fsckObjects:: |
2 | When `fetch.fsckObjects` or `receive.fsckObjects` are | |
3 | not set, the value of this variable is used instead. | |
4 | Defaults to false. | |
5 | + | |
6 | When set, the fetch or receive will abort in the case of a malformed | |
7 | object or a link to a nonexistent object. In addition, various other | |
8 | issues are checked for, including legacy issues (see `fsck.<msg-id>`), | |
9 | and potential security issues like the existence of a `.GIT` directory | |
10 | or a malicious `.gitmodules` file (see the release notes for v2.2.1 | |
11 | and v2.17.1 for details). Other sanity and security checks may be | |
12 | added in future releases. | |
13 | + | |
14 | On the receiving side, failing fsckObjects will make those objects | |
15 | unreachable, see "QUARANTINE ENVIRONMENT" in | |
16 | linkgit:git-receive-pack[1]. On the fetch side, malformed objects will | |
17 | instead be left unreferenced in the repository. | |
18 | + | |
19 | Due to the non-quarantine nature of the `fetch.fsckObjects` | |
6d169227 | 20 | implementation it cannot be relied upon to leave the object store |
4a5bad07 NTND |
21 | clean like `receive.fsckObjects` can. |
22 | + | |
23 | As objects are unpacked they're written to the object store, so there | |
24 | can be cases where malicious objects get introduced even though the | |
25 | "fetch" failed, only to have a subsequent "fetch" succeed because only | |
26 | new incoming objects are checked, not those that have already been | |
27 | written to the object store. That difference in behavior should not be | |
28 | relied upon. In the future, such objects may be quarantined for | |
29 | "fetch" as well. | |
30 | + | |
31 | For now, the paranoid need to find some way to emulate the quarantine | |
32 | environment if they'd like the same protection as "push". E.g. in the | |
33 | case of an internal mirror do the mirroring in two steps, one to fetch | |
34 | the untrusted objects, and then do a second "push" (which will use the | |
35 | quarantine) to another internal repo, and have internal clients | |
36 | consume this pushed-to repository, or embargo internal fetches and | |
37 | only allow them once a full "fsck" has run (and no new fetches have | |
38 | happened in the meantime). | |
39 | ||
40 | transfer.hideRefs:: | |
41 | String(s) `receive-pack` and `upload-pack` use to decide which | |
42 | refs to omit from their initial advertisements. Use more than | |
43 | one definition to specify multiple prefix strings. A ref that is | |
44 | under the hierarchies listed in the value of this variable is | |
45 | excluded, and is hidden when responding to `git push` or `git | |
46 | fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for | |
47 | program-specific versions of this config. | |
48 | + | |
49 | You may also include a `!` in front of the ref name to negate the entry, | |
50 | explicitly exposing it, even if an earlier entry marked it as hidden. | |
51 | If you have multiple hideRefs values, later entries override earlier ones | |
52 | (and entries in more-specific config files override less-specific ones). | |
53 | + | |
54 | If a namespace is in use, the namespace prefix is stripped from each | |
55 | reference before it is matched against `transfer.hiderefs` patterns. | |
56 | For example, if `refs/heads/master` is specified in `transfer.hideRefs` and | |
57 | the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master` | |
58 | is omitted from the advertisements but `refs/heads/master` and | |
59 | `refs/namespaces/bar/refs/heads/master` are still advertised as so-called | |
60 | "have" lines. In order to match refs before stripping, add a `^` in front of | |
61 | the ref name. If you combine `!` and `^`, `!` must be specified first. | |
62 | + | |
63 | Even if you hide refs, a client may still be able to steal the target | |
64 | objects via the techniques described in the "SECURITY" section of the | |
65 | linkgit:gitnamespaces[7] man page; it's best to keep private data in a | |
66 | separate repository. | |
67 | ||
68 | transfer.unpackLimit:: | |
69 | When `fetch.unpackLimit` or `receive.unpackLimit` are | |
70 | not set, the value of this variable is used instead. | |
71 | The default value is 100. |