OpenSSL CSWS-2.2-1

[Neil Rieck]

Everyone reading this already knows that HP (now HPE) used to provide free updates for CSWS (a.k.a. Apache for OpenVMS) modules including SSL, Java, PHP, etc. All of those web pages have been redirected to the common OpenVMS landing page so I guess we can assume that those days are over.

However, life goes on and I just learned that all major browsers are going to disable TLS-1.0 and TLS-1.1 sometime in 2020. Here are a few links which shine more light on the announcement.

https://www.zdnet.com/article/chrome-edge-ie-firefox-and-safari-to-disable-tls-1-0-and-tls-1-1-in-2020/

https://www.cso.com.au/article/648261/tls-1-0-1-1-will-disabled-edge-ie-chrome-firefox-safari-2020/

https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls

Now 2020 seems a long way off but web developers at my employer's company are already seeing TLS-1.0 and TLS-1.1 warnings in the AJAX transport associated with "Developer Tools" in Chrome v73 so I suggest that anyone with an OpenVMS support contract at HPE contact them for support (previously they just send out a new version of file "mod_ssl.exe"). I just filed a support request with them this morning.

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net




 

[Jan-Erik Söderholm]

Den 2019-03-14 kl. 17:36, skrev Neil Rieck:
> Everyone reading this already knows that HP (now HPE) used to provide
> free updates for CSWS (a.k.a. Apache for OpenVMS) modules including SSL,
> Java, PHP, etc. All of those web pages have been redirected to the
> common OpenVMS landing page so I guess we can assume that those days are
> over.
>
> However, life goes on and I just learned that all major browsers are
> going to disable TLS-1.0 and TLS-1.1 sometime in 2020. Here are a few
> links which shine more light on the announcement.
>
> https://www.zdnet.com/article/chrome-edge-ie-firefox-and-safari-to-disable-tls-1-0-and-tls-1-1-in-2020/
>
>
> https://www.cso.com.au/article/648261/tls-1-0-1-1-will-disabled-edge-ie-chrome-firefox-safari-2020/
>
>
> https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls
>
> Now 2020 seems a long way off but web developers at my employer's

> company are already seeing TLS-1.0 and TLS-1.1 warnings in the AJAX much

> transport associated with "Developer Tools" in Chrome v73 so I suggest
> that anyone with an OpenVMS support contract at HPE contact them for
> support (previously they just send out a new version of file
> "mod_ssl.exe"). I just filed a support request with them this morning.
>
> Neil Rieck Waterloo, Ontario, Canada. http://neilrieck.net
>

Not that it helps CSWS much, but WASD got OpenSSL 1.1.1 (incl. TLS 1.3)
pre-support in May 2017 and the SSL 1.1.1 kit is from Nov 2018.

https://wasd.vsm.com.au/wasd_root/doc/misc/changes.html
https://wasd.vsm.com.au/wasd/

[Bill Gunshannon]

This is only peripherally related to VMS but it is a case of
the same effect. In talking about long term support (something
VMS is still claimed to have) it has been mentioned that MicroSoft
has sold longer term use of EOLed OSes like XP and Vista. Well,
being probably one of the last US users of either of these OSes
(mostly Vista!) I have run in to a similar problem as the one
stated above. None of the currently popular Web Browsers are
doing any versions for XP or Vista. What good is continued
vendor support of an OS if application support has been terminated?
Isn't this the same problem VMS users are going to start seeing
because of so much being so far behind the current standards of
the industry?

bill

[Stephen Hoffman]

On 2019-03-14 16:36:33 +0000, Neil Rieck said:

> Everyone reading this already knows that HP (now HPE) used to provide
> free updates for CSWS (a.k.a. Apache for OpenVMS) modules including
> SSL, Java, PHP, etc. All of those web pages have been redirected to the
> common OpenVMS landing page so I guess we can assume that those days
> are over.
>
> However, life goes on and I just learned that all major browsers are
> going to disable TLS-1.0 and TLS-1.1 sometime in 2020.

Upgrade to VSI OpenVMS.

For not the first time this has been mentioned, HPE is exiting the
OpenVMS new-patch business at the end of 2020.

Or port at least the web front-end to a different platform with a more
current web server.

With TLSv1.3 now available, all TLS prior to TLSv1.2 is headed for scrap.

I'm already routinely encountering minimal SSL connections requirements
for TLSv1.2 for connections, and the deprecation of all earlier SSL/TLS
connections.

As for the SSL and SSL1 kits, the foundation of SSL1 is OpenSSL 1.0.2
(LTS) and that is end-of-life at the end of this year. AFAIK, neither
HPE nor VSI offer the current 1.1.1 release as yet.
https://www.openssl.org/policies/releasestrat.html

While discussing certs and security with HPE, check whether the secure
delivery certificates have been updated, too. (I don't have a
currently-patched HPE OpenVMS V8.4 server handy to check.) The
longstanding (current?) HPE public cert will expire at the end of 2028,
which means that PCSI PRODUCT INSTALL and VMSINSTAL will start to fail
then absent various workarounds, which means y'all have until the end
of 2020 when new-patches support ends to get HPE to re-issue the root
public cert. HPE and VSI both updated to higher-level security, but I
don't recall HPE having re-issued the secure delivery root public cert
with an extended date.

--
Pure Personal Opinion | HoffmanLabs LLC

[Bill Gunshannon]

On 3/14/19 2:26 PM, Stephen Hoffman wrote:
>
>
> Or port at least the web front-end to a different platform with a more
> current web server.
>

But, that was my point exactly. I am being forced off of XP
and (mostly) Vista. I am not upgrading to Windows 7 or Windows
10. I am leaving Microsoft behind. (And recommending other
people do the same!!)

If a business is running on VMS and a major part of that business
is a web server front end and they have to move that front end to
a different platform where is the incentive to leave anything
still on the VMS system? I have worked with heterogeneous systems.
It ain't fun. Especially when something goes wrong and you have to
determine which platform is responsible (and I am not even talking
about the politics and finger pointing at the meeting tables!!)

bill

[Stephen Hoffman]

On 2019-03-14 18:26:28 +0000, Stephen Hoffman said:

> For not the first time this has been mentioned, HPE is exiting the
> OpenVMS new-patch business at the end of 2020.

If you want to or need to run older versions and older apps in
isolation, have at.

But for not the first time, it is not possible to stay on older
software releases forever. Not for very much past the end of the app-
or product- or OS-specific long-term support. Not if there's to be
network connectivity and heterogeneous operations.

We are on a treadmill, and the treadmill is only going to accelerate.
Security patches and related updates are not going to slow down.

This also causes issues for vendors, as they're necessarily updating
their own development efforts, and they're tracking security issues and
patches and more general updates in their dependencies, and testing the
related bits.

Which further gets back to my comment around the need for APIs that
isolate some of the API differences that can arise here. Those APIs
not just for end-users, too.

Yes, this all heads toward SaaS and subscriptions and the "fun" of
continuous releases, too.

This is the world we're in, whether we want it or not.

[Dave Froble]

On 3/14/2019 3:04 PM, Bill Gunshannon wrote:
> On 3/14/19 2:26 PM, Stephen Hoffman wrote:
>>
>>
>> Or port at least the web front-end to a different platform with a more
>> current web server.
>>
>
> But, that was my point exactly. I am being forced off of XP
> and (mostly) Vista. I am not upgrading to Windows 7 or Windows
> 10. I am leaving Microsoft behind. (And recommending other
> people do the same!!)

So what are you going to use? Specifically for the desktop?

I also do not like using WEENDOZE 7, and refuse to boot up 10.

> If a business is running on VMS and a major part of that business
> is a web server front end and they have to move that front end to
> a different platform where is the incentive to leave anything
> still on the VMS system? I have worked with heterogeneous systems.
> It ain't fun. Especially when something goes wrong and you have to
> determine which platform is responsible (and I am not even talking
> about the politics and finger pointing at the meeting tables!!)

What you do is design and implement the required interfaces. Not so
hard. It's even somewhat good to totally segregate some things. Easier
to determine where problems exist.

It's amusing to see the suggestions to "port". 40 years of specific
business logic just doesn't get re-implemented all that easily. Or
cheaply. Sort of tough to get a businessman to pay to re-implement
something he already has.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Dave Froble]

Makes me wonder. How difficult is it to move existing stuff from Apache
to WASD?

Of course, then, there is the problem of employees who figure it's the
employer's job to keep their resumes up to date and looking good.

[Neil Rieck]

I just received a newer version of "mod_ssl.exe" for Itanium which does not get me to the goal line but is newer than the one I am currently using. Unfortunately, this one is built against OpenSSL-1.0.2L (same as the client-side kit of the same name). I noticed a newer client-side kit available from the patch site, It is based upon OpenSSL-1.0-2O (that's two oh; not twenty).

I am still discussing this with HPE so will get back here if/when we have more news.

[Arne Vajhøj]

On 3/14/2019 4:40 PM, Dave Froble wrote:
> On 3/14/2019 1:25 PM, Jan-Erik Söderholm wrote:
>> Den 2019-03-14 kl. 17:36, skrev Neil Rieck:
>>> Everyone reading this already knows that HP (now HPE) used to provide
>>> free updates for CSWS (a.k.a. Apache for OpenVMS) modules including SSL,
>>> Java, PHP, etc. All of those web pages have been redirected to the
>>> common OpenVMS landing page so I guess we can assume that those days are
>>> over.
>>>
>>> However, life goes on and I just learned that all major browsers are
>>> going to disable TLS-1.0 and TLS-1.1 sometime in 2020. Here are a few
>>> links which shine more light on the announcement.

>>>  Now 2020 seems a long way off but web developers at my employer's
>>> company are already seeing TLS-1.0 and TLS-1.1 warnings in the AJAX much
>>> transport associated with "Developer Tools" in Chrome v73 so I suggest
>>> that anyone with an OpenVMS support contract at HPE contact them for
>>> support (previously they just send out a new version of file
>>> "mod_ssl.exe"). I just filed a support request with them this morning.

>> Not that it helps CSWS much, but WASD got OpenSSL 1.1.1 (incl. TLS 1.3)
>> pre-support in May 2017 and the SSL 1.1.1 kit is from Nov 2018.
>>
>> https://wasd.vsm.com.au/wasd_root/doc/misc/changes.html
>> https://wasd.vsm.com.au/wasd/

> Makes me wonder.  How difficult is it to move existing stuff from Apache
> to WASD?

Depends a lot on what the stuff is.

Static content : should be easy.

CGI scripts : probably easy.

Some very specific Apache modules : somewhere between hard and impossible

Arne

[Arne Vajhøj]

On 3/14/2019 3:04 PM, Bill Gunshannon wrote:

> On 3/14/19 2:26 PM, Stephen Hoffman wrote:
>> Or port at least the web front-end to a different platform with a more
>> current web server.
>
> But, that was my point exactly.

> If a business is running on VMS and a major part of that business
> is a web server front end and they have to move that front end to
> a different platform where is the incentive to leave anything
> still on the VMS system?  I  have worked with heterogeneous systems.
> It ain't fun.  Especially when something goes wrong and you have to
> determine which platform is responsible (and I am not even talking
> about the politics and finger pointing at the meeting tables!!)

I suspect that the companies running VMS typically already are
heterogeneous. Maybe not fun but reality.

Arne

[Bill Gunshannon]

On 3/14/19 4:38 PM, Dave Froble wrote:
> On 3/14/2019 3:04 PM, Bill Gunshannon wrote:
>> On 3/14/19 2:26 PM, Stephen Hoffman wrote:
>>>
>>>
>>> Or port at least the web front-end to a different platform with a more
>>> current web server.
>>>
>>
>> But, that was my point exactly.  I am being forced off of XP
>> and (mostly) Vista.  I am not upgrading to Windows 7 or Windows
>> 10.  I am leaving Microsoft behind. (And recommending other
>> people do the same!!)
>
> So what are you going to use?  Specifically for the desktop?

My every day, workhorse desktop is Ubuntu. Been working fine since
the machine (running Vista) died about 3 years ago. I also have it
on a couple of my laptops. Have not found anything Windows did that
these can not do and a lot of things they can do that Windows could
not.

>
> I also do not like using WEENDOZE 7, and refuse to boot up 10.

I refuse to pay any more money into the Microsoft coffers. Just wish
the government would adopt this idea as well and stop wasting billions
of taxpayers dollars making them rich.

>
>> If a business is running on VMS and a major part of that business
>> is a web server front end and they have to move that front end to
>> a different platform where is the incentive to leave anything
>> still on the VMS system?  I  have worked with heterogeneous systems.
>> It ain't fun.  Especially when something goes wrong and you have to
>> determine which platform is responsible (and I am not even talking
>> about the politics and finger pointing at the meeting tables!!)
>
> What you do is design and implement the required interfaces.  Not so
> hard.  It's even somewhat good to totally segregate some things.  Easier
> to determine where problems exist.

So you add a third layer in between giving yet another item to
point fingers at and blame. yeah, that's gonna work.

>
> It's amusing to see the suggestions to "port".  40 years of specific
> business logic just doesn't get re-implemented all that easily.  Or
> cheaply.  Sort of tough to get a businessman to pay to re-implement
> something he already has.
>

But when you are being forced off of a system by the lack of
current, required technology what choice do you really have?

bill

[Scott Dorsey]

Bill Gunshannon <bill.gu...@gmail.com> wrote:
> But, that was my point exactly.  I am being forced off of XP
> and (mostly) Vista.  I am not upgrading to Windows 7 or Windows
> 10.  I am leaving Microsoft behind. (And recommending other
> people do the same!!)

XP was -never- safe to use on the open internet, even when it was supported
by Microsoft. Now it's even less so. Since nobody in their right mind would
be using it on the internet, browser vendors are not supporting it.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Stephen Hoffman]

On 2019-03-14 21:10:22 +0000, Arne Vajh j said:

> On 3/14/2019 3:04 PM, Bill Gunshannon wrote:
>> On 3/14/19 2:26 PM, Stephen Hoffman wrote:
>>> Or port at least the web front-end to a different platform with a more
>>> current web server.
>>
>> But, that was my point exactly.

I wasn't replying to you with that posting, Bill.

>> If a business is running on VMS and a major part of that business is a
>> web server front end and they have to move that front end to a
>> different platform where is the incentive to leave anything still on
>> the VMS system?

The cost and the effort getting the apps ported off of OpenVMS,
usually. Inertia. This is the VSI market for the foreseeable future.

Or an established and long-time pool of experienced OpenVMS developers
working on the apps, and that either don't know or that are disinclined
to port or to learn different platforms and different tools and for any
of various good and bad reasons, for that matter.

