Re: [PATCH v1] read_index_from(): Skip verification of the cache entry order to speed index loading

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Stefan,

On Thu, 19 Oct 2017, Stefan Beller wrote:

> On Thu, Oct 19, 2017 at 8:12 AM, Ben Peart <peartben@xxxxxxxxx> wrote:
> 
> > If we are guarding against "git" writing out an invalid index, we can move
> > this into an assert so that only git developers pay the cost of validating
> > they haven't created a new bug.  I think this is better than just adding a
> > new test case as a new test case would not achieve the same coverage.  This
> > is my preferred solution.
> >
> > If we are guarding against "some other application" writing out an invalid
> > index, then everyone will have to pay the cost as we can't insert the test
> > into "some other applications."  Without user reports of it happening or any
> > telemetry saying it has happened I really have no idea if it every actually
> > happens in the wild anymore and whether the cost on every index load is
> > still justified.
> 
> How well does this play out in the security realm?, c.f.
> https://public-inbox.org/git/20171002234517.GV19555@xxxxxxxxxxxxxxxxxxxxxxxxx/

That link talks about security implications from administrators accessing
Git repositories with maliciously crafted hooks/pagers.

Ben's original mail talks about integrity checks of the index file, and
how expensive they get when you talk about any decent-sized index (read:
*a lot* larger than Git or even Linux developers will see regularly).

The text you quoted talks about our talking out of our rear ends when we
talk about typical user schenarios because we simply have no telemetry or
otherwise reliable statistics.

Now, I fail to see any relationship between Jonathan's mail and either of
Ben's statements.

Care to enlighten me?

Ciao,
Dscho



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux