config doc: elaborate on fetch.fsckObjects security

avar · gitster · commit 720dae5a1907 · 2018-07-27T11:36:05.000-07:00
Change the transfer.fsckObjects documentation to explicitly note the unique security and/or corruption issues fetch.fsckObjects suffers from, since it doesn't have a quarantine environment. This was already alluded to in the existing documentation, but let's spell it out so there's no confusion here, and give a concrete example of how to work around this limitation. Let's also prominently note that this is considered to be a limitation of the current implementation, rather than something that's intended and by design, since we might change this in the future. See https://public-inbox.org/git/20180531060259.GE17344@sigill.intra.peff.net/ for further details. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/Documentation/config.txt b/Documentation/config.txt
@@ -3408,6 +3408,27 @@ 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
