Re: [RFC/PATCH 3/3] mailinfo: handle in-body header continuations

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 16, 2016, 20:59 UTC
Message-ID: <xmqqshszimrh.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <1b392241-461e-3b87-400d-70d66903e3d7@google.com>

Jonathan Tan <jonathantanmy@google.com> writes:

Show 19 quoted lines

>> handle_commit_msg(...)
>> {
>> 	if (mi->in_line_header->len) {
>> 		/* we have read the beginning of one in-line header */
>> 		if (line->len && isspace(*line->buf))
>
> This would mean that a message like the following:
>
>   From: Me <me@example.com>
>     -- 8< -- this scissors line will be treated as part of "From"
>
> would have its scissors line treated as a header.
>
> The main reason why I reordered the checks (in RFC/PATCH 1/3) is to
> avoid this (treating a scissors line with an initial space immediately
> following an in-body header as part of a header).
>
> (If this is not a concern then yes, I agree that the way you described
> is simpler and better.)

Ahh, OK. I do not think anybody sane would do the "From:" thing, but with the "does it look like 2822 header" check to decide if the first header-looking line should be queued, another failure mode may be:

	any-random-alpha-and-dash-string: 
         -- >8 -- cut here -- >8 --
        Subject: real subject

        The first line of the real message
        
I personally do not think it matters that much, but if we wanted to
protect us from it we could easily do

        if (mi->in_line_header->len) {
                /* we have read the beginning of one in-line header */
                if (line->len && isspace(*line->buf) &&
                    !(mi->use_scissors && is_scissors_line(line))) {
                        append to mi->in_line_header strbuf;
                        return 0;
                }
                /* otherwise we know mi->in_line_header is now complete */
                check_header(mi, mi->in_line_header, ...);
                strbuf_reset(&mi->in_line_header);
        }
	...

instead, I think.