Half-expecting to see somebody do a run of EDT4EVR stickers. If EDT
works for you, sure. But don't assume that most (any?) newer
developers are going to want to learn EDT. You'll have to pay them to
learn it and to contend with its limits. But I digress.

As for more general server configurations, web servers routinely
operate remotely from and separate from the associated database
servers. That's something that the common front-end web-oriented
languages make quite feasible.

>>   I  have worked with heterogeneous systems. It ain't fun.  Especially
>> when something goes wrong and you have to determine which platform is
>> responsible (and I am not even talking about the politics and finger
>> pointing at the meeting tables!!)
>
> I suspect that the companies running VMS typically already are
> heterogeneous. Maybe not fun but reality.

It'd be more interesting to find those organizations that weren't
heterogeneous, what with the prevalence of mobile clients and Windows
clients, and with integration with Windows Server and Active Directory
and and Exchange Server and other related services.

I'm sure there are still a few customers that are wholly based on
OpenVMS, and maybe even with VT terminals. Or that have non-networked
OpenVMS boxes. Most of those are probably using OpenVMS as an embedded
operating system, too.

But customers commonly using homogeneous configurations? Not a chance.

And not when OpenVMS isn't built, sold or positioned for front-end
client usage. Not that there's really been a supported front-end box
suitable for and priced for front-end client usage available with
OpenVMS in recent years. There are some folks using local or remote X
via DECwindows, not that that is seemingly all that common. I see
rather more command line and previous-millennium UIs, and web UIs. Not
so much X, though there's some around.

There are some folks using Apache on OpenVMS as a production front-end
for the server, any complaints around the various issues with the
commonly-down-revision components and with the utterly absurd
web-related packaging aside.

[Dave Froble]

But that's not happening.

True, SSL and certificates give us fits. But nothing much else. And
it's not like there is anything better available.

You present a case that doesn't exist. VMS works for us.

Really, what might be a possible replacement? Don't forget that 40
years of business logic. That is a critical part. Other vendors have
tried to compete. None came close.

Some might blithely say "port elsewhere". None seem to consider the
cost, both monetarily, and in mistakes that are sure to occur.

We on the other hand must consider such. We have done so. We don't
want to think of doing such a potentially disastrous and costly thing,
to end up with at best, what already exists. At best, most likely less.

Now, if you wish to actually consider the ramifications of what you
propose, before doing the proposing, that might be wise.

[Stephen Hoffman]

On 2019-03-15 19:45:54 +0000, Dave Froble said:

> You present a case that doesn't exist. VMS works for us.
>
> Really, what might be a possible replacement? Don't forget that 40
> years of business logic. That is a critical part. Other vendors have
> tried to compete. None came close.
>
> Some might blithely say "port elsewhere". None seem to consider the
> cost, both monetarily, and in mistakes that are sure to occur.
>
> We on the other hand must consider such. We have done so. We don't
> want to think of doing such a potentially disastrous and costly thing,
> to end up with at best, what already exists. At best, most likely less.
>
> Now, if you wish to actually consider the ramifications of what you
> propose, before doing the proposing, that might be wise.

As you quite correctly state, re-hosting and wholesale rewriting can be
(and variously will be) difficult for an incumbent provider with an
installed base. Incremental migration or incremental refactoring
(usually) being the most viable path.

Remember too to ponder whether a new competitor might be able to sell
at a lower price, with a different approach, with different tooling, or
a different platform. If a business isn't looking to undercut itself
and its own products and to attract new, somebody else can be. If
(when?) a "cheaper, and good enough" competitor appears, it can well be
too late for an incumbent.

As for OpenVMS and SSL and this particular comp.os.vms newsgroup
thread, Apache and a whole chain of other packages including SSL and
certificates and a password store should all have been fully integrated
into the base distro a decade ago. Trade-offs and assumptions and
expectations can and do change. What worked for a single-core VAX with
456 MB disks and 8 MB of RAM can be an entirely wrong trade-off when
desktops and low-end servers routinely operate with 16 or more cores,
64 GB of RAM, and a few dozen terabytes of SSD. And worse, as fast,
byte-addressable, persistent memory continues to arrive. And app
development tools on OpenVMS are weak, in the most charitable of terms.
Why do I mention this? Because this makes app development on OpenVMS
more tedious, more difficult, and variously more expensive.

There are always trade-offs with products and product updates and
pricing. Some management decisions will pay off. Some won't.

[Neil Rieck]

Strictly as an emergency backup plan, I've been working on trial to replace CSWS-2.2-1 with WASD-11.

For example, if my ~1,200 clients begin to use new browsers next year, they might not be able to connect to my current system so I have got to do something now. But that got me thinking about another problem: we are receiving B2B SOAP transactions from a system in Montreal (another company) which currently relies on SSLv3. If I upgrade my web-server to something that doesn't offer SSLv3 (because it hasn't been compiled into Apache's mod_ssl, or I've linked WASD to an SSL library that is too restrictive) then I'm not going to be able to receive those B2B SOAP connections.

After a restless night of sleep it occurred to me that many other systems are also going to run into this situation but no one seems to be talking about it (at least not in the way they talked about Y2K). So I have decided to call this problem "Y2K20" and have placed some preliminary notes here:

http://neilrieck.net/docs/calendar_time_y2k_etc.html#y2k20

[Steven Schweda]

> [...] I have decided to call this problem "Y2K20" [...]

Because "Y2020" would be so much less compact, and
wouldn't suggest "2200"?

[Neil Rieck]

:-)

[Arne Vajhøj]

I don't know how general the problem is.

OpenSSL and Apache httpd are open source.

You can build OpenSSL with the protocols you want.

In Apache config you can enable and disable the protocols you want.

Arne

[Arne Vajhøj]

Besides that then I would consider not serving static content and
web services from same server.

exposed web 1 serving static content
exposed web 2 web services

or

exposed web 1 serving static content and proxy to web 2
internal web 2 web services

or similar.

Arne

[Arne Vajhøj]

If your security people are strict they may insist on:

exposed web 0 proxy to web 1 and web 2
internal web 1 serving static content

internal web 2 web services

Arne

[Kerry Main]

While true, we should also remember, that in todays world, unless it is a small site, there are very few companies that are only using 1 type of OS platform. There is always some group that says "we really need XYZ application and the vendor says their preferred OS platform is [insert your favourite OS]"

The days of Windows only or Linux only or OpenVMS only or UNIX only platforms etc. are long gone for most med-large companies.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Stephen Hoffman]

On 2019-04-06 12:32:57 +0000, Neil Rieck said:

> Strictly as an emergency backup plan, I've been working on trial to
> replace CSWS-2.2-1 with WASD-11.

The current OpenVMS CSWS version is based on Apache HTTP Server V2.4-38.

Apache HTTP Server 2.4-39 is current.

List of security issues identified in the 2.4 series, including in 2.4-38:
https://httpd.apache.org/security/vulnerabilities_24.html

Building a new version of Apache on OpenVMS is somewhat of a project,
though it's possible.

Updating OpenSSL TLS would usually be a smaller project within an
existing Apache port, so long as the software versions involved aren't
too skewed.

Per Apache, "Apache HTTP Server version 2.4.39 or newer is required in
order to operate a TLS 1.3 web server with OpenSSL 1.1.1."

Also per Apache, "Please note the 2.2.x branch has now passed the end
of life at the Apache HTTP Server project and no further activity will
occur including security patches."

"Y2K20"? Obfuscare, err, obfuscate much? Why not MMXX? 🤪

[Scott Dorsey]

Kerry Main <kemain...@gmail.com> wrote:
>While true, we should also remember, that in todays world, unless it is =
>a small site, there are very few companies that are only using 1 type of =
>OS platform. There is always some group that says "we really need XYZ =
>application and the vendor says their preferred OS platform is [insert =
>your favourite OS]"

A lot of IT people think their company is only using one platform, as
they actively don't see (or sometimes have users deliberately hiding
from them) anything that doesn't look like their notion of what a
computer is.

[terry-...@glaver.org]

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. 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).

This would seem to be the perfect candidate to be turned over to freeware developers. There will always be sites that insist on running only "vendor released" software, but an actual security audit that finds a site running such horribly out-of-date and known-insecure software will likely cause a re-think of that. Plus, there's no reason that a vendor couldn't receive and review updates from a freeware developer and examine them (the differences should be small if this is done for each release) and then produce a signed version if desired by their customers.

The three things I think HP got wrong (and Compaq and DEC before them) are:

1) Thinking that "port once and done" is a workable solution, and when they find out it isn't, making another "port once and done" effort. This is something that needs to continuously track the upstream branch.

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).

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.

Back on the general topic of deprecated crypto libraries, some people may find my blog post "Is no crypto always better than bad crypto?" that I wrote over 3 years ago interesting: https://www.glaver.org/blog/?p=853

[Craig A. Berry]

On 4/6/19 5:54 PM, terry-...@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?

It is, but only if you are a VSI support customer and know which secret
rock to look under and have the magic decoder ring that allows you to
see what's under the rock.

[Robert A. Brooks]

On 4/6/2019 6:54 PM, terry-...@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. 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).

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 three things I think HP got wrong (and Compaq and DEC before them) are:

> 1) Thinking that "port once and done" is a workable solution, and when they
> find out it isn't, making another "port once and done" effort. This is
> something that needs to continuously track the upstream branch.

We are not going the DEC/CPQ/HP way. We've got a group of people
who are dedicated to open source work. The current big effort is with Samba.
I'm pretty sure that OpenSSL V1.1.1 is also underway.

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

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

--
-- Rob

[Dave Froble]

On 4/6/2019 8:17 PM, Robert A. Brooks wrote:
> On 4/6/2019 6:54 PM, terry-...@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. 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).
>
> 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.

That was my impression.

>> The three things I think HP got wrong (and Compaq and DEC before them)
>> are:
>
>> 1) Thinking that "port once and done" is a workable solution, and when
>> they
>> find out it isn't, making another "port once and done" effort. This is
>> something that needs to continuously track the upstream branch.
>
> We are not going the DEC/CPQ/HP way. We've got a group of people
> who are dedicated to open source work. The current big effort is with
> Samba.
> I'm pretty sure that OpenSSL V1.1.1 is also underway.

I'm in the process of installing and learning a bit about Mark Daniel's
WASD web server. Included, and optional, is the (I believe) OpenSSL
V1.1.1. At least it is claimed to do TLS V1.3.

Now, I have no idea if it is a complete port of OpenSSL, or, just enough
for WASD. Might be worth checking out, and if Mark can provide VMS
users with a good port of OpenSSL, why not take advantage of that?

[Stephen Hoffman]

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

> On 4/6/2019 6:54 PM, terry-...@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.

[Craig A. Berry]

On 4/6/19 8:58 PM, Stephen Hoffman wrote:
> So we have CSWS, which everybody obviously knows is a web
> server.

Not just a web server, but a secure web server from a company named
Compaq that never knew anything about servers or security.

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

Some VMS-friendly wrapper functions might be nice. But as far as the
underlying crypto, it would be unwise for VSI to roll any of that on
their own.

