Sry for the toppost “My stuff needs smbv1 and I’ve known about it being deprecated for over a decade with the person i/c it at MSFT was begging folk not to use it in 2016 and I haven’t worked out a technical solution for my limited domain and because of my limited experience with a 50 year old file protocol I want to keep all the obvious footguns still enabled by default for all to use.”
https://techcommunity.microsoft.com/blog/filecab/stop-using-smb1/425858 Strip it all out and those that need to use different stuff can use it in their limited domain. > On 3 Jan 2026, at 02:33, John Gilmore <[email protected]> wrote: > > Mr. Herbert, I am not sure why you are so excited to delete a feature > that others are certainly using. Why use your valuable time to make > trouble for others? Isn't standing on each others' shoulders better > than standing on each others' toes? > > "Deprecating" a protocol feature is more of a political statement than a > technical statement. For example, I recall an Internet-Draft proposing > to deprecate the entire IPv4 protocol suite: > draft-howard-sunset4-v4historic-00. Its successor, > draft-ietf-sunset4-ipv6-ietf-01, was approved by a small wg with three > total votes, and actually made it to an IETF Last Call before saner > heads prevailed, pointing out that the majority of traffic on the > Internet was running over this "to-be-deprecated" protocol. > > The draft claims that there's no reason to run AH and "extrapolates" > (sec. 3.3) that it is "not used anywhere". Clearly the author did not > research the history of AH and ESP, the Crypto Wars, and the legal > landmines that led to the development of authentication-only protocols. > There have been, and are, many countries where encryption is illegal. > You can't assume that full blown unbreakable encryption like IKE/ESP is > available everywhere on the Internet, because it makes governments > nervous when they can't wiretap their citizens. AH does not threaten > them, which is why the IPSEC WG designed and deployed it. Distributing > ESP in the United States was illegal until the year 2000 when EFF.org > led a court case that overturned the multiple crypto export control laws > that made it a felony. (It is still illegal to use ESP encryption, and > TLS, over amateur radio links in the United States. And yes, IP runs > over amateur radio links all over the world.) In 2026, the UK and EU > are trying hard to outlaw encryption of messaging applications on the > theory that bluenoses can't spy on who's trading dirty pictures -- and > the US Congress was not far behind in trying to pass such a law last > year. There are today major countries that entirely ban VPNs too -- > China is an example. > > Tom Herbert <[email protected]> wrote: >> To deprecate a protocol like this we can take a phased approach that >> has been used for other features being deprecated. First, we'll >> disable it to be compiled by default and give a nice warning that the >> protocol is being deprecated. Once that's fully deployed and if no one >> complains the feature is being deprecated then the code for the >> protocol can safely be removed. > > First, most people don't compile their kernels. They run a popular > Linux distribution that provides a small selection of kernels. If the > mainline kernel config defaults the feature to "off" and the distros are > not savvy enough to turn it back on for their customers, then anyone who > was depending on the feature will suddenly discover that upgrading their > OS to the latest version has broken whatever subsystem depended on the > feature. This backward-incompatible breakage is the sort of thing that > causes people to be very wary of upgrading to new OS releases. Their > justified hesitancy, as another poster pointed out, is very bad for > getting people to install the regular updates that close major security > holes throughout the Internet. So breaking backward compatability is > only justified in the most extreme cases. > > The "complaints" of end-users will mostly just turn the air blue > around the user's or sysadmin's desk. Possibly they will be mad enough > to send an email to their distro complaining that the feature went away > for no obvious reason. Which will probably be filed in a bug-tracking > system, and then later closed unfixed by someone or some daemon to make > it look like they don't have any pending bugs. Essentially none of the > users will send anything to the Linux-Kernel mailing list, or to you > (the responsible party). So unless you make some particularly special > arrangements to get feedback from ordinary users, there's no way for you > to ever know that "no one complains". > > Second, the fix that you propose to require end-users and sysadmins to > apply, after they discover that AH is broken, is to learn how to > download, configure and build kernels from source code, and to then step > through that process. But also to find and override the default that you > created in the rat's nest of config options, the specific setting which > makes AH not work. This is a relatively steep learning curve for most > end users. You can probably do it in your sleep, but most people don't > want to be kernel maintainers. > > And if end users do go through this step and make AH work again for > them, they will likely not produce the "complaints" back to you that > would prevent you from taking the second step and deleting the code > entirely from some future mainline kernel release. Which would make an > entirely greater burden on the end users once that kernel landed in > their OS release. They'd have to resurrect the code from a prior kernel > release, manually tease it out and integrate it and its config hooks > into their modern kernel, and reconfigure and rebuild their kernel and > reinstall it. That's an order of magnitude harder (e.g. they'd need to > know C programming), and even more likely to produce unrelated errors or > breakages. > > The easiest thing for users would be to not break AH at all. > > But it would certainly be easier for them if they could do a web search > that led to: "Put this sysctl command in your /etc/rc.local and it will > turn AH support back on every time you boot your machine." That's a > much smaller lift than pointing them at a many-page document on how to > configure kernels, rebuild them, reinstall them and test them. Maybe > the suggested fix should also include: > > And put this command into your /etc/rc.local too: > > echo "Yes we still use AH don't delete it." | /bin/mail [email protected] > > As another poster suggested, it's likely that many end users would just > downgrade their system to an OS release that still works for them. > Which has all the security and compatability problems of running > back-rev OS's. Why force them into making such a choice? > > In my own small home network I am facing a very similar issue due to the > mainline kernel and distros removing support for SMB v1 (over security > issues). The change was not backward compatible, and the result is that > a piece of proprietary high-end audio gear that used to access my music > library over SMB v1 can no longer reach my music collection. This left > me with many possible paths to resolution, such as: > > * Junk my whole-house audio system > * Try to get the supplier to provide an upgrade to SMB v2 or to NFS, > for this product that they no longer produce > * Try to manually patch the proprietary audio system (which runs an > unfamiliar version of Linux under their proprietary code) to > support SMB v2. > * Find the old SMB v1 kernel code and manually merge it into a modern > kernel in my file server > * Downgrade my file server to run an old Ubuntu release with SMB v1 > support > > Since I am my own sysadmin, and doing days of sysadmin is my least favorite > activity, I have so far taken path #1 -- my music system is wrecked. > > In the SMB v1 case, I at least see why the kernel maintainers did what > they did, despite the trouble that they caused me. In the case of AH > support, I see zero reason to make it stop working, except misplaced > zeal. > > John > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > List Info: https://mailman3.ietf.org/mailman3/lists/[email protected]/ > --------------------------------------------------------------------
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
