On Fri, Jun 01, 2018 at 10:42:00AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I haven't tested it, but I suspect that doing multiple fetches could
> > result in passing bad objects through a fetch.fsckObjects filter.
> > Because the objects aren't quarantined on fetch, and because
>
Jeff King writes:
> I haven't tested it, but I suspect that doing multiple fetches could
> result in passing bad objects through a fetch.fsckObjects filter.
> Because the objects aren't quarantined on fetch, and because
> fsck_finish() requires the objects to be installed into place, they may
>
On Thu, May 31 2018, Jeff King wrote:
> On Tue, May 29, 2018 at 11:59:07PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > I'm not sure what testing this buys us. [...]
>>
>> Half of what I'm trying to do here is clarifying the v2.17.1 release
>> notes. The initial version Junio had & my proposed
On Wed, May 30, 2018 at 10:32:19AM +0900, Junio C Hamano wrote:
> If we want to also encourage people to vet their own "fetches", I am
> not against extending documentation. It just is different from "we
> extended the mechanism to help server side protect their clients"
> that was the focus of
On Tue, May 29, 2018 at 11:59:07PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I'm not sure what testing this buys us. [...]
>
> Half of what I'm trying to do here is clarifying the v2.17.1 release
> notes. The initial version Junio had & my proposed amendment on
> git-security was:
I think
Ævar Arnfjörð Bjarmason writes:
> The receive.fsckObjects variable only kicks in when someone pushes to
> you, not when you fetch something malicious and someone then fetches
> from you.
> ...
Yes, that is what was described in the release notes as the server
side support. If you want to avoid
Jeff King writes:
>> It's worth testing for this explicitly. So let's amend the tests added
>> in 73c3f0f704 ("index-pack: check .gitmodules files with --strict",
>> 2018-05-04) to show how this can result in a v2.17.1 client passing
>> along the evil objects.
>
> I'm not sure what testing this
On Tue, May 29 2018, Jeff King wrote:
> On Tue, May 29, 2018 at 09:19:50PM +, Ævar Arnfjörð Bjarmason wrote:
>
>> Something that's known but not explicitly discussed in the v2.17.1
>> release notes, or tested for, is that v2.17.1 will still happily pass
>> on evil .gitmodules objects by
On Tue, May 29, 2018 at 09:19:50PM +, Ævar Arnfjörð Bjarmason wrote:
> Something that's known but not explicitly discussed in the v2.17.1
> release notes, or tested for, is that v2.17.1 will still happily pass
> on evil .gitmodules objects by default to vulnerable downstream
> clients.
>
>
Something that's known but not explicitly discussed in the v2.17.1
release notes, or tested for, is that v2.17.1 will still happily pass
on evil .gitmodules objects by default to vulnerable downstream
clients.
This could happen e.g. if an in-house git hosting site is mirroring a
remote repository
10 matches
Mail list logo