[terry-...@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?

[Neil Rieck]

The current version of CSWS for OpenVMS from HPE is based upon Apache 2.0.63

The current version of CSWS for OpenVMS from VSI is based upon Apache 2.4.12 according to this link.

We attempted to move support from HPE to VSI last year but our management would not approve the purchase of software relicensing by VSI. If they had then I would not find myself in this dilemma; which is why I'm experimenting with WASD.

p.s. managers are always moving around. There is a high likelihood that when dung-hits-the-fan next year, they'll be gone and I'll be blamed for not having a workaround waiting in the wings. A career limiting situation indeed.

[Bill Gunshannon]

On 4/7/19 10:06 AM, Neil Rieck wrote:
>
> We attempted to move support from HPE to VSI last year but our management would not approve the purchase of software relicensing by VSI.

I know this is not what people want to hear and I will be blamed
for the bad news (always shoot the messenger!) but I have seen
this as a potential sticking point since the announcement of the
creation of VSI.

When the recent discussion about Intersystems was going
on I saw it again. There is a very finite expense in
VARs moving to the new version of VMS. Both on the
current architecture and on the future new architecture.
One must buy new equipment to develop, test and maintain
the product on the new architecture. One must buy the
new version of the OS and the necessary licenses to use
it. And one must weigh that cost against expected revenues.
When one was already considering dropping support it can
become very hard to justify the needed expense when one
has other platforms that more than supply the revenue
to keep the company successful.

Sadly, I think this forced change may be more detrimental
to the continued success of VMS than people either expect
or want. And, the way HPE is handling their end (at least
from what I can see and my perception of it) is not going
to help. They wanted to kill VMS. I think they still do
because its continued success would reflect badly on their
decision to kill it. I expect they will do nothing to aids
in VSI's successful revival of VMS and quite the contrary
will do all they can to scuttle it.

bill

[Craig A. Berry]

On 4/7/19 9:21 AM, Bill Gunshannon wrote:
> On 4/7/19 10:06 AM, Neil Rieck wrote:
>>
>> We attempted to move support from HPE to VSI last year but our
>> management would not approve the purchase of software relicensing by VSI.
>
> I know this is not what people want to hear and I will be blamed
> for the bad news (always shoot the messenger!) but I have seen
> this as a potential sticking point since the announcement of the
> creation of VSI.

If you were the conveyor of non-bogus information, then people might be
more receptive.

> When the recent discussion about Intersystems was going
> on I saw it again.  There is a very finite expense in
> VARs moving to the new version of VMS.  Both on the
> current architecture and on the future new architecture.
> One must buy new equipment to develop, test and maintain
> the product on the new architecture.  One must buy the
> new version of the OS and the necessary licenses to use
> it.  And one must weigh that cost against expected revenues.

When we moved to VSI from HPE a couple of years ago at the time our HPE
support contract was expiring, it was a whole lot cheaper to get a
support contract with VSI including new licenses than to renew with HPE.
So switching to VSI meant saving money immediately, not incurring any
extra expense. Our licenses included upgrade rights to the x86_64
version when it becomes available.

People running unsupported will have some cash outlay to switch to VSI.
But people running unsupported are not planning for the future anyway.

As far as buying new hardware to make a platform switch, do you really
think it will be cheaper to maintain 10-20-year-old Alpha or Integrity
hardware over the next five years than to get some brand new x86 kit (or
possibly just spin up some VM instances on a host most companies already
have available)?

[Bill Gunshannon]

On 4/7/19 11:20 AM, Craig A. Berry wrote:
> On 4/7/19 9:21 AM, Bill Gunshannon wrote:
>> On 4/7/19 10:06 AM, Neil Rieck wrote:
>>>
>>> We attempted to move support from HPE to VSI last year but our
>>> management would not approve the purchase of software relicensing by
>>> VSI.
>>
>> I know this is not what people want to hear and I will be blamed
>> for the bad news (always shoot the messenger!) but I have seen
>> this as a potential sticking point since the announcement of the
>> creation of VSI.
>
> If you were the conveyor of non-bogus information, then people might be
> more receptive.
>

Why do you say it was bogus? Neil just posted an example from his
own personal experience supporting it. Others have been mentioned
here in the past. And I remember similar (for other products) from
my days in the business and academic world.

>> When the recent discussion about Intersystems was going
>> on I saw it again.  There is a very finite expense in
>> VARs moving to the new version of VMS.  Both on the
>> current architecture and on the future new architecture.
>> One must buy new equipment to develop, test and maintain
>> the product on the new architecture.  One must buy the
>> new version of the OS and the necessary licenses to use
>> it.  And one must weigh that cost against expected revenues.
>
> When we moved to VSI from HPE a couple of years ago at the time our HPE
> support contract was expiring, it was a whole lot cheaper to get a
> support contract with VSI including new licenses than to renew with HPE.

You were lucky. Are everyone's licenses going to expire at just
the right time?

>  So switching to VSI meant saving money immediately, not incurring any
> extra expense.  Our licenses included upgrade rights to the x86_64
> version when it becomes available.

But that doesn't pay for the new equipment which will be an
additional expense. Management look at everything. If they
have to buy new machines and new software and new licenses
they will be looking at the big picture. And the competitors
to VMS are going to be more in the front of their minds
because they see the ads on TV during the golf and in their
trade journals and on billboards when they drive to work.

>
> People running unsupported will have some cash outlay to switch to VSI.
>  But people running unsupported are not planning for the future anyway.

That's true and I never said it wasn't. The only people who matter
are the ones spending money.

>
> As far as buying new hardware to make a platform switch, do you really
> think it will be cheaper to maintain 10-20-year-old Alpha or Integrity
> hardware over the next five years than to get some brand new x86 kit (or
> possibly just spin up some VM instances on a host most companies already
> have available)?

No, I don't think it will be cheaper. But, going back to the
Intersystems example. Dou you think it will be cheaper (or
more profitable) to invest in the move to X86-64 VMS than to
just let the VMS support wither and die? The sell their
product on a lot of long-term viable systems. Is there really
likely to be enough business left on VMS to justify the expense
of maintaining it.

Not saying it is a bad idea, just trying to get past the blinders
of people here and point out that the picture is not as rosy as
some would like it to be. It's hard sell and with the negative
picture that HPE continues to paint, it isn't going to get better.

Tell me, has HPE provided VSI with their VMS customer list so that
VSI can actively talk with these people about migrating? Last
thing about I saw about that here was "No".

bill

[Jan-Erik Söderholm]

Den 2019-04-07 kl. 17:49, skrev Bill Gunshannon:
> On 4/7/19 11:20 AM, Craig A. Berry wrote:
>> On 4/7/19 9:21 AM, Bill Gunshannon wrote:
>>> On 4/7/19 10:06 AM, Neil Rieck wrote:
>>>>
>>>> We attempted to move support from HPE to VSI last year but our
>>>> management would not approve the purchase of software relicensing by VSI.
>>>
>>> I know this is not what people want to hear and I will be blamed
>>> for the bad news (always shoot the messenger!) but I have seen
>>> this as a potential sticking point since the announcement of the
>>> creation of VSI.
>>
>> If you were the conveyor of non-bogus information, then people might be
>> more receptive.
>>
>
> Why do you say it was bogus?  Neil just posted an example from his
> own personal experience supporting it.

Neil posted one example from one specific company. I can post another
example from another specific company that did the opposite. So then
we are even, right?

>> When we moved to VSI from HPE a couple of years ago at the time our HPE
>> support contract was expiring, it was a whole lot cheaper to get a
>> support contract with VSI including new licenses than to renew with HPE.
>
> You were lucky.  Are everyone's licenses going to expire at just
> the right time?

Everyone's licences will expire when the support from HPE ends.
What would the "right time" be otherwise?

>
>>   So switching to VSI meant saving money immediately, not incurring any
>> extra expense.  Our licenses included upgrade rights to the x86_64
>> version when it becomes available.
>
> But that doesn't pay for the new equipment which will be an
> additional expense.

The usual x86 server replacement period is 3-4 years. How could it
then be an issue to replace some 10-15 year old Alpha with x86?

> Not saying it is a bad idea, just trying to get past the blinders
> of people here and point out that the picture is not as rosy as
> some would like it to be.  It's hard sell and with the negative

> picture...

What "negative picture". They have transferred the maintenance
of VMS to someone else and are winding down their own business.
What else could they do?

> that HPE continues to paint, it isn't going to get better.
>
> Tell me,

Ask VSI if you need to know.

[Scott Dorsey]

Bill Gunshannon <bill.gu...@gmail.com> wrote:
>But that doesn't pay for the new equipment which will be an
>additional expense. Management look at everything. If they
>have to buy new machines and new software and new licenses
>they will be looking at the big picture. And the competitors
>to VMS are going to be more in the front of their minds
>because they see the ads on TV during the golf and in their
>trade journals and on billboards when they drive to work.

Computers are cheap. Support is expensive.

If you're already paying for support, the new software and new licenses
will be coming along for free in the bargain. Your cost is the
hardware and that of transitioning your own software in that day when the
move to x86 becomes essential.

If you're not paying for support, then you have more serious problems
to worry about.

Timeline: you move from HPE support to VSI support right now. This is
likely to be a cost savings rather than an extra cost. When the x86 port
comes along, you buy x86 hardware and move your applications to it. That
will cost money, but that's not today, and it's likely a drop in the
bucket compared with the support costs.

If, on the other hand, you are running unsupported software on unsupported
hardware, you have the choice of either putting up the money and getting
support, or continuing on with the same path. Depending on how critical
your system is, you may realistically prefer either one. I have a vax
right now in the corner of the machine room for reading the occaisonal
9-track tape. The OS is not supportable, neither is the hardware, but if
it breaks I'll fix it. If it takes a few weeks for me to get it done,
that's okay. It doesn't need support. On the other hand, we also have
critical systems that need and have support.

[Dave Froble]

On 4/7/2019 10:21 AM, Bill Gunshannon wrote:
> On 4/7/19 10:06 AM, Neil Rieck wrote:
>>
>> We attempted to move support from HPE to VSI last year but our
>> management would not approve the purchase of software relicensing by VSI.

I'm not aware of VSI's pricing, but, if long term support is desired,
then I personally think it is just stupid to charge any significant
re-licensing fees. That just means they won't get the support money.

It would be interesting to know just what fees were quoted. And for how
many systems. Be a good indicator of which side, or both, are being
unreasonable.

> I know this is not what people want to hear and I will be blamed
> for the bad news (always shoot the messenger!) but I have seen
> this as a potential sticking point since the announcement of the
> creation of VSI.
>
> When the recent discussion about Intersystems was going
> on I saw it again. There is a very finite expense in
> VARs moving to the new version of VMS. Both on the
> current architecture and on the future new architecture.
> One must buy new equipment to develop, test and maintain
> the product on the new architecture. One must buy the
> new version of the OS and the necessary licenses to use
> it. And one must weigh that cost against expected revenues.
> When one was already considering dropping support it can
> become very hard to justify the needed expense when one
> has other platforms that more than supply the revenue
> to keep the company successful.

Well, you just made a big leap there Bill, with nothing to justify it.
I did not notice Neil mentioning any plans to drop support, or move to
alternates.

> Sadly, I think this forced change may be more detrimental
> to the continued success of VMS than people either expect
> or want. And, the way HPE is handling their end (at least
> from what I can see and my perception of it) is not going
> to help. They wanted to kill VMS. I think they still do
> because its continued success would reflect badly on their
> decision to kill it. I expect they will do nothing to aids
> in VSI's successful revival of VMS and quite the contrary
> will do all they can to scuttle it.

If HP(e) wanted to kill VMS, all they had to do was not give it to VSI.

Then again, they may have had some legal reasons to do so. Doesn't mean
they want VSI to succeed.

The bottom line, VSI should be taking the "long view" if they want to
succeed.

[Arne Vajhøj]

On 4/7/2019 10:21 AM, Bill Gunshannon wrote:

> When the recent discussion about Intersystems was going
> on I saw it again.  There is a very finite expense in
> VARs moving to the new version of VMS.  Both on the
> current architecture and on the future new architecture.
> One must buy new equipment to develop, test and maintain
> the product on the new architecture.  One must buy the
> new version of the OS and the necessary licenses to use
> it.  And one must weigh that cost against expected revenues.
> When one was already considering dropping support it can
> become very hard to justify the needed expense when one
> has other platforms that more than supply the revenue
> to keep the company successful.

They don't need to buy new x86-64 HW - they can run it on VM's.

And I expect that VSI offer ISV's (I assume you mean ISV's not VAR's)
licenses for free or very little.

So the cost is the effort to port and test. Which obviously
can be substantial.

> Sadly, I think this forced change may be more detrimental
> to the continued success of VMS than people either expect
> or want.

The move from Itanium to x86-64 will certainly hurt VMS short term.

But given that Itanium is dead then either VMS move or VMS is dead. It
was not a real choice.

And long term being on a standard HW platform may turn out to be a good
thing.

Arne

[Robert A. Brooks]

On 4/7/2019 2:54 PM, Arne Vajhøj wrote:
> On 4/7/2019 10:21 AM, Bill Gunshannon wrote:
>> When the recent discussion about Intersystems was going
>> on I saw it again.  There is a very finite expense in
>> VARs moving to the new version of VMS.  Both on the
>> current architecture and on the future new architecture.
>> One must buy new equipment to develop, test and maintain
>> the product on the new architecture.  One must buy the
>> new version of the OS and the necessary licenses to use
>> it.  And one must weigh that cost against expected revenues.
>> When one was already considering dropping support it can
>> become very hard to justify the needed expense when one
>> has other platforms that more than supply the revenue
>> to keep the company successful.
>
> They don't need to buy new x86-64 HW - they can run it on VM's.
>
> And I expect that VSI offer ISV's (I assume you mean ISV's not VAR's)
> licenses for free or very little.

That's correct.


--
-- Rob

[Bill Gunshannon]

On 4/7/19 2:54 PM, Arne Vajhøj wrote:
> On 4/7/2019 10:21 AM, Bill Gunshannon wrote:
>> When the recent discussion about Intersystems was going
>> on I saw it again.  There is a very finite expense in
>> VARs moving to the new version of VMS.  Both on the
>> current architecture and on the future new architecture.
>> One must buy new equipment to develop, test and maintain
>> the product on the new architecture.  One must buy the
>> new version of the OS and the necessary licenses to use
>> it.  And one must weigh that cost against expected revenues.
>> When one was already considering dropping support it can
>> become very hard to justify the needed expense when one
>> has other platforms that more than supply the revenue
>> to keep the company successful.
>
> They don't need to buy new x86-64 HW - they can run it on VM's.

And those are free?

>
> And I expect that VSI offer ISV's (I assume you mean ISV's not VAR's)
> licenses for free or very little.

I certainly have n ot heard of anyone getting free licenses. Anybody
want to confirm that? Very little is a subjective term. How much
"very little" actually is may depend on which side of the fence you
are standing.

>
> So the cost is the effort to port and test. Which obviously
> can be substantial.

And maintain after you have ported and tested.

>
>> Sadly, I think this forced change may be more detrimental
>> to the continued success of VMS than people either expect
>> or want.
>
> The move from Itanium to x86-64 will certainly hurt VMS short term.
>
> But given that Itanium is dead then either VMS move or VMS is dead. It
> was not a real choice.
>
> And long term being on a standard HW platform may turn out to be a good
> thing.

Yes, it may. And believe it or not, I would like to see that happen.
But some people really need to look at this from the point of view
of the outside world. It is not as rosy as many want to see it.

bill

[Bill Gunshannon]

On 4/7/19 12:59 PM, Dave Froble wrote:
> On 4/7/2019 10:21 AM, Bill Gunshannon wrote:
>> On 4/7/19 10:06 AM, Neil Rieck wrote:
>>>
>>> We attempted to move support from HPE to VSI last year but our
>>> management would not approve the purchase of software relicensing by
>>> VSI.
>
> I'm not aware of VSI's pricing, but, if long term support is desired,
> then I personally think it is just stupid to charge any significant
> re-licensing fees.  That just means they won't get the support money.

He didn't say how much it was. he said they would not approve it.
The one may not have been the reason for the other.

>
> It would be interesting to know just what fees were quoted.  And for how
> many systems.  Be a good indicator of which side, or both, are being
> unreasonable.

From their own point of view, I doubt either is unreasonable.

>
>> I know this is not what people want to hear and I will be blamed
>> for the bad news (always shoot the messenger!) but I have seen
>> this as a potential sticking point since the announcement of the
>> creation of VSI.
>>
>> When the recent discussion about Intersystems was going
>> on I saw it again.  There is a very finite expense in
>> VARs moving to the new version of VMS.  Both on the
>> current architecture and on the future new architecture.
>> One must buy new equipment to develop, test and maintain
>> the product on the new architecture.  One must buy the
>> new version of the OS and the necessary licenses to use
>> it.  And one must weigh that cost against expected revenues.
>> When one was already considering dropping support it can
>> become very hard to justify the needed expense when one
>> has other platforms that more than supply the revenue
>> to keep the company successful.
>
> Well, you just made a big leap there Bill, with nothing to justify it. I
> did not notice Neil mentioning any plans to drop support, or move to
> alternates.

In that paragraph I was talking about Intersystems and Cache.
While some have said they heard otherwise the web page still
says no new VMS versions. If no new VMS versions are going
to be forthcoming people using Intersystems Cache on VMS
have only two choices. Stay where they are to move to a
system that has a path forward.

>
>> Sadly, I think this forced change may be more detrimental
>> to the continued success of VMS than people either expect
>> or want.  And, the way HPE is handling their end (at least
>> from what I can see and my perception of it) is not going
>> to help.  They wanted to kill VMS.  I think they still do
>> because its continued success would reflect badly on their
>> decision to kill it.  I expect they will do nothing to aids
>> in VSI's successful revival of VMS and quite the contrary
>> will do all they can to scuttle it.
>
> If HP(e) wanted to kill VMS, all they had to do was not give it to VSI.

If they did that they would live the possible bad press of their
failure with VMS to come back and haunt them in the future. Now,
if VMS fails the blame lands squarely on VSI's shoulders.

>
> Then again, they may have had some legal reasons to do so.  Doesn't mean
> they want VSI to succeed.

I don;t think they care about VSI. I think it is all about VMS
and corporate image.

>
> The bottom line, VSI should be taking the "long view" if they want to
> succeed.

I am sure they are. But I also think that it is a long uphill
battle and HPE, who could be helping at no real cost to themselves
are actually doing the opposite.

bill

[Bill Gunshannon]

On 4/7/19 12:05 PM, Jan-Erik Söderholm wrote:
> Den 2019-04-07 kl. 17:49, skrev Bill Gunshannon:
>> On 4/7/19 11:20 AM, Craig A. Berry wrote:
>>> On 4/7/19 9:21 AM, Bill Gunshannon wrote:
>>>> On 4/7/19 10:06 AM, Neil Rieck wrote:
>>>>>
>>>>> We attempted to move support from HPE to VSI last year but our
>>>>> management would not approve the purchase of software relicensing
>>>>> by VSI.
>>>>
>>>> I know this is not what people want to hear and I will be blamed
>>>> for the bad news (always shoot the messenger!) but I have seen
>>>> this as a potential sticking point since the announcement of the
>>>> creation of VSI.
>>>
>>> If you were the conveyor of non-bogus information, then people might be
>>> more receptive.
>>>
>>
>> Why do you say it was bogus?  Neil just posted an example from his
>> own personal experience supporting it.
>
> Neil posted one example from one specific company. I can post another
> example from another specific company that did the opposite. So then
> we are even, right?

Even in this race is a loser.
Example: There are 100 companies running HPE VMS.
50 move to VSI VMS.
50 move to Linux or Windows.

Even, right?

>
>>> When we moved to VSI from HPE a couple of years ago at the time our HPE
>>> support contract was expiring, it was a whole lot cheaper to get a
>>> support contract with VSI including new licenses than to renew with HPE.
>>
>> You were lucky.  Are everyone's licenses going to expire at just
>> the right time?
>
> Everyone's licences will expire when the support from HPE ends.
> What would the "right time" be otherwise?

And how many of them will be left with a bitter taste in their mouth.
And before you say none, how many people here really dislike HP/HPE
over the past treatment of VMS? And, how many of these will choose
to take it out on VMS rather than HPE who will have left the game.

>
>>
>>>   So switching to VSI meant saving money immediately, not incurring any
>>> extra expense.  Our licenses included upgrade rights to the x86_64
>>> version when it becomes available.
>>
>> But that doesn't pay for the new equipment which will be an
>> additional expense.
>
> The usual x86 server replacement period is 3-4 years. How could it
> then be an issue to replace some 10-15 year old Alpha with x86?

We are not talking about replacing the Alphas. We are talking
about having to develop software on the new machine while still
running on the Alpha. This is not a light switch solution where
you can turn one off turn the other on and continue operations.

>
>> Not saying it is a bad idea, just trying to get past the blinders
>> of people here and point out that the picture is not as rosy as
>> some would like it to be.  It's hard sell and with the negative
>> picture...
>
> What "negative picture". They have transferred the maintenance
> of VMS to someone else and are winding down their own business.
> What else could they do?

Actively work on convincing their current installed VMS base
to move over to VSI. Anybody heard about them doing that?

>
>> that HPE continues to paint, it isn't going to get better.
>>
>> Tell me,
>
> Ask VSI if you need to know.

bill

[Dave Froble]

On 4/7/2019 7:58 PM, Bill Gunshannon wrote:
> On 4/7/19 2:54 PM, Arne Vajhøj wrote:
>> On 4/7/2019 10:21 AM, Bill Gunshannon wrote:
>>> When the recent discussion about Intersystems was going
>>> on I saw it again. There is a very finite expense in
>>> VARs moving to the new version of VMS. Both on the
>>> current architecture and on the future new architecture.
>>> One must buy new equipment to develop, test and maintain
>>> the product on the new architecture. One must buy the
>>> new version of the OS and the necessary licenses to use
>>> it. And one must weigh that cost against expected revenues.
>>> When one was already considering dropping support it can
>>> become very hard to justify the needed expense when one
>>> has other platforms that more than supply the revenue
>>> to keep the company successful.
>>
>> They don't need to buy new x86-64 HW - they can run it on VM's.
>
> And those are free?

Nothing is free. TANSTAAFL ...

But, if you'e going to run some stuff on some system, then isn't the
cost going to be there, regardless of what system?

Stop expounding a double standard ...

>> And I expect that VSI offer ISV's (I assume you mean ISV's not VAR's)
>> licenses for free or very little.
>
> I certainly have n ot heard of anyone getting free licenses. Anybody
> want to confirm that? Very little is a subjective term. How much
> "very little" actually is may depend on which side of the fence you
> are standing.

Here you go ...

OpenVMS V8.4-2L1 on node AS800 7-APR-2019 21:23:51.78 Uptime 66
06:13:48

Courtesy of a VSI developer's license.

Confirmed now?

Oh, yeah, and I have VMS V8.4 2L2 for my EV6 systems, though not using
them at this time.

I will admit it would be nice to have the new TCP/IP to learn from, but,
I can be patient.

>> So the cost is the effort to port and test. Which obviously
>> can be substantial.
>
> And maintain after you have ported and tested.

Again, tell me how that would differ in any other environment? It's a
wash. W A S H !!!

Actually, if one is on VMS, then any change to anything else will be
more expensive. Sometimes too expensive to survive.

>
>>
>>> Sadly, I think this forced change may be more detrimental
>>> to the continued success of VMS than people either expect
>>> or want.
>>
>> The move from Itanium to x86-64 will certainly hurt VMS short term.
>>
>> But given that Itanium is dead then either VMS move or VMS is dead. It
>> was not a real choice.
>>
>> And long term being on a standard HW platform may turn out to be a good
>> thing.
>
> Yes, it may. And believe it or not, I would like to see that happen.
> But some people really need to look at this from the point of view
> of the outside world. It is not as rosy as many want to see it.

If the outside world has vision problems, that is an issue, and one
"they" will suffer from. Or, they can have an ounce of sense.

One thing is clear, and if you do not agree, then you're fooling
yourself, or just being difficult.

It is always easier and cheaper to remain with what works and is in hand
than to convert to something else, all else being equal. With VMS on
x86 and VMs, it seems all else will be at least equal.

Now, are you done crying "Wolf!"

[Dave Froble]

Another Bill post to stomp upon ...

You are correct, it is NOT even. There is NO WAY anyone will take
applications running on VMS and move them to anything else, including
Linux, without spending much more money. MUCH MORE!

>>>> When we moved to VSI from HPE a couple of years ago at the time our HPE
>>>> support contract was expiring, it was a whole lot cheaper to get a
>>>> support contract with VSI including new licenses than to renew with
>>>> HPE.
>>>
>>> You were lucky. Are everyone's licenses going to expire at just
>>> the right time?
>>
>> Everyone's licences will expire when the support from HPE ends.
>> What would the "right time" be otherwise?
>
> And how many of them will be left with a bitter taste in their mouth.
> And before you say none, how many people here really dislike HP/HPE
> over the past treatment of VMS? And, how many of these will choose
> to take it out on VMS rather than HPE who will have left the game.

Bitter about HP(e)s treatment of VMS? Bitter doesn't even begin to
describe it. The only way I would not piss on HP(e) is if they were on
fire.

VSI has my gratitude ...

>>>> So switching to VSI meant saving money immediately, not incurring any
>>>> extra expense. Our licenses included upgrade rights to the x86_64
>>>> version when it becomes available.
>>>
>>> But that doesn't pay for the new equipment which will be an
>>> additional expense.

You won't need "new equipment" for Linux? You are so full of FUD.

>> The usual x86 server replacement period is 3-4 years. How could it
>> then be an issue to replace some 10-15 year old Alpha with x86?
>
> We are not talking about replacing the Alphas. We are talking
> about having to develop software on the new machine while still
> running on the Alpha. This is not a light switch solution where
> you can turn one off turn the other on and continue operations.

It was just that for us with the Alpha to itanic port. Re-compile,
re-link, move data files, and run.

Yes, transferring the data files took just a bit longer than flicking a
light switch.

>>> Not saying it is a bad idea, just trying to get past the blinders
>>> of people here and point out that the picture is not as rosy as
>>> some would like it to be. It's hard sell and with the negative
>>> picture...
>>
>> What "negative picture". They have transferred the maintenance
>> of VMS to someone else and are winding down their own business.
>> What else could they do?
>
> Actively work on convincing their current installed VMS base
> to move over to VSI. Anybody heard about them doing that?

Yes ...

>>> that HPE continues to paint, it isn't going to get better.
>>>
>>> Tell me,
>>
>> Ask VSI if you need to know.
>
>
> bill
>
>

[Dave Froble]

Web sites are never out of date, or missing information? BA HA HA HA

>>> Sadly, I think this forced change may be more detrimental
>>> to the continued success of VMS than people either expect
>>> or want. And, the way HPE is handling their end (at least
>>> from what I can see and my perception of it) is not going
>>> to help. They wanted to kill VMS. I think they still do
>>> because its continued success would reflect badly on their
>>> decision to kill it. I expect they will do nothing to aids
>>> in VSI's successful revival of VMS and quite the contrary
>>> will do all they can to scuttle it.
>>
>> If HP(e) wanted to kill VMS, all they had to do was not give it to VSI.
>
> If they did that they would live the possible bad press of their
> failure with VMS to come back and haunt them in the future. Now,
> if VMS fails the blame lands squarely on VSI's shoulders.
>
>>
>> Then again, they may have had some legal reasons to do so. Doesn't
>> mean they want VSI to succeed.
>
> I don;t think they care about VSI. I think it is all about VMS
> and corporate image.
>
>>
>> The bottom line, VSI should be taking the "long view" if they want to
>> succeed.
>
>
> I am sure they are. But I also think that it is a long uphill
> battle and HPE, who could be helping at no real cost to themselves
> are actually doing the opposite.

Frankly, I'd be afraid of any more HP(e) help, seeing what they have
done in the past, and even now.

[Stephen Hoffman]

On 2019-04-07 14:06:20 +0000, Neil Rieck said:

> The current version of CSWS for OpenVMS from HPE is based upon Apache 2.0.63

HPE is exiting the OpenVMS business, with new-patch support ending in
less than two years. I'd expect the HPE investments to taper over
time, too.

> The current version of CSWS for OpenVMS from VSI is based upon Apache
> 2.4.12 according to this link.

For not the first time I have stated this in this thread, the current
VSI CSWS Apache Web Server version is V2.4-38. If what is posted on
the VSI web site doesn't indicate that, what is posted is stale.

> We attempted to move support from HPE to VSI last year but our
> management would not approve the purchase of software relicensing by
> VSI. If they had then I would not find myself in this dilemma; which is
> why I'm experimenting with WASD.

Then keep records, and expect to toss the whole discussion back at your
management, as part of transitioning from HPE support to VSI support;
positioned as a one-time on-boarding fee or transition fee or whatever.
It'd be nice if the licensing could be buried in the support costs,
but that's not currently the case. The current VSI web site and the
VSI communications and the lack of a list price price list aren't
particularly helpful here, either.

> p.s. managers are always moving around. There is a high likelihood that
> when dung-hits-the-fan next year, they'll be gone and I'll be blamed
> for not having a workaround waiting in the wings. A career limiting
> situation indeed.

I'm familiar with organizations that use "bungee bosses", and with the
energy and the effort entailed with bringing each new boss up to speed,
and with the organizational knock-off effects when a mix of good boss
and bad bosses transition through an organization, and how those
managers pick good and bad managers and staff. This managerial churn
can be quite challenging. Both for the staff, and for the up-or-out
policies that the managers themselves are generally measured by.

[Stephen Hoffman]

On 2019-04-07 02:59:52 +0000, Craig A. Berry said:

> On 4/6/19 8:58 PM, Stephen Hoffman wrote:
>> So we have CSWS, which everybody obviously knows is a web server.
>
> Not just a web server, but a secure web server from a company named
> Compaq that never knew anything about servers or security.

CSWS, SWB, the oddly-named-and-why-are-these-even-separate Apache
language modules, T4, etc.
Terms such as LP and "host-based volume shadowing", for that matter.
LMF, PAKs, etc.
Process has similar issues with the lack of references to "firewall" in
their Multinet docs, IIRC.
There's "autogen", which by all appearances neither autos nor gens, and
with a name that is clear if you knew RSX-11. Why that even still
exists is another discussion.
This certainly isn't going to change for existing environments, but
OpenVMS folks are way too fond of OpenVMS-isms in naming, in
documentation, and in API designs.
Common terms are helpful, both to existing users and particularly to new users.

>> 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.
>
> Some VMS-friendly wrapper functions might be nice. But as far as the
> underlying crypto, it would be unwise for VSI to roll any of that on
> their own.

Wouldn't suggest home-grown cryptography. That often ends badly. As
for wrapping, that's what the Apple frameworks provide. Secure
Transport, the Network Framework, etc., wrap libtls, as well as dealing
with DNS and sockets and certificates.

https://developer.apple.com/security/

Do I expect VSI to crib Apple here? No. I reference this so that
folks can see what's been happening in the past decade or two; in the
era since the OpenVMS frameworks have been substantially updated.

And as I've commented elsewhere, go try writing a secure network
connection using DNS, and self-signed root certificate authority and
certificates and CSRs, and sockets. Now work through the failure modes
and the attacks, and "minor" details such as certificate renewals.
Apps with errors and vulnerabilities are probably the norm here, too.
Now make this work with IPv6.

Apple's been rolling all of this right into their networking framework,
past what Secure Transport provides. As have other folks, I'd expect.

[Dave Froble]

On 4/8/2019 1:23 PM, Stephen Hoffman wrote:
> On 2019-04-07 02:59:52 +0000, Craig A. Berry said:
>
>> On 4/6/19 8:58 PM, Stephen Hoffman wrote:
>>> So we have CSWS, which everybody obviously knows is a web server.
>>
>> Not just a web server, but a secure web server from a company named
>> Compaq that never knew anything about servers or security.
>
> CSWS, SWB, the oddly-named-and-why-are-these-even-separate Apache
> language modules, T4, etc.
> Terms such as LP and "host-based volume shadowing", for that matter.
> LMF, PAKs, etc.

Host based mirroring might be a bit more understood, but volume
shadowing sure isn't all that mysterious.

LMF and PAKs should just go away.

Usually when a "challenge" is issued, there will be those who pick up
the gauntlet. I figured at least two methods to get past the LMF. No,
I'm not saying. It wasn't to actually do so, just to answer the challenge.

Thing is, and it's been said before, LMF isn't to stop piracy. If
someone wants it, they will get it. Just ask Bill Gates about the
Chinese. So, all LMF does is harrass those who respect it. Get VMS in
front of as many as possible. Those who will purchase support will do
so. Those who won't don't. No real loss.

> Process has similar issues with the lack of references to "firewall" in
> their Multinet docs, IIRC.
> There's "autogen", which by all appearances neither autos nor gens, and
> with a name that is clear if you knew RSX-11. Why that even still
> exists is another discussion.

Yeah, I'd like to see some SYSGEN parameters just go away, or by default
be set so that needing to change them will be rare. I doubt we'll see
an x86 server with less than 16 GB of memory, and maybe much more.

> This certainly isn't going to change for existing environments, but
> OpenVMS folks are way too fond of OpenVMS-isms in naming, in
> documentation, and in API designs.
> Common terms are helpful, both to existing users and particularly to new
> users.
>
>>> 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.

Please! And better documentation, and ease, for what is necessary.
Certificates are obscure, at least I think so, and they aren't any
better, that I'm aware of, on other platforms.

>>> Alternatives to OpenSSL include NaCl and libtls, among others.
>>
>> Some VMS-friendly wrapper functions might be nice. But as far as the
>> underlying crypto, it would be unwise for VSI to roll any of that on
>> their own.
>
> Wouldn't suggest home-grown cryptography. That often ends badly. As
> for wrapping, that's what the Apple frameworks provide. Secure
> Transport, the Network Framework, etc., wrap libtls, as well as dealing
> with DNS and sockets and certificates.
>
> https://developer.apple.com/security/
>
> Do I expect VSI to crib Apple here? No. I reference this so that folks
> can see what's been happening in the past decade or two; in the era
> since the OpenVMS frameworks have been substantially updated.
>
> And as I've commented elsewhere, go try writing a secure network
> connection using DNS, and self-signed root certificate authority and
> certificates and CSRs, and sockets. Now work through the failure modes
> and the attacks, and "minor" details such as certificate renewals. Apps
> with errors and vulnerabilities are probably the norm here, too. Now
> make this work with IPv6.
>
> Apple's been rolling all of this right into their networking framework,
> past what Secure Transport provides. As have other folks, I'd expect.
>
>


--

[Stephen Hoffman]

On 2019-04-08 19:26:13 +0000, Dave Froble said:

> On 4/8/2019 1:23 PM, Stephen Hoffman wrote:
>> On 2019-04-07 02:59:52 +0000, Craig A. Berry said:
>>
>>> On 4/6/19 8:58 PM, Stephen Hoffman wrote:
>>>> So we have CSWS, which everybody obviously knows is a web server.
>>>
>>> Not just a web server, but a secure web server from a company named
>>> Compaq that never knew anything about servers or security.
>>
>> CSWS, SWB, the oddly-named-and-why-are-these-even-separate Apache
>> language modules, T4, etc.
>> Terms such as LP and "host-based volume shadowing", for that matter.
>> LMF, PAKs, etc.
>
> Host based mirroring might be a bit more understood, but volume
> shadowing sure isn't all that mysterious.

Once you know to look for it—once you're aware of the jargon—sure.
Host-based RAID-1 would be the typical jargon. And jargon can and does
change over time.

> LMF and PAKs should just go away.

That's up to VSI.

> Usually when a "challenge" is issued, there will be those who pick up
> the gauntlet. I figured at least two methods to get past the LMF. No,
> I'm not saying. It wasn't to actually do so, just to answer the
> challenge.
>
> Thing is, and it's been said before, LMF isn't to stop piracy. If
> someone wants it, they will get it. Just ask Bill Gates about the
> Chinese. So, all LMF does is harrass those who respect it. Get VMS in
> front of as many as possible. Those who will purchase support will do
> so. Those who won't don't. No real loss.

I'm not discussing bypassing LMF. I'm discussing simplifying the
existing license management.

For many products, a licensee name and a checksum is enough. There's a
lot of baggage on OpenVMS left over from the era of each giblet being
separately licensed, not the least of which is the design of LMF itself.

As for changing the licensing and support and pricing scheme? That's
the lifeblood of VSI, and there'll be resistance to anything that might
negatively effect revenues.

And there are in-built sales and marketing assumptions carried over
from the DEC era.

LMF was designed to be able to implement most any scheme that the
pricing folks could conceive. It's bloody brilliant for that, too.
But LMF is an inward-facing design, and not a customer-facing one.

[Dave Froble]

On 4/8/2019 4:30 PM, Stephen Hoffman wrote:
> On 2019-04-08 19:26:13 +0000, Dave Froble said:
>
>> On 4/8/2019 1:23 PM, Stephen Hoffman wrote:
>>> On 2019-04-07 02:59:52 +0000, Craig A. Berry said:
>>>
>>>> On 4/6/19 8:58 PM, Stephen Hoffman wrote:
>>>>> So we have CSWS, which everybody obviously knows is a web server.
>>>>
>>>> Not just a web server, but a secure web server from a company named
>>>> Compaq that never knew anything about servers or security.
>>>
>>> CSWS, SWB, the oddly-named-and-why-are-these-even-separate Apache
>>> language modules, T4, etc.
>>> Terms such as LP and "host-based volume shadowing", for that matter.
>>> LMF, PAKs, etc.
>>
>> Host based mirroring might be a bit more understood, but volume
>> shadowing sure isn't all that mysterious.
>
> Once you know to look for it—once you're aware of the jargon—sure.
> Host-based RAID-1 would be the typical jargon. And jargon can and does
> change over time.

Ayep. That would be a good name.

>> LMF and PAKs should just go away.
>
> That's up to VSI.
>
>> Usually when a "challenge" is issued, there will be those who pick up
>> the gauntlet. I figured at least two methods to get past the LMF.
>> No, I'm not saying. It wasn't to actually do so, just to answer the
>> challenge.
>>
>> Thing is, and it's been said before, LMF isn't to stop piracy. If
>> someone wants it, they will get it. Just ask Bill Gates about the
>> Chinese. So, all LMF does is harrass those who respect it. Get VMS
>> in front of as many as possible. Those who will purchase support will
>> do so. Those who won't don't. No real loss.
>
> I'm not discussing bypassing LMF. I'm discussing simplifying the
> existing license management.
>
> For many products, a licensee name and a checksum is enough. There's a
> lot of baggage on OpenVMS left over from the era of each giblet being
> separately licensed, not the least of which is the design of LMF itself.
>
> As for changing the licensing and support and pricing scheme? That's
> the lifeblood of VSI, and there'll be resistance to anything that might
> negatively effect revenues.
>
> And there are in-built sales and marketing assumptions carried over from
> the DEC era.

Yes, and look at how well that's worked lately.

VSI's future will be based upon support, and to be specific, shpport
from those customers glad to pay for it.

A while back some were bitching about the cost of Rdb. Jan-Erik chipped
in with the statement that the annual support fee was something like
minutes of production. From that perspective, any halt in production
would be VERY expensive. Thus, the willingness, or even gladness, to
pay for support.

The other side of the coin is, get VMS in front of as many eyes as
possible. The worst that can happen is "nothing". Anything else is "to
the good". Never know what some of that might lead to. Even a small
fraction can be profitable.

A VMS "demo disk" should be as simple as one of those Linux disks that
you put in the reader and are immediately running Linux. Or WEENDOZE.
No, there won't be a Solitare game immediately available, but that's not
your target audience. Now, a socket based client and echo server, which
could work with any other system they have, might be a good demo
program. "Yep, VMS will work in your environment".

> LMF was designed to be able to implement most any scheme that the
> pricing folks could conceive. It's bloody brilliant for that, too. But
> LMF is an inward-facing design, and not a customer-facing one.

And it's one more obstacle to the casual observer.

[Neil Rieck]

Unfortunately that was not my experience.

In 2015, we purchased a brand new rx2800-i2 from HP and this meant trading in Alpha licenses (OpenVMS, C, C++, BASIC, FMS) to get new Itanium equivalents. The total purchase (which was not cheap) also provided three years of hardware and software support.

Three years later, our software support agreement with HPE was expiring so I reached out to VSI where I was told that I needed to buy new licenses, then upgrade the OS in order to get a one-year support contract. The new business quote from VSI was three times larger than the software support renewal from HPE.

I recommended going with VSI but middle management (who were making the decisions and would need to sign off on the approvals) absolutely refused. From their perspective, we had just bought new licenses 3-years earlier from HP and didn't give a damn about anything else. In fact, one middle-manager said to me (paraphrased) "that if VSI took over the OpenVMS product line from HP/HPE then they (VSI) should honor the HP licenses"

While I disagreed with him, I could see his point of view.

[Craig A. Berry]

Did you try pricing a three-year support contract? It may be that VSI
does not offer attractive trade-ins without that, or it may be that they
stopped offering such deals shortly after we got ours.

[Dave Froble]

On 4/13/2019 2:10 PM, Neil Rieck wrote:

> Unfortunately that was not my experience.
>
> In 2015, we purchased a brand new rx2800-i2 from HP and this meant trading in Alpha licenses (OpenVMS, C, C++, BASIC, FMS) to get new Itanium equivalents. The total purchase (which was not cheap) also provided three years of hardware and software support.
>
> Three years later, our software support agreement with HPE was expiring so I reached out to VSI where I was told that I needed to buy new licenses, then upgrade the OS in order to get a one-year support contract. The new business quote from VSI was three times larger than the software support renewal from HPE.
>
> I recommended going with VSI but middle management (who were making the decisions and would need to sign off on the approvals) absolutely refused. From their perspective, we had just bought new licenses 3-years earlier from HP and didn't give a damn about anything else. In fact, one middle-manager said to me (paraphrased) "that if VSI took over the OpenVMS product line from HP/HPE then they (VSI) should honor the HP licenses"
>
> While I disagreed with him, I could see his point of view.

I'm going to agree with the manager. It's just plain stupid of VSI to
throw away the support contract. I sure hope their reasoning is not
"they'll be back, where else can they go". Management might just decide
to throw VMS out completely, or, run without support.

Don't know what they are thinking, but, it sure isn't long term ...

Now they get nothing.

[Kerry Main]

Agree.

Just look at Oracle license costs alone. Oracle savings alone often stated as one of the reasons to move Oracle on OpenVMS A64/I64 to Linux on X86-64.

Sample licensing for Oracle for small environment: (5 core server)using list pricing:
OpenVMS - 5 cores x$50,000 x Oracle Processor Core Factor (1 for Alpha, Integrity) = $250,000
Linux - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000

Going fwd with OpenVMS/X86-64:
OpenVMS - - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000
Linux - - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000

Also remember that, similar to RH Linux and Windows, the OpenVMS subscription licensing for VSI remains the same whether the server is on a physical or virtual VM server.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Craig A. Berry]

