From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8476B2C80 for ; Tue, 11 Jan 2022 03:16:17 +0000 (UTC) Received: by mail-lf1-f53.google.com with SMTP id s30so23669114lfo.7 for ; Mon, 10 Jan 2022 19:16:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tnWatjEgyJ9FaJC0eKyvOWSFHkKwoNBRdfNz32BOWbE=; b=pvQgk6WPtiBTpIIyj88Tt/GisS81oFMofetcLKN3sOU6bPpnu0GDVyxIytbhDGZOkN eRKNihQzDJUElKaZ4vTc+dQw6CLObT2uqdDjw5srFd7RMIe37sXcGDvjADJiCdi1oeOT ssJqESC0Ww4m0+P+evVF5e3MVETSy/0TfrolckyYCiYVcT87vr6myAaFMvHFpL1LhZWh NMEP3ja4iIVCAPAOSEZhi8hEtbZ4bvicmK4XxV6/U59gh+cLpmSOxHg3rU+yP8YJWzjM T4gBySONopcqtbPh25Sa1xDlOOSbSs5MsuL5A3fKLEE0E4kPyVtf9wxNMkcS64L8bZzR yZlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tnWatjEgyJ9FaJC0eKyvOWSFHkKwoNBRdfNz32BOWbE=; b=QEVq6wAWmXFJQGLuvgXew/9p/I5zsxqyRGQFpqUDsAO7E8lZKdGVnNkK8DSA4buBHD WA8qISAojjnyXYFPOFM4FuYizOejyuc5oI23Nzvu2wNQS8UhsMRKwPsjD5/wmMnhs3Uh VKEW1MVbdCvMRbLenR87s3gPOcaBuUWz/9zgyiEaEKppjHAbiivcDt0TkZ0ao3zuO7AJ /c2IEJtyHqS9gp0tz9+CiGFTCOFJzN4LRxlF390t+trVBJNIk5uaqKes//oxX6MMkcji L774WuwxSAFKgBVa4CjohgecmhPZcRI7XSDOqBJeWGeuj+9SSFyuape1bSSYEsq+GZxB tWKw== X-Gm-Message-State: AOAM530zzE0N5XtZhTJeAhsfAsN5kobuN2OcTp4D9/M+Pnx5MvrbE0qU G4LKu/ZX7iOOoMUDq+0JKixym/6X9/daWBqU5xk= X-Google-Smtp-Source: ABdhPJz0pfbIUNFY/jTTUD+wPeqdHZIzltUsCUeAh/QExyS0hTGeCDFj1To+Ow5RM7SA564uZgvAiNV97+dt9BvaT5w= X-Received: by 2002:a19:8c4a:: with SMTP id i10mr1885122lfj.537.1641870975462; Mon, 10 Jan 2022 19:16:15 -0800 (PST) Precedence: bulk X-Mailing-List: regressions@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: In-Reply-To: From: Steve French Date: Mon, 10 Jan 2022 21:16:04 -0600 Message-ID: Subject: Re: Possible regression: unable to mount CIFS 1.0 shares from older machines since 76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c To: Thorsten Leemhuis Cc: Davyd McColl , "lsahlber@redhat.com" , "stfrench@microsoft.com" , "linux-cifs@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "regressions@lists.linux.dev" Content-Type: text/plain; charset="UTF-8" We do still need a little more data from the users affected to ensure that it isn't something more subtle. One user noted Windows 11 worked as a client, but not Linux which would imply that it is probably something other than NTLM (NTLM has been strongly discouraged if not disabled for more than 20 years). On Mon, Jan 10, 2022 at 9:07 PM Thorsten Leemhuis wrote: > > Hi, this is your Linux kernel regression tracker speaking. > > On 10.01.22 06:53, Davyd McColl wrote: > > > > I'm following advice from the thread at > > https://bugzilla.kernel.org/show_bug.cgi?id=215375 > > as to how to report > > this, so please bear with me and redirect me as necessary. > > > > Since commit 76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c, > > FWIW, that is "cifs: remove support for NTLM and weaker authentication > algorithms" > > > I'm unable to > > mount a CIFS 1.0 share ( from a media player: mede8er med600x3d, which > > runs some older linux). Apparently I'm not the only one, according to > > that thread, though the other affected party there is windows-based. > > > > I first logged this in the Gentoo bugtracker > > (https://bugs.gentoo.org/821895 ) and a > > reversion patch is available there for the time being. > > > > I understand that some of the encryption methods upon which the original > > feature relied are to be removed and, as such, the ability to mount > > these older shares was removed. This is sure to affect anyone running > > older Windows virtual machines (or older, internally-visible windows > > hosts) in addition to anyone attempting to connect to shares from > > esoteric devices like mine. > > > Whilst I understand the desire to clean up code and remove dead > > branches, I'd really appreciate it if this particular feature remains > > available either by kernel configuration (which suits me fine, but is > > likely to be a hassle for anyone running a binary distribution) or via > > boot parameters. In the mean-time, I'm updating my own sync software to > > support this older device because if I can't sync media to the player, > > the device is not very useful to me. > > From my point of view this afaics looks like one of those issues where > the "no regressions" rule gets tricky. But I told Davyd to bring it > forward here to get it discussed in the open. I also wonder if some > middle-ground solution could be found in this particular case -- e.g. > one where the commit stated above gets reverted and the code then > slightly changed to only allow weaker authentication if the user > manually requests in somehow, for example using a module parameter or > something in /proc or /sys. > > Ciao, Thorsten > > P.S.: Anyway, getting this tracked: > > #regzbot ^introduced 76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c > #regzbot title cifs: unable to shares that require NTLM or weaker > authentication algorithms > #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=215375 -- Thanks, Steve