linux-kernel - Re: [GIT PULL] scheduler updates for v4.20

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]

Date:   Tue, 23 Oct 2018 15:12:22 +0100
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>, tglx@...utronix.de,
        Greg KH <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] scheduler updates for v4.20

On Tue, Oct 23, 2018 at 12:06 PM Ingo Molnar <mingo@...nel.org> wrote:
>
> Please pull the latest sched-core-for-linus git tree from:

Hmm. I've pulled, but this message was odd and mis-formed.

First off, it didn't have a diffstat (I did verify the shortlog instead).

Secondly, can you please check how you send emails. I get a DMARC
failure on that email, looking like this:

  ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@...il.com header.s=20161025 header.b=iFVXLHcJ;
       spf=pass (google.com: domain of mingo.kernel.org@...il.com
designates 209.85.220.65 as permitted sender)
smtp.mailfrom=mingo.kernel.org@...il.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org

so it seems something is unhappy with how you had that

   Sender: Ingo Molnar <mingo.kernel.org@...il.com>
   From: Ingo Molnar <mingo@...nel.org>

set up. It looks like you went directly through gmail rather than
going through kernel.org and getting a proper kernel.org dkim hash.

Thirdly (and least importantly), you should probably check your MUA
(which seems to be Mutt), because this came in with

  Content-Type: text/plain; charset=iso-8859-1
  Content-Disposition: inline
  Content-Transfer-Encoding: 8bit

and using iso-8859-1 instead of utf-8 in this day and age is just all
kinds of odd.  It looks like it was all fine, but if Mutt has an
option to just send as utf-8, I encourae everybody to just use that
and try to just have utf-8 everywhere. We've had too many silly issues
when people mix locales etc and some point in the chain gets it
wrong..

                Linus