On 4/27/19 9:09 AM, Kerry Main wrote:

> Just look at Oracle license costs alone. Oracle savings alone often
> stated as one of the reasons to move Oracle on OpenVMS A64/I64 to Linux
> on X86-64.
>
> Sample licensing for Oracle for small environment: (5 core server)using list pricing:
> OpenVMS - 5 cores x$50,000 x Oracle Processor Core Factor (1 for Alpha, Integrity) = $250,000
> Linux - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000
>
> Going fwd with OpenVMS/X86-64:
> OpenVMS - - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000
> Linux - - 5 cores x$50,000 x Oracle Processor Core Factor (0.5 for X86-64) = $125,000

Given that no recent version of Oracle database server runs on VMS,
those are very expensive client licenses. Or if you are assuming that
at some point they will bring Oracle classic up-to-date on VMS and
release it on OpenVMS x64, how do you know they would charge the same
price for it that they charge for the Linux version?

[Jan-Erik Söderholm]

And do we know if/that Rdb would see the same cost savings?

[Arne Vajhøj]

Oracle "Oracle Processor Core Factor Table" is by CPU type.

It has nothing to do with OS.

See:

http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf

It seems very unlikely that Oracle would make an exception for VMS.

Arne

[Arne Vajhøj]

You should ask somebody at Oracle.

