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] [day] [month] [year] [list]

Message-ID: <8d5aff7a-5fca-c551-f6df-c617c11564d6@eaglescrag.net>
Date:   Fri, 24 Mar 2017 13:19:12 -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

You can disregard this, I missed the other thread and that looks fine.

On 03/24/2017 01:14 PM, John 'Warthog9' Hawley wrote:
> 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
>