[Info-vax] DCL vulnerability write up on The Register

[terry-groups at glaver.org]

On Thursday, February 22, 2018 at 11:40:21 AM UTC-5, Stephen Hoffman wrote:
> You'd be surprised what I find on some of those OpenVMS networks, then. 
>   And where I've found some OpenVMS servers.   BTW... It's not just 
> local SCS traffic.   OpenVMS clusters don't encrypt WAN traffic.

Perhaps the AESNI support in newer x86 CPUs can be leveraged for hardware acceleration for both cluster traffic (at least to other x86 nodes, the "cluster compatibility kit" or whatever it ends up being called will likely need to handle unencrypted traffic to Alpha / Itanium nodes) and other crytographic stuff like SSH/SSL.
 
> The VSI IP stack will help with some of this, but there's a whole lot 
> that app developers have to do to drag their own apps forward, and 
> there's a whole lot ahead of VSI just to drag the default installation 
> toward better security.

The MultiNet code base will help here (I think I heard that VSI's product would be based on MultiNet), but even it is a little long in the tooth. The current MultiNet identifies itself as "MultiNet 5.5 Rev A-X (4.4bsd+ Networking)". 4.4BSD was a long time ago, and while TGV / Process added selected features and fixes from later code, it could probably do with a going-over after reviewing the change logs from one of the current *BSDs.

MultiNet's BIND is 9.9.7 with select fixes backported. Current BIND99 is 9.9.11-P1 and all of BIND 9.9 is going EoL as of June 2018. 9.11 is the new ESV, slated for support through 2021. The reason for "select fixes backported" dates back to TGV, because there were a large number of changes needed all across the BIND source tree to deal with VMSisms in general and VAX/DEC C and related RTLs. A bunch of that can go away (working around obsolete compiler and RTL issues, at least on x86) but dealing with the VMSisms will actually get worse as BIND starts making more and more use of modern(ish) operating system and TCP stack features that aren't in VMS or MultiNet's TCP implementation. For example, BIND911 and newer expects TFO (TCP Fast Open, RFC7413) support.

Some of the dustier corners of MultiNet either have (as I said 20+ years ago) "a fragile, thin veneer of VMSisms on top of Unix command-line syntax" or flat-out Unix style (SSH config, for example). That worked in a 3rd-party product, particularly since it was the best of the 3rd-party TCP stacks, but customers probably expect better integration with OS-style command syntax and command line processing (no "?" auto-complete anywhere else in VMS, for example).

Another issue here is whether VSI and Process will be duplicating work the other did, or if there will be unidirectional or bidirectional sharing of changes / fixes.