But as I read the price list:

https://www.oracle.com/assets/technology-price-list-070617.pdf

then RDB use the same processor calculation as Classic.

Arne

[Craig A. Berry]

Maybe. But if the cost per license to them were higher than on other
OSs that have a larger installed base, then I'm sure they could find a
way to charge more for it if they felt they needed to. It's all
speculative until and unless they decide to port some future version of
the product to some future version of OpenVMS x64. I do genuinely hope
that happens.

As far as processor count, people might well save more by reducing the
number of cores than by the benefits of the core factor. A current
8-core Xeon surely wipes the floor with a 32-core AlphaServer GS1280,
for example. The folks on the oldest hardware would likely benefit the
most, which is a good thing, as they're also likely the ones most in
need of persuading to make a change.

[Kerry Main]

> -----Original Message-----
> From: Info-vax <info-vax...@rbnsn.com> On Behalf Of Craig A. Berry
> via Info-vax
> Sent: April 27, 2019 7:32 PM
> To: info...@rbnsn.com
> Cc: Craig A. Berry <craig...@nospam.mac.com>
> Subject: Re: [Info-vax] OpenSSL CSWS-2.2-1
>
>

Minor nit, but as a fyi, the OpenVMS license model for Integrity servers is based on socket counts not core counts.

Applies to both HPE and VSI.

Hence a IA64 server with 1 socket for all its OpenVMS licensing might be $50K. If that same server has 4 sockets, the licensing pricing jumps to $200K.

This might be reason why Neil's pricing quote awhile back was high.

Lesson learned - if you have an older Integrity server with 4 sockets e.g. I2 (or pre-I2) blade server and using HPE for OpenVMS support, moving to a new Integrity server with VSI and fewer sockets might be wise move. The change in license costs might even pay for the new server. Especially if one considers the new I4/I6 server cores will be much faster so you likely can reduce core counts as well as socket counts and hence really reduce the overall license costs for OpenVMS Integrity.

[doug...@aol.com]

Given the original topic for this thread being "OpenSSL CSWS-2.2-1" and seeing the concerns about keeping up-to-date with OpenSSL and Apache, I thought I'd throw in my $.02 to let you know what VSI is doing.

VSI continues to keep both OpenSSL and Apache up-to-date and is working on advancing support for many open source offering with a team dedicated to that effort.

SSL1 Update R has been released (OpenSSL 1.0.2r).

OpenSSL 1.1.1(b) kits have been developed and will be released soon (TLS V1.3 support). The product name will likely be SSL111 and maintain the same install structure as SSL1 (separate directory trees for co-existence).

