[Info-vax] How do I make zip, unzip etc. available to all users?

[RobertsonEricW]

On Saturday, January 9, 2016 at 11:18:33 AM UTC-5, Stephen Hoffman wrote:
> On 2016-01-09 15:30:52 +0000, abrsvc said:
> 
> >> 
> >> Live patches have been around for Unix for a while with now-at-Oracle 
> >> Ksplice, and similar capabilities has been added to Linux 4.   That 
> >> kernel patching infrastructure is, of course, a non-trivial part of how 
> >>  far behind OpenVMS is, in this area.   OpenVMS can't manage to unload 
> >> device drivers, for that matter.
> > 
> > I'm not convinced that allowing kernel level patching is a god thing 
> > with a running system.
> 
> Few will, either.  Certainly not until after they've tested the 
> operations on a non-critical server.
> 
> >  Doesn't that provide a rather large invitation to problems?
> 
> Doesn't not-patching invite rather large (known) problems?
> 
> > How much easier would it be to install viruses at the OS level should 
> > this be allowed?
> 
> How many folks here have downloaded a pre-built version of zip and 
> unzip from somewhere?   That's a far simpler path than installing 
> malware via a live-patch.   (Who do you go after, if you want to nail 
> an OpenVMS system?   Start with Hunter, Brian and Jur.   More than a 
> few OpenVMS sites trust those folks with our servers, after all.  Be 
> patient.  See where your malware gets.)
> 
> How many folks are down-revision on their server versions and patches?  
>  That's far simpler than malware via a live-patch.
> 
> If you're in the pre-millennial era with your applications and servers 
> and have your servers entirely firewalled in your DC, maybe you don't 
> patch.   But when somebody gets 'phished and prints a PDF to a 
> down-revision printer that happens to be located on the cluster LAN, 
> that's simpler than installing a live-patch.
> 
> If your servers are entirely walled off in the DC, maybe you have 
> credentials embedded in the configuration or there's telnet or ftp in 
> use or your administrators get themselves phished for their creds.   
> That's simpler than acquiring malware via a live-patch.
> 
> Now if the servers are network-accessible or web-facing or if you 
> correctly do not trust that your network and your infrastructure is 
> actually wholly isolated from The Bad People -- which is a situation 
> that more than a few of the OpenVMS servers I deal with are in -- 
> then... you might have a problem with down-revision software.  Prompt 
> patching is the usual solution.
> 
> Live-patching can potentially help with application uptime, if your 
> applications can't tolerate failures and aren't coded for fail-over or 
> checkpoint-restart.
> 
> Now there could certainly be some improvements made to the tools used 
> for verification and application signing -- I believe I've occasionally 
> mentioned that network transport and certificate security is 
> ever-so-slightly problematic on OpenVMS -- that'd be a welcome 
> improvement.   The core security implementation on OpenVMS is based on 
> decade-outdated and long-deprecated CDSA open-source code.    
> Interestingly, AFAICT the HPE folks seem to have decided to bypass the 
> integrated CDSA tools for their current kit-signing implementation, 
> too.  Not that anything could be inferred from that decision, of course.
> 
> So.... sure.... Yes.  It's possible there'll eventually be malware 
> acquired via live-patching.   We should be so lucky, really.
> 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

Unfortunately, the current state of OpenVMS limits Secure Software Delivery to software produced exclusively by either HPE or VSI (via the newer HPE-specific signing routines). The situation with respect to Secure delivery using CDSA signed packages is virtually the same with respect to third party software producers. The only third party software producers outside of HPE and VSI that are capable of getting Secure Delivery using (now deprecated) CDSA signed installation kits are those producers who got their certificates signed by the OpenVMS CDSA Integrity Root Certificate before HPE suspended that process for third party software producers. Since VSI has not reinstituted that process, the situation remains unchanged; aspiring third party software producers (that did not previously produce CDSA-signed software kits for OpenVMS) cannot securely deliver software to the OpenVMS platforms.

Since Secure delivery is one of a few foundational capabilities needed to enable automation of secure delivery and installation  of third party software installation kits, I am hoping that VSI targets the certificate management capabilities of OpenVMS as one of the first items to get attention once resources start freeing up from the development of OpenVMS x86-64. After all, in this day and age, what aspiring third party software developer is going to think very long about developing software for OpenVMS when they cannot make certain that the software they might contemplate producing will be securely transmittable and installable "over the wire" onto the very platform which they contemplate producing software for? Yes, certificate management and secured product installation are important ingredients needed for future growth of both the OpenVMS user and software marketplaces. Without it, the long (and possibly even medium) term future of OpenVMS will be grim indeed.