linux-kernel - Re: [PATCH] checkpatch: Flag spam header (X-Spam-Report) to prevent spurious warnings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 24 Mar 2017 13:14:29 -0700
From:   John 'Warthog9' Hawley <warthog9@...lescrag.net>
To:     Joe Perches <joe@...ches.com>, linux-kernel@...r.kernel.org
Cc:     Andy Whitcroft <apw@...onical.com>,
        "Darren Hart (VMware)" <dvhart@...radead.org>
Subject: Re: [PATCH] checkpatch: Flag spam header (X-Spam-Report) to prevent
 spurious warnings

On 03/21/2017 11:31 AM, Joe Perches wrote:
> On Tue, 2017-03-21 at 09:30 -0700, John 'Warthog9' Hawley (VMware) wrote:
>> Spamassassin sticks a long (~79 character) long string after a
>> line that has a single space in it. The line with space causes
>> checkpatch to erroniously think that it's in the content body, as
>> opposed to headers and thus flag a mail header as an unwrapped long
>> comment line.
> 
> If the spammassassin header is like
> 
> email-header-n: foo
> email-header-m: bar
>  
> X-Spam-Report: bar
> 
> Does that form follow rfc 5322?

It does look that way

> If it does then any email header could have that
> form and the header wrapping test should be
> updated from
> 
> 		if ($in_header_lines && $realfile =~ /^$/ &&
> 		    !($rawline =~ /^\s+\S/ ||
> 		      $rawline =~ /^(commit\b|from\b|[\w-]+:).*$/i)) {
> 			$in_header_lines = 0;
> 			$in_commit_log = 1;
> 			$has_commit_log = 1;
> 		}
> 
> to something like
> 
> 		if ($in_header_lines && $realfile =~ /^$/ &&
> 		    !($rawline =~ /^ (?:\s*\S|$)/ ||
> 		      $rawline =~ /^(commit\b|from\b|[\w-]+:).*$/i)) {
> 

So this seems to fix the specific issue we were tripping over, but in
doing so causes some other problems on some of the other headers in the
message we are using for testing (3 new warnings, and an error),
specifically flagging a:
	- Warning on 'Received:' header
	- Warning on 'DKIM-Signature:' header (twice, for both leading and
trailing white space on To: and From:)
	- Erroring on the DKIM-Signature as well

Noting the DKIM-Signature, in this case, is also a multi-line header message

This resolves the issue we were seeing, and doesn't (at least in my test
cases), cause any new errors:

	if ($in_header_lines && $realfile =~ /^$/ &&
		!(
			(
				$rawline =~ /^\s+\S*/
				&&
				$rawline !~ /^[\r\n]+$/
			)
			||
			$rawline =~ /^(commit\b|from\b|[\w-]+:).*$/i)
	) {

as the line that's causing issues, /^ [\r\n]+$/, wouldn't get
incorrectly caught as the end of the headers.

- John 'Warthog9' Hawley