CSWS will be released built against SSL111 and include TLS V1.3 support in the near future. Current support level is TLS V1.2.

There is also an LDAP client update (V3) that allows the caller to specify which TLS version to restrict connections to as an alternative to the current handshake negotiations from TLSV1.2 down to as low as SSLV3.

Plans are also in place to follow the OpenSSL V3.0 release when it becomes available. (SSL3?)

Hope this helps.

Doug.

[Craig A. Berry]

On Monday, April 29, 2019 at 10:24:15 AM UTC-5, doug...@aol.com wrote:

> OpenSSL 1.1.1(b) kits have been developed and will be released soon
>(TLS V1.3 support). The product name will likely be SSL111 and maintain
> the same install structure as SSL1 (separate directory trees for co-existence).

SSL11 would make more sense than SSL111 in that it preserves those parts (and only those parts) of the version number indicating a binary compatible release. There may never be a 1.1.2, but if there is, it will be binary compatible with 1.1.1, so no need for a new product name.

While it will probably throw a wrench into human-readable version comparisons for those versions that already exist, v3.x.x might be a good time to deal with the fact that in a few years there will likely be an OpenSSL 10.x.x. A product name like SSL0300 for a release based on OpenSSL 3.0.x would have an obvious relationship to a product called SSL1013 and based on OpenSSL 10.13.x.

[Simon Clubley]

On 2019-04-29, Craig A. Berry <craig....@gmail.com> wrote:
>
> While it will probably throw a wrench into human-readable version
> comparisons for those versions that already exist, v3.x.x might be a good
> time to deal with the fact that in a few years there will likely be an
> OpenSSL 10.x.x. A product name like SSL0300 for a release based on OpenSSL
> 3.0.x would have an obvious relationship to a product called SSL1013 and
> based on OpenSSL 10.13.x.
>

I agree.

In fact, all VMS kits based around open source products should just use
the open source product version number as part of the kit name instead
of making up a version number that is VMS specific.

Having VMS specific version numbers for open source products is just
yet another source of confusion that simply does not need to exist.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Craig A. Berry]

On Monday, April 29, 2019 at 12:30:05 PM UTC-5, Simon Clubley wrote:
> On 2019-04-29, Craig A. Berry <craig....@gmail.com> wrote:
> >
> > While it will probably throw a wrench into human-readable version
> > comparisons for those versions that already exist, v3.x.x might be a good
> > time to deal with the fact that in a few years there will likely be an
> > OpenSSL 10.x.x. A product name like SSL0300 for a release based on OpenSSL
> > 3.0.x would have an obvious relationship to a product called SSL1013 and
> > based on OpenSSL 10.13.x.
> >
>
> I agree.
>
> In fact, all VMS kits based around open source products should just use
> the open source product version number as part of the kit name instead
> of making up a version number that is VMS specific.
>
> Having VMS specific version numbers for open source products is just
> yet another source of confusion that simply does not need to exist.

I agree, but I'm actually talking about product names not version numbers. If you want to simultaneously support two different versions that are not binary compatible with each other, you need different product names and they need to appear not just in the kit names but also in the filenames of whatever libraries end up in sys$share or sys$library, not to mention system-level logical names.

[Arne Vajhøj]

On 4/29/2019 2:30 PM, Craig A. Berry wrote:
> On Monday, April 29, 2019 at 12:30:05 PM UTC-5, Simon Clubley wrote:
>> On 2019-04-29, Craig A. Berry <craig....@gmail.com> wrote:
>>> While it will probably throw a wrench into human-readable version
>>> comparisons for those versions that already exist, v3.x.x might be a good
>>> time to deal with the fact that in a few years there will likely be an
>>> OpenSSL 10.x.x. A product name like SSL0300 for a release based on OpenSSL
>>> 3.0.x would have an obvious relationship to a product called SSL1013 and
>>> based on OpenSSL 10.13.x.

>> In fact, all VMS kits based around open source products should just use
>> the open source product version number as part of the kit name instead
>> of making up a version number that is VMS specific.
>>
>> Having VMS specific version numbers for open source products is just
>> yet another source of confusion that simply does not need to exist.

> I agree, but I'm actually talking about product names not version
> numbers. If you want to simultaneously support two different versions
> that are not binary compatible with each other, you need different
> product names and they need to appear not just in the kit names but also
> in the filenames of whatever libraries end up in sys$share or
> sys$library, not to mention system-level logical names.

This is only a problem if products insist on dumping their stuff
into the operating systems structure.

Very common across operating systems.

But still a bad idea in my opinion.

Arne

[Craig A. Berry]

It certainly has its problems, but without a common, canonical location,
configure scripts would not know where to find the library to link
against it. Of course they then have to examine the headers and see
what version they've got and whether it's compatible with the package
being built.

Having to handle multiple, incompatible versions of the same package is
kind of a mess any way you slice it. Here's something I recently
encountered on a RHEL system:

$ which java
/usr/bin/java
$ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 Apr 22 15:20 /usr/bin/java ->
/etc/alternatives/java
$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 73 Apr 22 15:20 /etc/alternatives/java ->
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.212.b04-0.el7_6.x86_64/jre/bin/java

So there's double indirection via two symlinks from the canonical
location of the java binary to the actual location. This system only
has one version of java installed, but if there were more than one, I
could use the "alternatives" program to fiddle with the intermediate
symlink and enable a different version. Except the installation
processing of a lot of things that depend on Java follows the symlinks
and hard-codes the actual java binary locations in the start-up scripts,
which tends to break something even when you just do a minor update.

Compared to that, choosing between running SYS$STARTUP:SSL$STARTUP or
SYS$STARTUP:SSL1$STARTUP and then following the OPENSSL logical name
doesn't seem especially worse than what everyone else does.

[Stephen Hoffman]

OpenVMS itself encourages the scatter-shot installation misbehavior,
requiring logical names if the message file and shareable images and
whatnot are to be isolated from a bespoke bundle. Wouldn't surprise
me to see VSI start to take a few swings at this and related problems,
at least for themselves and their layered products, and sometime after
the port is available.

As for OpenSSL, one of the few precedents for installing parallel
versions—and one of the few that works—is multi-version Rdb. There's
little (no?) documentation on what's involved with that too, and it's
easy to get it wrong.

And as for OpenSSL, the API changes are almost certainly going to
continue, which means we re-code and update our apps for those and/or
migrate to a VSI or third-party API. Or we embed the required versions
in the app directory, which is probably where we're headed. Downside
of embedding OpenSSL or other dependencies: chasing individual app
updates because of vulnerabilities in the OpenSSL or other
dependencies. Which means that easier and more automated and faster
patch notification and update notification and patch and update
application paths are necessary.

For those folks that haven't seen what can be available for maintaining
and updating apps: https://sparkle-project.org

We ain't headed back to the era of small disks or infrequent updates or
limited vulnerabilities. We have what we have. And we have the trends
we have. And the treadmill we're all on around patches and upgrades is
only going to accelerate.

ps: "There are only two hard things in Computer Science: cache
invalidation, naming things, and off-by-one errors."

[Jan-Erik Söderholm]

Den 2019-04-30 kl. 17:50, skrev Stephen Hoffman:

>
> As for OpenSSL, one of the few precedents for installing parallel
> versions—and one of the few that works—is multi-version Rdb.  There's
> little (no?) documentation on what's involved with that too, and it's easy
> to get it wrong.
>

A slightly unnecessary and mostly wrong comment.

The Install and Config Guide:

http://download.oracle.com/otndocs/products/rdb/pdf/rdb073_install_guide.pdf

has these chapters:

2.3 Overview of Multiple−Version Support in Oracle Rdb
2.4 Accessing Multiple Versions of Oracle Rdb
2.5 How Applications Access Multiple Versions of Oracle Rdb
3.14 Deleting Versions of Oracle Rdb

I have used only Rdb multiversion kits since they was introduced,
I think it was 4.1 or 4.2, and the "standard" (non-multi-version)
kit was removed from 7.1, and I have never had any issues.

One single line in the script where you start Rdb at boot and
that is the default for the whole system after that.

$ @SYS$LIBRARY:RDB$SETVER 7.3 /SYSTEM

And one line in your system wide SYLOGIN.COM (does not have to be
changed if you still want all users to use the system default):

$ @SYS$LIBRARY:RDB$SETVER RESET

For specific needs you can easily establish the right environment.

You can get *anything* wrong, but *this* is not hard to get right.

[Stephen Hoffman]

On 2019-04-30 20:20:21 +0000, Jan-Erik S derholm said:

> Den 2019-04-30 kl. 17:50, skrev Stephen Hoffman:
>
>>
>> As for OpenSSL, one of the few precedents for installing parallel
>> versions—and one of the few that works—is multi-version Rdb.  There's
>> little (no?) documentation on what's involved with that too, and it's
>> easy to get it wrong.
>>
> A slightly unnecessary and mostly wrong comment.

I referenced multi-version Rdb as an example of an installer that
allows multiple versions.

Rdb is certainly an example of an installer that permits parallel
installations.

Rdb does arrive with documentation of how to install Rdb, too.

Rdb does not arrive with documentation around how to *construct* a
multi-version installation kit, whether Rdb or otherwise.

You have pointed to some documentation for a kit that I had
acknowledged as a multi-version kit, and a design that works pretty
well.

However, you did not reference design and implementation documentation
for a multi-version kit, whether PCSI or VMSINSTAL or otherwise.

Distinct from Rdb, there's ample evidence that there have been folks
creating kits have tried and have encountered issues with their
designs, too.

Yes, in the absence of design and implementation documentation, having
some familiarity with an example is valuable.

There's a hole here in the OpenVMS kitting documentation.

There's are related holes in the OpenVMS application design
documentation around supporting upgrades in our apps, supporting
cluster rolling upgrades in our apps, and better supporting app
availability.

[Arne Vajhøj]

On 4/29/2019 11:01 PM, Craig A. Berry wrote:
> On 4/29/19 8:53 PM, Arne Vajhøj wrote:
>> On 4/29/2019 2:30 PM, Craig A. Berry wrote:
>>> I agree, but I'm actually talking about product names not version
>>> numbers. If you want to simultaneously support two different versions
>>> that are not binary compatible with each other, you need different
>>> product names and they need to appear not just in the kit names but also
>>> in the filenames of whatever libraries end up in sys$share or
>>> sys$library, not to mention system-level logical names.
>>
>> This is only a problem if products insist on dumping their stuff
>> into the operating systems structure.
>>
>> Very common across operating systems.
>>
>> But still a bad idea in my opinion.
>
> It certainly has its problems, but without a common, canonical location,
> configure scripts would not know where to find the library to link
> against it.

I would suggest the developer decide what library to link against.

> Having to handle multiple, incompatible versions of the same package is
> kind of a mess any way you slice it.  Here's something I recently
> encountered on a RHEL system:
>
> $ which java
> /usr/bin/java
> $ ls -l /usr/bin/java
> lrwxrwxrwx 1 root root 22 Apr 22 15:20 /usr/bin/java ->
> /etc/alternatives/java
> $ ls -l /etc/alternatives/java
> lrwxrwxrwx 1 root root 73 Apr 22 15:20 /etc/alternatives/java ->
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.212.b04-0.el7_6.x86_64/jre/bin/java
>
> So there's double indirection via two symlinks from the canonical
> location of the java binary to the actual location.  This system only
> has one version of java installed, but if there were more than one, I
> could use the "alternatives" program to fiddle with the intermediate
> symlink and enable a different version.  Except the installation
> processing of a lot of things that depend on Java follows the symlinks
> and hard-codes the actual java binary locations in the start-up scripts,
> which tends to break something even when you just do a minor update.

That is also fucked up.

/allmyjavaversions/jdk1.8.0_182/bin/java
/allmyjavaversions/jdk-11.0.2/bin/java
etc.

works fine.

And again I want the sysadm to decide what Java version to use.

> Compared to that, choosing between running SYS$STARTUP:SSL$STARTUP or
> SYS$STARTUP:SSL1$STARTUP and then following the OPENSSL logical name
> doesn't seem especially worse than what everyone else does.

True.

The situation is approx. the same across VMS, Linux and Windows.

Arne

[Stephen Hoffman]

On 2019-04-30 23:27:31 +0000, Arne Vajh j said:

> The situation is approx. the same across VMS, Linux and Windows.

https://nixos.org/nix/ — "You can have multiple versions or variants
of a package installed at the same time. This is especially important
when different applications have dependencies on different versions of
the same package — it prevents the “DLL hell”. Because of the hashing
scheme, different versions of a package end up in different paths in
the Nix store, so they don’t interfere with each other." Etc.

[Jan-Erik Söderholm]

Den 2019-05-01 kl. 01:06, skrev Stephen Hoffman:
> On 2019-04-30 20:20:21 +0000, Jan-Erik S derholm said:
>
>> Den 2019-04-30 kl. 17:50, skrev Stephen Hoffman:
>>
>>>
>>> As for OpenSSL, one of the few precedents for installing parallel
>>> versions—and one of the few that works—is multi-version Rdb.  There's
>>> little (no?) documentation on what's involved with that too, and it's
>>> easy to get it wrong.
>>>
>> A slightly unnecessary and mostly wrong comment.
>
> I referenced multi-version Rdb as an example of an installer that allows
> multiple versions.
>
> Rdb is certainly an example of an installer that permits parallel
> installations.
>
> Rdb does arrive with documentation of how to install Rdb, too.
>
> Rdb does not arrive with documentation around how to *construct* a
> multi-version installation kit, whether Rdb or otherwise.

> .......


OK. I read your post as there was something missing in the Rdb docs
on how to configure and use the Rdb MV kits. Rdb MV works just fine,
as you also noted. Fine then. Maybe someone else also misread your
post and got that right...

[Arne Vajhøj]

There are typical plenty of technical solutions for the problem.

But they are not commonly used.

Arne

[Neil Rieck]

Just thought I'd toss in my own 2-cents on the OpenSSL issue as well.

I've been playing with WASD HTTPd v11.3 as a drop in replacement for CSWS-2.2-1

First off, WASD is a hackers delight because it is published with all the source code. If you have a DEC-C compiler then you will be able to support yourself if need be.

Secondly, during the install (you are given the choice of "just linking" or "compile then link") you will be prompted for five OpenSSL options depending upon what you've already got installed on your system. For example WASD can link against its own SSL library, or HP-SSL1 (OpenSSL 1.0 and higher) or HP-SSL (OpenSSL 0.9 and lower) although this last step is disabled by default when HP-SSL1 is present. How cool is that!

