[Info-vax] OpenSSL CSWS-2.2-1

[terry-groups at glaver.org]

On Saturday, April 6, 2019 at 9:58:41 PM UTC-4, Stephen Hoffman wrote:
> If you're planning to stay with OpenVMS and want current versions and 
> support, you'll want to migrate your licenses and support and versions 
> to VSI.
> 
> And there's the discussion about VSI marketing.

Indeed. On a number of occasions I've said to VSI folks "I'm a Hobbyist - please take my money!" and have been told that there's no mechanism in place for that at the (then-current) time. Based on what I've heard from people who have purchased from VSI, pricing is rather more variable than it was with Hpaqital, so I'm not sure why this is happening. I'm running the commercial version of AlphaVM from a customized price quotation, so it isn't impossible for vendors to do this.

> VSI is unfortunately sticking with the absurd product names though, but 
> then acronyms and obfuscations are the OpenVMS way.  We can't have 
> something cleverly called "webserver", after all.  Much too obvious.  
> Requirements around the possession of arcane or obscure knowledge—like 
> what SWS or CSWS translates into—is part of the membership in the 
> OpenVMS club.   Plain names and clear descriptions?  Those are just not 
> permitted.  So we have CSWS, which everybody obviously knows is a web 
> server.

It would be nice if the product was called "VSI Apache web server (formerly CSWS) for OpenVMS" or somesuch.

> This is a restriction of the upstream in the case of the OpenSSL APIs, 
> and the upstream OpenSSL releases are themselves not completely 
> compatible.

For "native" VMS use, any particular SSL implementation could be shimmed to give it typical VMS calling conventions. For use with Apache, SAMBA, etc. the (undocumented on VMS?) native (non-shimmed) interface could be used if converting the particular application to VMS-type conventions is too much work.

> To address that incompatibility when it next arose, then-HP tried to 
> make this stuff independent with the SSL1 kit in addition to the 
> existing SSL kit, but didn't quite complete the design.

If I'm remembering correctly, at one point the newest HP/VMS OpenSSL release had a _lower_ version number than the older release.

> VSI has moved to allow multiple installed versions in parallel with 
> their latest V8.4-2L1 and V8.4-2L2 releases, which will ease the 
> migrations.
> 
> We're headed for another OpenSSL update and likely later this year, as 
> the OpenSSL security patches are ending for the current series.  We'll 
> see a version based on 1.1.1, and then 3.0.0 as that arrives.

This would seem to make a good argument for shimming.

> Then there's the discussion of why any of Apache and OpenSSL is 
> separate from the OpenVMS distribution, and not integrated.  Having 
> worked with server platforms with integrated networking and network 
> services, the OpenVMS approach is just a hassle. When it works.

Because they update far more frequently than VMS does? But this gets into a discussion of support / patching plans, etc. which is a completely different can of fish?