On Fri, May 25 2018, Junio C Hamano wrote:
> Eric Sunshine <sunsh...@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.ge17...@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).
