[Info-vax] OpenSSL CSWS-2.2-1

[Stephen Hoffman]

On 2019-04-07 00:17:43 +0000, Robert A. Brooks said:

> On 4/6/2019 6:54 PM, terry-groups at glaver.org wrote:
>> On Saturday, April 6, 2019 at 1:24:05 PM UTC-4, Stephen Hoffman wrote:
>>> The current OpenVMS CSWS version is based on Apache HTTP Server V2.4-38.
>> 
>> Is it really that up-to-date? I'd be amazed.

Be amazed, then.

>> A Google search for "OpenVMS CSWS" leads me to
>> https://support.hpe.com/hpsc/doc/public/display?docId=a00058394en_us 
>> which says it is based on Apache 2.0.65, and took apparently nearly a 
>> year and a half (based on June 2013 release date from the Apache 
>> Foundation and an October 2014 date on the HP release notes).

HPE have less than two years' new-patch support announced, and they're 
clearly working toward their long-announced exit from the OpenVMS 
business.

> We (VSI) have a much more current version of Apache, although I'd be 
> hard-pressed to tell you what that is.  I suspect the version that 
> Steve referred to is ours.

The referenced Apache version is from VSI.

Again, HPE is exiting the OpenVMS business.

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.

>> 2) Assigning (apparently) arbitrary version numbers instead of using 
>> the upstream version number (possibly with a suffix like "-VMS1", 
>> "-VMS2", etc. if multiple VMS releases against the same upstream 
>> version are needed (which shouldn't happen if the upstream releases are 
>> being tracked regularly).
> 
> In general, I didn't think we are doing that, although the "-Q" above 
> confuses me.  Then again, I know very little about our open source work.

Version-numbering has been confusing with vendor-provided ports for a 
while, yes.  VSI has been using the upstream open source version 
numbers, to their credit.

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.

>> 3) Producing incompatible releases of various upstream packages that 
>> are supposed to work together. I've read many posts where people say 
>> that package A requires OpenSSL X, but package B requires OpenSSL Y 
>> which has a different API than OpenSSL X.
> 
> I do know that we are pretty good at documenting requirements and 
> restrictions, and ensuring that they are accurate.

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

The then-HP SSL V1.3 to SSL V1.4 change—why that wasn't labeled a "2.0" 
release?—required app rebuilds and potentially app source code changes.

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.

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.

OpenSSL 3.0.0 will be the first release with an Apache 2 license, too.

This particular mess is also why I've commented around the lack of an 
API for OpenVMS that masks these differences and that makes creating a 
secure network connection rather less of a project than is currently 
involved.  I've pointed to Secure Transport and similar approaches as 
one of various examples from other platforms that have sought to reduce 
or to isolate SSL-level differences from the application developers.

Alternatives to OpenSSL include NaCl and libtls, among others.

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.

And there's the discussion about VSI marketing.


-- 
Pure Personal Opinion | HoffmanLabs LLC