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

[Stephen Hoffman]

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_security%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.

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.



-- 
Pure Personal Opinion | HoffmanLabs LLC