Last but not least, WASD HTTPd is the fastest web server in my shop. Although I'm running WASD on an old rx2600 (8 CPUs, 16 GB of RAM), it is faster than CSWS-2.2-1 on my rx2800-i2 (8 CPUs, 64 GB of RAM) as well as Apache 2.4 under CentOS-7 on my DL385p-gen8 (24 CPUs, 132 GB of RAM).

Now I haven't (yet) done full-load testing of WASD, but it appears get its speed from doing a lot of caching to avoid disk i/o -AND- does not be using the pre-fork model seen in CSWS on OpenVMS-8.4 or Apache 2.4 on CentOS-7

Comment: I've done at least a half-dozen installs of CentOS which included Apache by default. I do not recall ever being asked to choose between pre-fork or something else. And yet, all the Apache self-help sites tell you not to use pre-fork. Go figure!

Neil Rieck
Waterloo, Ontario, Canada.

http://neilrieck.net/docs/openvms_notes_wasd.html

[Jan-Erik Söderholm]

Den 2019-05-02 kl. 13:15, skrev Neil Rieck:
> Just thought I'd toss in my own 2-cents on the OpenSSL issue as well.
>
> I've been playing with WASD HTTPd v11.3 as a drop in replacement for
> CSWS-2.2-1
>
> First off, WASD is a hackers delight because it is published with all
> the source code. If you have a DEC-C compiler then you will be able to
> support yourself if need be.
>
> Secondly, during the install (you are given the choice of "just linking"
> or "compile then link") you will be prompted for five OpenSSL options
> depending upon what you've already got installed on your system. For
> example WASD can link against its own SSL library,

Based on OpenSL 1.1.1 and last release/update was 15-Mar-2019.
There is also a OpenSSL 1.0.2r on the WASD page...

> or HP-SSL1 (OpenSSL 1.0 and higher)

Seems to be HPE SSL1 1.0-2G based on OpenSSL 1.0.2g (?).

> or HP-SSL (OpenSSL 0.9 and lower) although this last
> step is disabled by default when HP-SSL1 is present. How cool is that!
>
> Last but not least, WASD HTTPd is the fastest web server in my shop.

Not only fast, it is rock-solid. After install and config (apart from later
configs for new function) it just starts at boot and runs to shutdown.

[Stephen Hoffman]

Local operating assumption: Install-time questions are to be avoided.
Install-time questions usually means the developer either couldn't
answer a question and couldn't figure out how to eliminate the
question, or didn't want to answer a question and didn't want to
consider why. Or wanted to ask questions to show off. Among the
various things that PCSI—the most recent OpenVMS platform package
installer—did right here, it made asking questions of the installer
more difficult. If there are questions that cannot be answered at
install time, provide a configuration tool. And gather what data you
can from the local environment and local network services, whether it's
from mDNS or DHCP or NTP or otherwise. Yeah, OpenVMS isn't good at any
of that. And it'd be very handy if there were standardized profiles
and configuration files and tools available here, so that the
installation deployment and configuration process can be automated,
when there are questions or customizations required. With OpenVMS, we
all either end up writing that ourselves, and often differently. Or
making automated and faster deployments more difficult.

On 2019-05-02 11:15:44 +0000, Neil Rieck said:

> Just thought I'd toss in my own 2-cents on the OpenSSL issue as well.
> I've been playing with WASD HTTPd v11.3 as a drop in replacement for CSWS-2.2-1
>
> First off, WASD is a hackers delight because it is published with all
> the source code. If you have a DEC-C compiler then you will be able to
> support yourself if need be.

Apache source code is also available, and both HPE and VSI have made
source code of the ports available. Downside: OpenVMS C hasn't tracked
that of other platforms, so the ports tend to be more complex. VSI is
on a path to fix that, starting with Clang and LLVM support. There's
rather more past that, and hopefully the existing OpenVMS C RTL is
eventually relegated to use by unmaintained applications. There are
far too many layers of backward-compatibility clogging the existing
environment.

> Secondly, during the install (you are given the choice of "just
> linking" or "compile then link") you will be prompted for five OpenSSL
> options depending upon what you've already got installed on your
> system. For example WASD can link against its own SSL library, or
> HP-SSL1 (OpenSSL 1.0 and higher) or HP-SSL (OpenSSL 0.9 and lower)
> although this last step is disabled by default when HP-SSL1 is present.
> How cool is that!

How about installs with no questions at all? That's cool. That's the
best. For this case, probably with an embedded OpenSSL or libtls or
libsodium kit, though this presumes there'll be upgrades to that
support and thus some provisions are necessary for upgrades.

Now if somebody wants (needs) linkages against some other crypto
library, allow that after the install, and instrument that to see how
many folks use it as a foundation for adding or removing encryption
support, or for removing the feature entirely.

And I'm skeptical around needing changes here, if the crypto libraries
are kept current.

https://www.libressl.org
https://github.com/jedisct1/libsodium
etc.

Biggest reason to provide that variant support on OpenVMS has been a
bad trade-off between longstanding issues with old vendor SSL
libraries, and the time and effort involved in maintaining app-specific
libraries. OpenVMS is unfortunately missing a number of common
libraries, and the pace of change here makes keeping the dependencies
current more effort, whether that cost is at the vendor or at the
developer. And the crypto has been lagging, both with the OpenSSL
library and with the embedded SSL within various versions of Apache.

> Last but not least, WASD HTTPd is the fastest web server in my shop.
> Although I'm running WASD on an old rx2600 (8 CPUs, 16 GB of RAM), it
> is faster than CSWS-2.2-1 on my rx2800-i2 (8 CPUs, 64 GB of RAM) as
> well as Apache 2.4 under CentOS-7 on my DL385p-gen8 (24 CPUs, 132 GB of
> RAM).
>
> Now I haven't (yet) done full-load testing of WASD, but it appears get
> its speed from doing a lot of caching to avoid disk i/o -AND- does not
> be using the pre-fork model seen in CSWS on OpenVMS-8.4 or Apache 2.4
> on CentOS-7

It'd be interesting to try that against a tuned Apache HTTP Server
2.4-39 on VSI OpenVMS. Also against nginx on CentOS, if running a
comparison. Apache has never been particularly fast. It is, however,
extremely common.

> Comment: I've done at least a half-dozen installs of CentOS which
> included Apache by default. I do not recall ever being asked to choose
> between pre-fork or something else. And yet, all the Apache self-help
> sites tell you not to use pre-fork. Go figure!

The worker MPM is necessary when some part of your Apache module
environment isn't thread-safe, and prefork MPM is the choice when your
Apache module environment is thread-safe. If the default Apache
install is thread-safe, then there's no reason to ask a question.

[supers...@gmail.com]

On Saturday, April 6, 2019 at 8:32:58 AM UTC-4, Neil Rieck wrote:
> Strictly as an emergency backup plan, I've been working on trial to replace CSWS-2.2-1 with WASD-11.
>
> For example, if my ~1,200 clients begin to use new browsers next year, they might not be able to connect to my current system so I have got to do something now. But that got me thinking about another problem: we are receiving B2B SOAP transactions from a system in Montreal (another company) which currently relies on SSLv3. If I upgrade my web-server to something that doesn't offer SSLv3 (because it hasn't been compiled into Apache's mod_ssl, or I've linked WASD to an SSL library that is too restrictive) then I'm not going to be able to receive those B2B SOAP connections.
>
> After a restless night of sleep it occurred to me that many other systems are also going to run into this situation but no one seems to be talking about it (at least not in the way they talked about Y2K). So I have decided to call this problem "Y2K20" and have placed some preliminary notes here:
>
> http://neilrieck.net/docs/calendar_time_y2k_etc.html#y2k20

>
> Neil Rieck
> Waterloo, Ontario, Canada.
> http://neilrieck.net

BRING BACK PURVEYOR :)

[supers...@gmail.com]

On Sunday, April 7, 2019 at 8:17:36 PM UTC-4, Bill Gunshannon wrote:

>
> Even in this race is a loser.
> Example: There are 100 companies running HPE VMS.
> 50 move to VSI VMS.
> 50 move to Linux or Windows.
>
> Even, right?
>

WRONG! IF THEY LOOK AT THE CERT COUNTS FROM THE LAST 20 YEARS
OPENVMS 19 LINUX 2205 I BET IT WILL BE 100 TO VMS 0 TO LINUX.

[Simon Clubley]

Comparing CVE counts for different operating systems means absolutely
nothing unless (at an absolute minimum):

1) There are a comparable number of security researchers looking at each
operating system being compared as well as spending the same amount
of effort looking for flaws in each operating system and

2) There is a comparable range of software installed on all the
operating systems being compared.

Neither of these are true when comparing Linux to VMS.

BTW Bob, the ASR 33 is no longer the standard input device in use
these days and it is ok to include lower case in your replies.

[Arne Vajhøj]

Like nobody has moved from VMS to Unix/Linux/Windows the last 20 years ...

:-)

You need to view the world as the world actually is and not how you wish
it were.

Arne

[Kerry Main]

> -----Original Message-----
> From: Info-vax <info-vax...@rbnsn.com> On Behalf Of Stephen
> Hoffman via Info-vax
> Sent: April 8, 2019 11:26 AM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] OpenSSL CSWS-2.2-1
>

> On 2019-04-07 14:06:20 +0000, Neil Rieck said:
>
> > The current version of CSWS for OpenVMS from HPE is based upon Apache
> > 2.0.63
>
> HPE is exiting the OpenVMS business, with new-patch support ending in less
> than two years. I'd expect the HPE investments to taper over time, too.
>
> > The current version of CSWS for OpenVMS from VSI is based upon Apache
> > 2.4.12 according to this link.
>
> For not the first time I have stated this in this thread, the current VSI
CSWS
> Apache Web Server version is V2.4-38. If what is posted on the VSI web
site
> doesn't indicate that, what is posted is stale.
>
> > We attempted to move support from HPE to VSI last year but our
> > management would not approve the purchase of software relicensing by
> > VSI. If they had then I would not find myself in this dilemma; which
> > is why I'm experimenting with WASD.
>
> Then keep records, and expect to toss the whole discussion back at your
> management, as part of transitioning from HPE support to VSI support;
> positioned as a one-time on-boarding fee or transition fee or whatever.
> It'd be nice if the licensing could be buried in the support costs, but
that's not
> currently the case. The current VSI web site and the VSI communications
and
> the lack of a list price price list aren't particularly helpful here,
either.
>

[snip..]

Also, remember to look at sockets on your Integrity servers to be
transitioned to VSI. Current Integrity OpenVMS licensing from both HPE and
VSI is based on the base OpenVMS prod license cost x # of sockets in that
server. I believe this change was implemented in OpenVMS V8.4 timeframe
(before this, it was core based pricing).

If you are using older pre-I2 or I2 servers with 4 sockets and total of 8
cores, then it might be worth buying a newer I4 or I6 server with 1 socket
(with fewer cores, keeping in mind much better core perf on I4/I6's)

Example - if an Integrity server total OpenVMS licenses costs $50K on a
single socket I4/I6 server, the same OpenVMS licensing will cost $200K on an
older 4 socket I2 server.

[Craig A. Berry]

On 4/29/19 11:06 AM, Craig A. Berry wrote:
> On Monday, April 29, 2019 at 10:24:15 AM UTC-5, doug...@aol.com wrote:
>
>> OpenSSL 1.1.1(b) kits have been developed and will be released soon
>> (TLS V1.3 support). The product name will likely be SSL111 and maintain
>> the same install structure as SSL1 (separate directory trees for co-existence).
>
> SSL11 would make more sense than SSL111 in that it preserves those
> parts (and only those parts) of the version number indicating a
> binary compatible release. There may never be a 1.1.2, but if there
> is, it will be binary compatible with 1.1.1, so no need for a new
> product name.

Oh well, I tried. They just released it and the product name is indeed
SSL111. So eventually we'll be going cross-eyed over things like
version V1.1-2C of a product named SSL111.

> While it will probably throw a wrench into human-readable version
> comparisons for those versions that already exist, v3.x.x might be a
> good time to deal with the fact that in a few years there will likely
> be an OpenSSL 10.x.x. A product name like SSL0300 for a release
> based on OpenSSL 3.0.x would have an obvious relationship to a
> product called SSL1013 and based on OpenSSL 10.13.x.

I'm revising this advice slightly (not that it's any more likely to be
followed than my advice above) based on the fact that beginning with
OpenSSL 3.0.0, all versions sharing a major version number will be
binary compatible. So a product name of SSL03 would be sufficient for
everything in the 3.x.x series.

[seasoned_geek]

On Thursday, March 14, 2019 at 3:38:14 PM UTC-5, Dave Froble wrote:
>
> So what are you going to use? Specifically for the desktop?
>
> I also do not like using WEENDOZE 7, and refuse to boot up 10.
>

10 is not as bad as it once was, but I only use it when forced to at a client site. The bulk of my personal machines run either KDE Neon

https://neon.kde.org/

or Ubuntu 18.04 LTS.

Of all the distros I have used KDE Neon currently seems to be the best.

Linux Mint used to be a very good desktop.
https://linuxmint.com/

They had serious distro specific problems with NVidia drivers some years back so anyone running BOINC left them.

Of course you could just stick with IE

/ducks and runs

[johnwa...@yahoo.co.uk]

Hmmm. Never been a particular fan of Ubuntu myself, especially
in recent years, but it does seem to have mindshare sometimes,
and a share of press coverage in mainstream-ish media that to
me seems to be more related to Canonical's media-friendly skills
rather than anything directly related to what Canonical/Ubuntu
has brought to the table in recent years (even taking things like
Mint into account).

I do still like KDE etc for various reasons.

Where does KDE Neon fit in? Have a look at
https://neon.kde.org/faq
for a better answer than I can offer here at the moment.

Another well kept secret is that official variants of SUSE
(both Enterprise Server and OpenSuse flavours) are and have
been available through the Windows 10 App Store for maybe
a couple of years. It's not just for Ubuntu :)

Might be of interest to some folk (but not to me, as the
Windows Store is not currently in my IT strategy).

[Stephen Hoffman]

On 2019-05-30 18:47:12 +0000, Craig A. Berry said:

> Oh well, I tried. They just released it and the product name is

> indeedSSL111. So eventually we'll be going cross-eyed over things like

> version V1.1-2C of a product named SSL111.

...

> I'm revising this advice slightly (not that it's any more likely to be
> followed than my advice above) based on the fact that beginning with
> OpenSSL 3.0.0, all versions sharing a major version number will be
> binary compatible. So a product name of SSL03 would be sufficient for
> everything in the 3.x.x series.

Multiple parallel kits works better when the goal is to minimal changes
with some possibility of coexistence and incremental migration. This
is what I've previously suggested, too.

