Jonathan Tan <jonathanta...@google.com> writes:
>> 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 <m...@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.
