Re: Teach git-fetch(1) to use a quarantine directory

From: Patrick Steinhardt <ps@pks.im>
Date: Jul 19, 2023, 07:24 UTC
Message-ID: <7tprum2so74wdccd3vmzgrt7d4ds6lgsq2y6bsxcxflbxw7ds4@qv3sqnph7gyc>
In-Reply-To: <ZLVK5nzVZU48uvYE@nand.local>

On Mon, Jul 17, 2023 at 10:06:30AM -0400, Taylor Blau wrote:

Show 10 quoted lines

> On Mon, Jul 17, 2023 at 12:48:17PM +0200, Toon Claes wrote:
> > Hi,
> >
> > I've been looking into making git-fetch(1) to use a quarantine
> > directory, but I'm a bit stuck on direction.
> 
> What are you hoping to accomplish? receive-pack quarantines its objects
> to ensure that the pre-receive hook(s) are all OK before accepting the
> push. See 722ff7f876c (receive-pack: quarantine objects until
> pre-receive accepts, 2016-10-03) for more of the details there.

> Are you suggesting that fetch be taught the same, so that we can
> quarantine the pack sent from a remote before moving it into the main
> repository?

Yes. If we quarantine received objects it becomes easier to reject them in case it's determined that they are bogus in any way.

git-fetch(1) already does perform some checks, namely it will fsck objects when `fetch.fsckObjects` is enabled. I would consider it an improvement by itself already if the incoming objects were quarantined and discarded if we notice that any of them are corrupt. Right now, they will end up in the repository even if the consistency check declares them as broken. This makes the whole option less useful in my opinion.

Also, it makes it easier to prune incoming objects in case Git crashes or gets killed abnormally, e.g. due to a server crash. Mind you, it's not a perfect solution as the operation may be killed after objects have already been migrated or midway through. But it at least makes it easier to clean things up a little bit.

Patrick