Re: [PATCH v2 5/8] hook(clone protections): add escape hatch

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 20, 2024, 19:38 UTC
Message-ID: <736b43a1-a371-4d6f-7739-b5b64e060585@gmx.de>
In-Reply-To: <xmqqzfskfiu3.fsf@gitster.g>

Hi Junio,

On Mon, 20 May 2024, Junio C Hamano wrote:

Show 8 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > To put this into perspective: If this protection had been put in place
> > before v2.39.4, the CVSS score of CVS-2024-32002 would not have been
> > 9.1 (Critical), but instead 2.2 (Low).
>
> But we wouldn't have a working git-lfs then, so that comparison is
> not quite fair.

I obviously did not mean to break Git LFS. And obviously I did not mean to insist on the current clone protection if we could not have fixed Git LFS. But we have patches in hand for that.

> As brian already said, you can reduce the score by making Git do
> nothing, which is _also_ an absurd position to take "security" (in air
> quotes) over everything else like usability and functionality.  And this
> time, the layered security went a bit too aggressive.

Right. And I never said that we should do something as absurd, so I fail to see your point.

Show 11 quoted lines

> Also as Peff said and I agreed to, we are not talking about refusing
> to do anything on top.  It was just that the "never run any approved
> hook during clone" turned out to be not-quite-fully thought out and
> it should be reworked in the open, and reverting that wholesale
> would hopefully give us a cleaner ground to design it.
>
> The end-result of such a reworking in the open may turn out to be
> the same (or similar) "register the blob object name of the contents
> to appear in approved hook scripts", or it may look completely
> different.  But the road to get there, and the state of the system
> while we get there, would be different.

I see there is no convincing you that the difference to our regular "revert-then-redesign-in-the-open" process is that we're talking about something security-relevant here, and that the revert should hence not be done lightly.

I've made my position clear, so have you. Since you have the last say, it's what you say that goes.

Let me quickly iterate on this here patch series (as well as the `tentative/maint-*` branches) so that we can accelerate toward a fixed version again; Git LFS has been broken for long enough, I'd think.

Ciao, Johannes

Show 8 quoted lines

> I would probably see if I can take brian's revert directly; if it
> applies to the oldest maint-2.39 track, it would be the ideal, but
> we'd still need to prepare a similar 7-track cascade like we did for
> the js/fix-clone-w-hooks-2.XX topics.  If it is only for the master,
> it needs to be munged to apply to maint-2.39 first.
>
> Thanks.
>