But I've rethought what I was suggesting here a while back, too. Ship
a TLS patch kit with all of the latest of the currently-supported TLS
versions—the two or three or whatever that are actively seeing OpenSSL
patches—and that removes the unsupported versions, and whatever
TLS-related changes are needed in the OpenVMS-specific TLS framework
that abstracts the changes in the OpenSSL APIs.

This as part of integrating IP networking and security, integrate
certificates, replacing and deprecating CDSA, etc. And part of keeping
that security current, particularly since OpenVMS claims to be "the
most secure operating system on the planet".

An omnibus kit that also deprecates and eventually removes the
unsupported OpenSSL releases will cause some grief for some app
developers and some sites. The TLS API provides a path for some of
those to migrate, and better handling around encryption, and around
writing a network server without having to deal (as much) with IPv4 and
IPv6 and certificates and DNS and the rest. The rest of the folks want
or need to be insecure and down-revision and for whatever reason, and
can find and integrate their own OpenSSL kits.

Down-revision and backward-compatibility? I really don't care why
those of y'all want or need to run down-revision and variously fossil
software, y'all have your reasons. I've heard most of those reasons
too, and you're probably not special. Whether you've accepted or
ignored or mitigated the associated risks, your down-revision needs
should not degrade the security of the rest of the folks and of those
developers that are keeping apps current. There's no transparent
upgrade path here short of the addition of a TLS API, and there'll be
folks that can't or won't upgrade to and migrate to that, and for
whatever reason. We're on a treadmill of upgrades, whether any of us
wants to be. But I digress.

This all assumes there's to be more of an investment in security and of
keeping SSL current, and around adding (better) support for calls from
the descriptor-oriented programming languages. Otherwise, we get what
we have: parallel OpenSSL kits for three and potentially more releases.
In a yet better world, OpenVMS logs first-use and then periodic
(monthly?) message about apps using deprecated and insecure APIs, too.
There are a number of folks that just don't know or don't realize
they're using insecure constructs.

But....

If the associated investment around security is to continue to be
delegated to the apps and the ISVs as is currently the case, then
parallel kits. Craig's proposed naming seems reasonable for that.
Though this current approach is going to be yet another round of
permutations and complexity; of kicking the costs to the system
administration ("manager") and to the ISVs and developers.

[Dave Froble]

First, I agree that the latest TLS/SSL should be provided.

I also feel that the interface to the product should be somehow
compatable rather than needing re-coding to use the newer stuff. Not
sure how easy that might be.

But, I'm going to ask, why remove older capabilities? Sure, it would be
best to not use them. But there will be some users that do not have a
choice, if they want to continue communicating with existing trading
partners. So, whynot some type of configuration tool that can set flags
as to which protocols should be allowed? Default it to TLS3, but allow
when necessary for older protocols to be allowed.

It's an imperfect world, but it's the one we must live in.

I could also mention that needed support, or lack thereof, would play
some part in selection or rejection of VMS for new users.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[doug...@aol.com]

"I also feel that the interface to the product should be somehow
compatable rather than needing re-coding to use the newer stuff. Not
sure how easy that might be. "

Easier said than done. Making internal structures opaque that were once directly visible and modifiable precludes forward compatibility.

Silo'd coexisting releases at least allow customers to continue to run their current applications until such time as they can, if ever, update their source code.

"So, whynot some type of configuration tool that can set flags
as to which protocols should be allowed? Default it to TLS3, but allow
when necessary for older protocols to be allowed."

The handshake does this now by connecting to the strongest protocol enabled by both sides. Applications can set options to limit which protocols are available during the handshake. For instance, you can restrict protocols to SSL3 and TLS1.3 and ignore the three TLS versions in between.

[Stephen Hoffman]

On 2019-06-03 23:21:18 +0000, Dave Froble said:

> First, I agree that the latest TLS/SSL should be provided.
>
> I also feel that the interface to the product should be somehow
> compatable rather than needing re-coding to use the newer stuff. Not
> sure how easy that might be.

This goes well past TLS, too. There's a whole pile of drudge work here,
and developers are increasingly being provided with frameworks for
these tasks.

For not the first time, yes, it is possible to do all of this in
bespoke app code—and variously either incompletely, or with errors—but
that's not where we're headed.

> But, I'm going to ask, why remove older capabilities? Sure, it would
> be best to not use them. But there will be some users that do not have
> a choice, if they want to continue communicating with existing trading
> partners. So, whynot some type of configuration tool that can set
> flags as to which protocols should be allowed? Default it to TLS3, but
> allow when necessary for older protocols to be allowed.

For various of these cases both involving OpenSSL and those beyond
OpenSSL, and in no particular order...

... all code has support costs, whether that code is used or supported
or not. Building, packaging, storage, kitting, installations, testing,
etc.
... unsupported code still has bugs. Unsupported security code has known bugs.
... folks that are not maintaining and are not updating their code are
the wrong end of the market. The folks that are not integrating with
and not networking with other systems is getting ever smaller.
... old and unsupported code can have API problems and constraints and
incompatibilities, and can constrain updates.
... more than a few OpenVMS sites have no idea what's secure and what's
not, and look to the folks maintaining "the most secure operating
system on the planet" for guidance and suggestions.
... economics. VSI can't do everything for everybody. Where there are
problems, start by creating and then migrating folks to better APIs.
Deprecate and eventually remove the worst and most problematic.

For this particular case, folks using old releases and old features can
lock in and hope it'll all keep working and as many (most?) do, or they
can fix and maintain their code if they want or need current versions
and support and they can then install a free OpenSSL kit and maintain
it themselves, or possibly use an add-on and extra-cost OpenSSL kit.

Why deprecate and eventually remove? Various reasons around the older
OpenSSL TLS bits: the older approaches are insecure. They're
fundamentally broken. More than a few users don't know this or don't
recognize this, and it's incumbent on VSI to guide OpenVMS developers
and end-users forward as part of the VSI "the most secure operating
system on the planet" marketing efforts. Preserving the older
approaches and older APIs variously also limit the range and scope of
enhancements and upgrades possible.

I really like compatibility. In theory. But that compatibility can be
far more costly and far more constraining than many realize. And it's
just not possible to fit sixteen or thirty-two bytes into an eight byte
buffer. I'd prefer the development focus on newer bits and newer
updates than on preserving APIs and designs for code that isn't being
maintained.

In practice, complete upward-compatibility is increasingly incompatible
with the future sales and future usefulness of a product, and
incompatible with the level of development effort that can be expended
and where and what, and with what the folks that are keeping current
and are maintaining their products need and want. Some old APIs have
to be retired and removed, preferably with migration paths and/or with
better replacements available.

I'd hope that VSI would prefer to steer user expectations away from
some of the more problematic DEC ideas. VSI and OpenVMS users can
either have a focus on better APIs and features and retiring what's
known problematic, or a focus on existing and old apps and on
increasingly convoluted APIs and increasingly hostile designs and
absurd defaults. DEC focused on the latter—on compatibility—at the
expense of the former—on usability, clear APIs, good defaults, current
tooling, etc. Based on what I've seen if it, the latter approach is
also a long-term declining market, too.

There's no right answer here, and there are always trade-offs. If
y'all have a can't-ever-upgrade-something or
can't-ever-change-something installation, have at. Again, I've heard
just about every reason for that too, and I really don't care what
constraints or evaluations or other requirements you've gotten tangled
with. Figure out how to do that. Go do it. Whatever. But please
don't expect the rest of us using OpenVMS to want to cater to your
requirements, nor to want our maintenance and our new work and our new
apps and our development costs to be more expensive so that your
existing and old installations can make fewer or no changes. Or the
new apps and new deployments increasingly go elsewhere, and the whole
dealing-with-upgrade problems become moot.

[Dave Froble]

You're missing the point. If a significant part of some companies
business is with a trading partner who will not upgrade their SSL
capabilities, and you have no way to get them to change, then, you do
what you have to do to stay in business.

Most of your arguments are good, but, when the alternatives are "stay in
business" or "go out of business", the choice is easy, at least for me.

[Phillip Helbig (undress to reply)]

In article <qd7kb1$95k$1...@dont-email.me>, Dave Froble

<da...@tsoft-inc.com> writes:

> You're missing the point. If a significant part of some companies
> business is with a trading partner who will not upgrade their SSL
> capabilities, and you have no way to get them to change, then, you do
> what you have to do to stay in business.

Indeed. While I understand the purpose of both encryption and
authentication, many SSL implementations will refuse to connect if the
offered ciphers are deemed to be insecure, rather than having an option
(more common in web browsers) saying: "there is a problem, but if you
know what you are doing, you can continue". Without that option, SSL is
a non-starter if the other side is "too old", which is why some people
still run telnet. Even if the cypher is not up to date, it is still
better than no encryption, and at least there is authentication.

[Bill Gunshannon]

Having considerable experience with the subject at hand, I can
assure you that if the cypher is not up to date it is not better
than no encryption. It is the same as no encryption. The days
if security by obscurity should be long gone by this point.

bill

[Simon Clubley]

SSL has nothing to do with interactive command line communications;
you are thinking of SSH.

As for SSL, people go for more secure options because those are now
the required industry standards. That's why TLS 1.2 is now so commonly
required (for example) and why you may not be allowed to fall back to
TLS 1.0 (for example) to talk to that service/website.

Similar comments apply to SSH however. If an organisation is upgrading
their SSH requirements then they are unlikely to offer telnet as an
option because that would defeat the point of upgrading SSH.

[Stephen Hoffman]

On 2019-06-05 05:37:05 +0000, Dave Froble said:

> You're missing the point. If a significant part of some companies
> business is with a trading partner who will not upgrade their SSL
> capabilities, and you have no way to get them to change, then, you do
> what you have to do to stay in business.
>
> Most of your arguments are good, but, when the alternatives are "stay
> in business" or "go out of business", the choice is easy, at least for
> me.

These companies that are both buying support and that are rolling out
OpenVMS and layered product upgrades, but that are also not
particularly maintaining their own code? That's not going to be a
growing market. Or one with much funding.

Given: OpenSSL isn't going to stop tweaking APIs with future releases.
Other products and other APIs will have similar issues, such as with
requiring particular and longer certificates.

Let those companies stay on older OpenVMS releases for the duration of
some hypothetical long-term-support LTS-style support offering. And
specifically with an old OpenSSL, these companies can't fix a flunked
audit without some app-level work, which means they're already well on
their way to maintenance or to outsourcing or to gone, or well on their
way to eventually flunking some audit or some review, and then funding
an upgrade or a port. Let these companies then figure out how to link
their own OpenSSL port. Or let these companies pay more for the older
OpenSSL. Either of these on the off chance these companies decide to
fund an upgrade or a port.

Preferably, give the folks a networking API that allows us to expunge
our pages and pages of existing IPv4 and IPv6 and DNS and TLS and
certificate-related code, as a path for folks needing SSL upgrades, and
as a foundation for new apps and for porting. And for better
capabilities and security. This also makes future software upgrades
somewhat easier, but there's a cost here to both VSI and to end-users.

Catering to the past at the expense of the present and of the future is
what got OpenVMS where it is now. I really don't think continuing
these practices can get OpenVMS where VSI and most of us want it to be,
either.

The economics have changed markedly over the years, the tech has
changed, the treadmill of upgrades is only going to accelerate, and VSI
and VSI customers are operating with fewer folks and smaller budgets.
VSI can't be everything for all. Not without a bigger and more vibrant
installed base. And how does VSI get to that? It won't be with
perpetual support of OpenSSL 0.9.8.7.6.5.4xyzzy.

Total upward-compatibility is an impossible dream. It trains folks to
dig in, and to want what is impossible. Some customer app code is
inevitably going to have to be tweaked. That's the world we're in. We
can't fit thirty-two bytes in an eight-byte buffer. Not without code
changes. Or you're not upgrading. Or the rest of us are losing out on
fixes and updates for the apps we are maintaining.

[Stephen Hoffman]

On 2019-06-04 14:57:41 +0000, doug...@aol.com said:

> "I also feel that the interface to the product should be

> somehowcompatable rather than needing re-coding to use the newer stuff.
> Notsure how easy that might be. "

>
> Easier said than done. Making internal structures opaque that were once
> directly visible and modifiable precludes forward compatibility.

Assuming folks call OpenSSL directly, quite correct.

Also welcome to why I've suggested wrapping the existing APIs.

I've previously released a descriptor-friendly set of wrappers for
OpenVMS and OpenSSL. That wrapper API could undoubtedly be done better
than what I designed, too. But it works. I'm aware of and have
previously linked to other wrappers for other platforms.

Welcome to why I keep grumbling about upward compatibility and the
inherent conflicts with fixing stuff and deprecating older APIs, too.

> Silo'd coexisting releases at least allow customers to continue to run
> their current applications until such time as they can, if ever, update
> their source code.
>

> "So, whynot some type of configuration tool that can set flagsas to

> which protocols should be allowed? Default it to TLS3, but allowwhen
> necessary for older protocols to be allowed."
>
> The handshake does this now by connecting to the strongest protocol
> enabled by both sides. Applications can set options to limit which
> protocols are available during the handshake. For instance, you can
> restrict protocols to SSL3 and TLS1.3 and ignore the three TLS versions
> in between.

Or with a wrapper, let that deal with selecting the requisite TLS
settings and the other details of the various OpenSSL APIs—preferably
also dealing with DNS and sockets and certificates and related baggage,
and preferably AST- or KP-friendly—and allow the wrapper to upgrade
connection security as newer implementations are available and/or as
older implementations become vulnerable.

ps: If I don't ever have to deal with another nonce in my
encryption-related code again, it'll be too soon...
https://eprint.iacr.org/2019/624

[Arne Vajhøj]

On 6/5/2019 11:09 PM, Stephen Hoffman wrote:
> On 2019-06-04 14:57:41 +0000, doug...@aol.com said:
>
>> "I also feel that the interface to the product should be
>> somehowcompatable rather than needing re-coding to use the newer
>> stuff.  Notsure how easy that might be. "
>>
>> Easier said than done. Making internal structures opaque that were
>> once directly visible and modifiable precludes forward compatibility.
>
> Assuming folks call OpenSSL directly, quite correct.
>
> Also welcome to why I've suggested wrapping the existing APIs.
>
> I've previously released a descriptor-friendly set of wrappers for
> OpenVMS and OpenSSL.  That wrapper API could undoubtedly be done better
> than what I designed, too.  But it works.  I'm aware of and have
> previously linked to other wrappers for other platforms.

OpenSSL actually comes with an abstraction: BIO.

BIO handle plain sockets, SSL sockets and disk files transparently.

It is a C API and I don't think it is widely used.

But it does exist.

Arne