Hi Junio,
On Thu, 14 Apr 2016, Junio C Hamano wrote:
> Even though a Git commit object is designed to be capable of storing
> any binary data as its payload, in practice people use it to describe
> the changes in textual form, and tools like "git log" are designed to
> treat the payload as text.
Jeff King writes:
> But I do agree in general that we should be checking as many things as
> we can.
I was about to say "I agree with that in principle, but there are
cases where you would want to say 'if the object does not pass even
this basic check, it is not worth validating it further', and
Jeff King writes:
> On Thu, Apr 14, 2016 at 02:21:03PM -0400, Jeff King wrote:
>
>> So yet another alternative would be to include this check in
>> verify_headers(). It would parse to the end of the headers as now, and
>> then from there additionally look for a NUL in the body.
>
> Hmm. Looking a
On Thu, Apr 14, 2016 at 11:25:29AM -0700, Junio C Hamano wrote:
> > You need this "buffer_begin" because we move the "buffer" pointer
> > forward as we parse. But perhaps whole-buffer checks should simply go at
> > the top (next to verify_headers) before we start advancing the pointer.
> > To me,
On Thu, Apr 14, 2016 at 11:07:09AM -0700, Junio C Hamano wrote:
> Even though a Git commit object is designed to be capable of storing
> any binary data as its payload, in practice people use it to describe
> the changes in textual form, and tools like "git log" are designed to
> treat the payload
On Thu, Apr 14, 2016 at 02:21:03PM -0400, Jeff King wrote:
> So yet another alternative would be to include this check in
> verify_headers(). It would parse to the end of the headers as now, and
> then from there additionally look for a NUL in the body.
Hmm. Looking at verify_headers(), I think i
Jeff King writes:
>> +const char *buffer_begin = buffer;
>>
>> if (verify_headers(buffer, size, &commit->object, options))
>> return -1;
>
> You need this "buffer_begin" because we move the "buffer" pointer
> forward as we parse. But perhaps whole-buffer checks should simp
Even though a Git commit object is designed to be capable of storing
any binary data as its payload, in practice people use it to describe
the changes in textual form, and tools like "git log" are designed to
treat the payload as text.
Detect and warn when we see any commit object with a NUL byte
8 matches
Mail list logo
