Re: [PATCH 3/4] config doc: elaborate on what transfer.fsckObjects does

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: May 31, 2018, 07:32 UTC
Message-ID: <87d0xc9t6f.fsf@evledraar.gmail.com>
In-Reply-To: <xmqq4liwpggs.fsf@gitster-ct.c.googlers.com>

On Fri, May 25 2018, Junio C Hamano wrote:

Show 19 quoted lines

> Eric Sunshine <sunshine@sunshineco.com> writes:
>
>>> +will instead be left unreferenced in the repository. That's considered
>>> +a bug, and hopefully future git release will implement a quarantine
>>> +for the "fetch" side as well.
>>
>> If this was a "BUGS" section in a man-page, the above might be less
>> scary. In this context, however, I wonder if it makes sense to tone it
>> down a bit:
>>
>>     On the fetch side, malformed objects will instead be left
>>     unreferenced in the repository. (However, in the future, such
>>     objects may be quarantined for "fetch", as well.)
>
> I had an impression that nobody else sayd it is considered as a
> bug.  Do we need to say it in this series?  I'd rather not--with or
> without such a future modification (or lack of plan thereof),
> teaching the fetch side to pay attention to the various fsck tweaks
> is an improvement.

I changed this in v2 to tone it down, but given what Jeff's mentioned in https://public-inbox.org/git/20180531060259.GE17344@sigill.intra.peff.net/ I'm inclined to bring back some stronger wording for it. Something like:

    Due to the non-quarantine nature of the fetch.fsckObjects
    implementation it can not be relied upon 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" fail, only to have a subsequent "fetch" succeed
    because only new incoming objects are checked, not those that have
    already been written to the store.

    This is considered a bug and will likely be fixed in future versions
    of git. 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).