[Info-vax] SAMBA and Ransomeware

[Stephen Hoffman]

On 2017-07-17 16:26:50 +0000, already5chosen at yahoo.com said:

> On Sunday, July 16, 2017 at 8:52:31 PM UTC+3, Stephen Hoffman wrote:
>> https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/
> 
> I really don't like this blog post.
> If Microsoft knew long ago that SMB1 is bad then why didn't they 
> provided a better variant of SMB with original WinXP? Or with WS2003? 
> Or with one of the  winXp service packs or with one of several service 
> packs and releases of WS2003?
> 
> Telling people to stop using WinXp is *not* a solution. Telling people 
> to stop using Ws2003 is somewhat more bearable, but also problematic.
> 
> For reference, WinXP SP3 is at least two years newer than the first 
> implementations of SMB2, so my suggestions are not anachronistic.

Remaining on ancient software and having it all magically work like 
more current bits, and without the vendor and the end-user spending 
appreciable money or effort to stay current?

Getting to where that's even possible is not a trivial investment in 
development, and also in customer expectations and acceptance.   
Dependency hell is just part of this.

Beyond SMB 1, there was a whole lot wrong with Windows XP.  The 
much-maligned Windows Vista broke a number of apps, and fixed a number 
of issues with earlier releases.

The same sorts of old-software issues arise with OpenVMS, too.   How 
many OpenVMS folks are still using DECnet, or insecure SCS, or telnet 
or ftp or the rest, or the folks that have yet to apply OpenVMS patches?

VSI is clearly commencing the efforts necessary bring OpenVMS forward 
to more current services, and is also starting the API work to make 
this easier for themselves and for developers.    There are already 
examples of these API dependencies on OpenVMS (e.g. OpenSSL APIs), and 
the frequency of occurrences of API dependencies arising is only going 
to increase as VSI continues and increases efforts to fix parts of 
OpenVMS itself, and to upgrade OpenVMS capabilities, and work toward 
more current software versions.

Some of which will break existing apps or require increasingly 
expensive and hairy technical debt ("compatibility"), and a situation 
which will inevitably keep some folks on older OpenVMS releases.

>From a product producer prospective, back-porting features and upgrades 
is more cost and more effort, and detracts from the efforts of getting 
folks to move forward to better and newer and more current platforms.

That written, Microsoft has decided to follow your suggestions here, 
but is doing so with Windows 10.   Not with Windows XP or older 
releases.    We'll eventually learn how well the Windows 10 approach 
works for Microsoft, for Microsoft partners and ISVs, and for end-users 
of Windows, too.  How well this works from a technical approach, and 
around corporate financial, marketing and partnerships?  Even if 
software compatibility continues, some new features are inevitably 
going to exclude older hardware, and which will force hardware 
upgrades; older hardware is inevitably going to age out.

Maybe VSI eventually follows this continuous-upgrades same-version 
approach with the OpenVMS 10 release?   This is very close to what's 
called SaaS, too; software as a service.   So long as you're covered by 
support, you get patches.   Even if VSI decides to adopt SaaS or 
similar, there's still more than a little technical work involved in a 
workable implementation for OpenVMS, too.

Related: PCSI lacks capabilities around maintaining and managing and 
upgrading dependencies, requiring end-users and developers to hand-roll 
their own unique solutions to API dependencies.   Of these, I happen to 
like the approach Oracle Rdb uses, but it's one of many.   For an 
approach around dependency management used elsewhere, see the nix 
package manager and NixOS:
https://nixos.org/nix/
https://nixos.org/


-- 
Pure Personal Opinion | HoffmanLabs LLC