[Info-vax] DECnet Phase IV and VMS code comments

Kerry Main kemain.nospam at gmail.com
Mon Nov 28 20:03:00 EST 2016


> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> Of Stephen Hoffman via Info-vax
> Sent: 28-Nov-16 6:17 PM
> To: info-vax at rbnsn.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [Info-vax] DECnet Phase IV and VMS code comments
> 
> On 2016-11-28 12:56:04 +0000, Kerry Main said:
> 
> > Given VSI is already coordinating regular and ongoing patches
> with
> > HPE, why would coordinating security patches be any different?
> 
> That statement could be inferred to indicate some confusion over
> what
> Simon is referencing with that particular terminology.
> Coordinated or
> responsible disclosure arises among the reporting party, the
> vendor, the users and parties — such as the relationship
> between VSI and HPE — with other parties.  Given the market
> Stark is aiming for, this is an area you will want to become more
> familiar with, if you've not already looked into it.  Potentially
> including bug bounties, which is a method for a vendor to try to
> set the pricing floor for security bugs.
> 
> https://technet.microsoft.com/en-us/security/dn467923
> https://en.wikipedia.org/wiki/Responsible_disclosure
> https://en.wikipedia.org/wiki/Full_disclosure_%28computer_sec
> urity%29
> https://blog.osvdb.org/tag/k8emo/ (old)
> 
> Given where you're headed with Stark, you may well want to
> look into these policies and practices, as well as the issues around
> creating and testing and deploying the patches, both in your
> servers as well as in any remote software you might provide or
> document or interoperate with.
>   These are usual sorts of issues that arise, obviously.
> 
> > If a security issue came up that was specific to DECnet, then
> based on
> > past experiences, VSI would address it.
> 
> Discussing and debating DECnet security is roughly equivalent to
> discussing that of telnet or FTP.   Barring recreating a DESNC-like
> solution or using stunnel or similar shenanigans or otherwise
> involving traffic via port 399, DECnet, telnet and FTP are not
> secure, and won't ever be.
> 

I don't think anyone here views 35+ year old DECnet as a strategic network product.

Having stated this, there is some basic maint support provided by both HPE/VSI which in itself, is pretty impressive.

> As for security and network vulnerabilities, VSI has been aware of
> at
> least one, and for over a year.   Less effort than finding a "new"
> bug,
> it's trivial to locate lists of dozens existing bug reports that likely
> or do apply to OpenVMS and go digging into those.   I have a list
> of
> several dozen that likely do apply to network-facing products and
> components associated with OpenVMS and several of which I've
> reproduced against OpenVMS, and I've not made a particular
> effort.
> 

I am certainly not in any position to speak for either VSI or HPE, so I will have to assume that you documented the network issue for one of them and it is under investigation.

For the benefits of others, the HPE security site is at:
http://www8.hp.com/us/en/business-services/it-services/security-vulnerability.html

Security Reporting:
https://www.hpe.com/h41268/live/index_e.aspx?qid=11503 

No one should ever be under the impression that ANY OS platform (incl OpenVMS) is security bug free. 

There will always be the next bug looming around the next corner.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com









More information about the Info-vax mailing list