@matheusbsbs / matheus-bagliano / commits / 720dae5a19

config doc: elaborate on fetch.fsckObjects security

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>

Ævar Arnfjörð Bjarmason committed Jul 27, 2018 at 14:37 UTC 720dae5a19074e404224c9051152d7c64ba2acf0

1 file changed +21

Documentation/config.txt

+21

@@ -3408,6 +3408,27 @@ On the receiving side, failing fsckObjects will make those objects

3408 unreachable, see "QUARANTINE ENVIRONMENT" in

3409 linkgit:git-receive-pack[1]. On the fetch side, malformed objects will

3410 instead be left unreferenced in the repository.

3411 ++

3412 +Due to the non-quarantine nature of the `fetch.fsckObjects`

3413 +implementation it can not be relied upon to leave the object store

3414 +clean like `receive.fsckObjects` can.

3415 ++

3416 +As objects are unpacked they're written to the object store, so there

3417 +can be cases where malicious objects get introduced even though the

3418 +"fetch" failed, only to have a subsequent "fetch" succeed because only

3419 +new incoming objects are checked, not those that have already been

3420 +written to the object store. That difference in behavior should not be

3421 +relied upon. In the future, such objects may be quarantined for

3422 +"fetch" as well.

3423 ++

3424 +For now, the paranoid need to find some way to emulate the quarantine

3425 +environment if they'd like the same protection as "push". E.g. in the

3426 +case of an internal mirror do the mirroring in two steps, one to fetch

3427 +the untrusted objects, and then do a second "push" (which will use the

3428 +quarantine) to another internal repo, and have internal clients

3429 +consume this pushed-to repository, or embargo internal fetches and

3430 +only allow them once a full "fsck" has run (and no new fetches have

3431 +happened in the meantime).

3432

3433 transfer.hideRefs::

3434 String(s) `receive-pack` and `upload-pack` use to decide which