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]
Message-ID: <CAHk-=wiNvB_j3VZYJ1yZqq+9JjgWCO1MUmRsjTKBwQ+x=kB5tg@mail.gmail.com>
Date:   Tue, 31 Aug 2021 09:39:42 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Steve French <smfrench@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        CIFS <linux-cifs@...r.kernel.org>
Subject: Re: [GIT PULL] cifs/smb3 client fixes

On Sun, Aug 29, 2021 at 10:48 PM Steve French <smfrench@...il.com> wrote:
>
> - mostly restructuring to allow disabling less secure algorithms (this
> will allow eventual removing rc4 and md4 from general use in the
> kernel)

Well, you should probably have mentioned that you already started on
this by removing LANMAN support.

I'm sincerely hoping nobody used or depended on that old garbage in
this day and age any more.

Anyway, entirely unrelated question: you pretty much interchangeably
use "cifs" or "smb3" for the filesystem, as shown once more by the
commit messages here (but also the subject line).

The filesystem directory is called "cifs", and I've taken to use that
in my "Pull cifs updates" thing from you to just avoiding the
confusion.

And now we have ksmbd (yup, I just merged that pull request too), so
we have a "cifs client" and a "smb server". Aaarrgh.

I understand that some people may care about the name, may care about
"smb2 vs smb3", or whatever. But I have to admit finding it a bit
annoying how the code and the directory layout uses these different
terms pretty much randomly with no real apparent logic.

Somehow the NFS people had no problem completely changing everything
about their protocols and then still calling the end result "nfs
client" vs "nfs server".

Oh well. I'm assuming it's not going to change, and it's not really a
problem, I just wanted to mention my frustration about how clear as
mud the naming is.

             Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