updated mod-ssl for web server 2.2 on Alpha?

[Malcolm Dunnett]

I see on the HP CSWS site there is a patch to mod-ssl to use the SSL 1 package. I can't find such a patch for Alpha. Does anyone know if such a beast exists or is being worked on?

[DaveFroble]

Post by Malcolm Dunnett
I see on the HP CSWS site there is a patch to mod-ssl to use the SSL 1 package. I can't find such a patch for Alpha. Does anyone know if such a beast exists or is being worked on?

HPE doesn't support Alpha anymore.

[Malcolm Dunnett]

Post by DaveFroble
HPE doesn't support Alpha anymore.

I figured that. However they were still releasing patches last Fall (the Itanium patch is dated Dec 2017) and I hoped this patch might have squeaked through somewhere before they abandoned Alpha.

[John Nebel]

The VSI Apache server is v2.4 and its mod_ssl supports TLSv1.2 - it rates an A+ in the
Qualys SSL test when configured with strong ciphers and for HSTS.

Post by Malcolm Dunnett
I see on the HP CSWS site there is a patch to mod-ssl to use the SSL 1 package. I can't find such a patch for Alpha. Does anyone know if such a beast exists or is being worked on?
_______________________________________________
Info-vax mailing list
http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com

[Malcolm Dunnett]

Post by John Nebel
The VSI Apache server is v2.4 and its mod_ssl supports TLSv1.2 - it rates an A+ in the
Qualys SSL test when configured with strong ciphers and for HSTS.

I presume there is no way to get access to that product without buying a VMS license from VSI. I have emailed them asking about the cost of a license.

[Stephen Hoffman]

Post by Malcolm Dunnett
I presume there is no way to get access to that product without buying
a VMS license from VSI. I have emailed them asking about the cost of a
license.

HPE ceased the creation of new updates for OpenVMS Alpha at the end of
2016. If you're planning on staying on OpenVMS for ~enough years and
then considering porting to OpenVMS x86 sometime in the early 20202s
and particularly once the port and other dependencies becomes available
and stable, then the purchase of VSI OpenVMS Alpha licenses is your
path. That also gets you TLS updates and various patches, and it's
down-revision TLS and ssh that tend to cause the most problems as other
systems around your OpenVMS server are upgraded.

[BlackCat]

Post by Malcolm Dunnett
I see on the HP CSWS site there is a patch to mod-ssl to use the SSL 1 package. I can't find such a patch for Alpha. Does anyone know if such a beast exists or is being worked on?

Easy - Switch to WASD https://wasd.vsm.com.au/ and always be up to date, and the support is second to none!

[IanD]

+1 WASD

It's built specifically for OpenVMS and is cluster aware

Runs accepts all 3 architectures of OpenVMS (Vax, Aloha, Itanium). Vax is marooned at certain levels though, which is understandable.
It's code is open source (can't remember now which flavor) and written in C.
There's quite a few bolt on's available for it as well. It has support for websockets very early on

Mark Daniel's frequents this place every now and again (he's the custodian of it)

Don't know if VSI ever approached him to use it internally within OpenVMS or not, perhaps they should. He's written stuff that creates a web interface to OpenVMS mail as well as an awesome probe tool to have the webserver debug requests with increasing levels of granularity all selectable via a web interface.
OpenVMS doc/help us all easily accessible via the web interface as well, far better than bookreader ever was

Certainly worth a look. On OpenVMS it outperforms Apache easily

https://wasd.vsm.com.au

[Bill Gunshannon]

Post by IanD
+1 WASD
It's built specifically for OpenVMS and is cluster aware
Runs accepts all 3 architectures of OpenVMS (Vax, Aloha, Itanium). Vax is marooned at certain levels though,

^
|
Is this a Freudian slip? :-)

Post by IanD
which is understandable.

bill

[Arne Vajhøj]

Post by IanD
+1 WASD
It's built specifically for OpenVMS and is cluster aware
Runs accepts all 3 architectures of OpenVMS (Vax, Aloha, Itanium).
Vax is marooned at certain levels though, which is understandable.
It's code is open source (can't remember now which flavor) and
written in C. There's quite a few bolt on's available for it as well.
It has support for websockets very early on
Mark Daniel's frequents this place every now and again (he's the custodian of it)
Don't know if VSI ever approached him to use it internally within
OpenVMS or not, perhaps they should. He's written stuff that creates
a web interface to OpenVMS mail as well as an awesome probe tool to
have the webserver debug requests with increasing levels of
granularity all selectable via a web interface. OpenVMS doc/help us
all easily accessible via the web interface as well, far better than
bookreader ever was
Certainly worth a look. On OpenVMS it outperforms Apache easily

If ones needs are VMS centric then WASD may be an excellent choice.

But Apache is a sort of a web server platform meaning that there
are a large number of Apache modules that a company may
require (mod_security, mod_jk, mod_php* etc.).

For those needing one or more of those then Apache is needed.
So VSI could add WASD but they should not replace Apache
with WASD as some has a specific need for Apache.


Arne

*) Yes - PHP supports other execution models than Apache module,
but changing execution model can have some implications.

[Kerry Main]

-----Original Message-----
Vajhøj via Info-vax
Sent: March 20, 2018 9:33 PM
Subject: Re: [Info-vax] updated mod-ssl for web server 2.2 on Alpha?

Post by IanD
+1 WASD
It's built specifically for OpenVMS and is cluster aware
Runs accepts all 3 architectures of OpenVMS (Vax, Aloha, Itanium).
Vax is marooned at certain levels though, which is understandable.
It's code is open source (can't remember now which flavor) and
written in C. There's quite a few bolt on's available for it as well.
It has support for websockets very early on
Mark Daniel's frequents this place every now and again (he's the custodian of it)
Don't know if VSI ever approached him to use it internally within
OpenVMS or not, perhaps they should. He's written stuff that creates
a web interface to OpenVMS mail as well as an awesome probe tool to
have the webserver debug requests with increasing levels of
granularity all selectable via a web interface. OpenVMS doc/help us
all easily accessible via the web interface as well, far better than
bookreader ever was
Certainly worth a look. On OpenVMS it outperforms Apache easily

If ones needs are VMS centric then WASD may be an excellent choice.
But Apache is a sort of a web server platform meaning that there
are a large number of Apache modules that a company may
require (mod_security, mod_jk, mod_php* etc.).
For those needing one or more of those then Apache is needed.
So VSI could add WASD but they should not replace Apache
with WASD as some has a specific need for Apache.
Arne
*) Yes - PHP supports other execution models than Apache module,
but changing execution model can have some implications.

The analogy would be that while Apache is available for Windows
platforms, most Windows Customers tend to use the native IIS web server
built specifically to take advantage of native Windows features.

Same could be stated for OpenVMS environments i.e. unless there is a
COTS or some other driver that requires Apache, OpenVMS environments
would be better suited to run the WASD web server which is specifically
designed to take advantage of OpenVMS native features.

Reference:
<https://wasd.vsm.com.au/wasd_root/doc/features/>

And of course, as others have stated here, the support from Mark Daniels
is fantastic.

As an example of the level of support - March 2018 WASD V11.2 release:
(scroll down for previous release notes)
<https://wasd.vsm.com.au/wasd_root/doc/misc/changes.html>


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Arne Vajhøj]

Post by Kerry Main

Vajhøj via Info-vax
If ones needs are VMS centric then WASD may be an excellent choice.
But Apache is a sort of a web server platform meaning that there
are a large number of Apache modules that a company may
require (mod_security, mod_jk, mod_php* etc.).
For those needing one or more of those then Apache is needed.
So VSI could add WASD but they should not replace Apache
with WASD as some has a specific need for Apache.

The analogy would be that while Apache is available for Windows
platforms, most Windows Customers tend to use the native IIS web server
built specifically to take advantage of native Windows features.
Same could be stated for OpenVMS environments i.e. unless there is a
COTS or some other driver that requires Apache, OpenVMS environments
would be better suited to run the WASD web server which is specifically
designed to take advantage of OpenVMS native features.

It is not so much about using native features or about some COTS
requirements.

It is about what thet want to use the web server for and what
the application platform is.

If you want to run ASP.NET on Windows then you need IIS.

If you want to run PHP on Windows then you most likely use Apache (even
though IIS can run PHP).

What does people want to use the web server for on VMS?

Access VMS HELP or monitor VMS system? Absolutely no need for Apache.

Run DCL CGI? Absolutely no need for Apache.

Run PHP? Most likely they will want Apache even though WASD can run PHP.

Proxy servlet container? They need Apache to run mod_jk.

DMZ proxy? They need Apache to run mod_security.

Arne

[Kerry Main]

-----Original Message-----
Vajhøj via Info-vax
Sent: March 20, 2018 10:16 PM
Subject: Re: [Info-vax] updated mod-ssl for web server 2.2 on Alpha?

Post by Kerry Main

Vajhøj via Info-vax
If ones needs are VMS centric then WASD may be an excellent choice.
But Apache is a sort of a web server platform meaning that there
are a large number of Apache modules that a company may
require (mod_security, mod_jk, mod_php* etc.).
For those needing one or more of those then Apache is needed.
So VSI could add WASD but they should not replace Apache
with WASD as some has a specific need for Apache.

The analogy would be that while Apache is available for Windows
platforms, most Windows Customers tend to use the native IIS web

server

Post by Kerry Main
built specifically to take advantage of native Windows features.
Same could be stated for OpenVMS environments i.e. unless there is a
COTS or some other driver that requires Apache, OpenVMS

environments

Post by Kerry Main
would be better suited to run the WASD web server which is

specifically

Post by Kerry Main
designed to take advantage of OpenVMS native features.

It is not so much about using native features or about some COTS
requirements.
It is about what thet want to use the web server for and what
the application platform is.
If you want to run ASP.NET on Windows then you need IIS.
If you want to run PHP on Windows then you most likely use Apache (even
though IIS can run PHP).
What does people want to use the web server for on VMS?
Access VMS HELP or monitor VMS system? Absolutely no need for
Apache.
Run DCL CGI? Absolutely no need for Apache.
Run PHP? Most likely they will want Apache even though WASD can run PHP.

Use PHP and WASD.

Works very well and PHP on OpenVMS is very current 7.1.15 (March 2018 release).
<https://theberrymans.com/php_kits/>

Proxy servlet container? They need Apache to run mod_jk.
DMZ proxy? They need Apache to run mod_security.
Arne

Use WASD proxy services.
<http://wasd.vsm.com.au/wasd_root/doc/features/features_0700.html>

From 2006 - (still applicable) Apache vs WASD

<https://wasd.vsm.com.au/other/d215_wasd_apache.ppt>

March 2018:
<http://wasd.vsm.com.au/wasd_root/doc/features/>

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Malcolm Dunnett]

Thanks for the suggestions about WASD. I should check it out. I already migrated the app once though, from OSU to Apache. Not sure I want to do that again.

OTOH nobody from VSI is getting back to me with VMS license prices so maybe buying a license from them is not an option :-)

[Simon Clubley]

Post by Malcolm Dunnett
OTOH nobody from VSI is getting back to me with VMS license prices so maybe
buying a license from them is not an option :-)

Based on comments from other potential customers made in the past,
that sounds about right unfortunately. :-(

Simon.

[DaveFroble]

Post by Simon Clubley

Post by Malcolm Dunnett
OTOH nobody from VSI is getting back to me with VMS license prices so maybe
buying a license from them is not an option :-)

Based on comments from other potential customers made in the past,
that sounds about right unfortunately. :-(
Simon.

Unfortunately, VSI doesn't have several dozen customer service reps just sitting
around waiting for people to call them. So don't expect it to be that way.

If anyone is serious about wanting something from them, I'd suggest you stay on
it until you find someone with time to help you.

Perhaps ask Jan Erik how it's done, as he's mentioned that they now have support
and stuff from VSI.

[Jan-Erik Söderholm]

Post by DaveFroble

Post by Simon Clubley

Post by Malcolm Dunnett
OTOH nobody from VSI is getting back to me with VMS license prices so maybe
buying a license from them is not an option :-)

Based on comments from other potential customers made in the past,
that sounds about right unfortunately. :-(
Simon.

Unfortunately, VSI doesn't have several dozen customer service reps just
sitting around waiting for people to call them.  So don't expect it to be
that way.
If anyone is serious about wanting something from them, I'd suggest you
stay on it until you find someone with time to help you.
Perhaps ask Jan Erik how it's done, as he's mentioned that they now have
support and stuff from VSI.

Works perfectly. Have had 4-5 questions to the support since last summer,
and it is usually answered the same day. And good answers too...

I'm also on the mail list for patches and other software releases.
About 10 mails so far 2018. Not filtered on platform, so some are
Itanium-only but 5 are also referring to Alpha.

[Robert A. Brooks]

Post by Malcolm Dunnett
OTOH nobody from VSI is getting back to me with VMS license prices so maybe
buying a license from them is not an option :-)

What email address did you use to try to contact us?

I emailed you at the address shown in the note, but didn't hear back from you.

[DaveFroble]

Post by Robert A. Brooks

Post by Malcolm Dunnett
OTOH nobody from VSI is getting back to me with VMS license prices so maybe
buying a license from them is not an option :-)

What email address did you use to try to contact us?
I emailed you at the address shown in the note, but didn't hear back from you.

ROTFLMAO ....

What, he used something to avoid spam, and then expected to hear back from you?

Just guessing, and, still ROTFLMAO ...

[Robert A. Brooks]

Post by DaveFroble
ROTFLMAO ....
What, he used something to avoid spam, and then expected to hear back from you?
Just guessing, and, still ROTFLMAO ...

The address he used in the posting does not look deliberately-mangled to avoid spam.

Sure, it may be a nonsensical address, but that's what I had to work with.

[Malcolm Dunnett]

Post by Robert A. Brooks

Post by Malcolm Dunnett
OTOH nobody from VSI is getting back to me with VMS license prices so maybe
buying a license from them is not an option :-)

What email address did you use to try to contact us?
I emailed you at the address shown in the note, but didn't hear back from you.
--
-- Rob

I sent the email to info@<yourwebsitednsname> (mangled here for the address harvesters, originally vmssoftware.com) on March 18. I got that address by clicking on the link on the "Contact us" web page. The email in this posting is valid but I don't check it that often. I will check it now and respond to the rest by private email

[Arne Vajhøj]

Post by Kerry Main

Vajhøj via Info-vax

Post by Kerry Main
The analogy would be that while Apache is available for Windows
platforms, most Windows Customers tend to use the native IIS web

server

Post by Kerry Main
built specifically to take advantage of native Windows features.
Same could be stated for OpenVMS environments i.e. unless there is a
COTS or some other driver that requires Apache, OpenVMS environments
would be better suited to run the WASD web server which is specifically
designed to take advantage of OpenVMS native features.

It is not so much about using native features or about some COTS
requirements.
It is about what thet want to use the web server for and what
the application platform is.
If you want to run ASP.NET on Windows then you need IIS.
If you want to run PHP on Windows then you most likely use Apache (even
though IIS can run PHP).
What does people want to use the web server for on VMS?
Access VMS HELP or monitor VMS system? Absolutely no need for
Apache.
Run DCL CGI? Absolutely no need for Apache.
Run PHP? Most likely they will want Apache even though WASD can run PHP.

Use PHP and WASD.
Works very well and PHP on OpenVMS is very current 7.1.15 (March 2018 release).
<https://theberrymans.com/php_kits/>

That does not change that PHP as Apache module (DSO) and PHP
as CGI/FASTCGI has some slight differences. I assume WASD RTE
also has.

Why bother with that if you can get Apache.

Post by Kerry Main

Proxy servlet container? They need Apache to run mod_jk.
DMZ proxy? They need Apache to run mod_security.

Use WASD proxy services.
<http://wasd.vsm.com.au/wasd_root/doc/features/features_0700.html>

I am aware that WASD can proxy.

It does have what mod_reverse_proxy and sub modules provides.

But I wrote mod_security. That is sort of a simple WAF.

Post by Kerry Main

From 2006 - (still applicable) Apache vs WASD

<https://wasd.vsm.com.au/other/d215_wasd_apache.ppt>

There are many good reasons to chose WASD.

But doing the "standard stuff" the "standard way"
is not it.

The all standard approach may not be better than the WASD
approach. But being all standard is a goal in itself.

Arne

[Kerry Main]

-----Original Message-----
Vajhøj via Info-vax
Sent: March 22, 2018 9:56 PM
Subject: Re: [Info-vax] updated mod-ssl for web server 2.2 on Alpha?

Post by Kerry Main

Vajhøj via Info-vax

Post by Kerry Main
The analogy would be that while Apache is available for Windows
platforms, most Windows Customers tend to use the native IIS web

server

Post by Kerry Main
built specifically to take advantage of native Windows features.
Same could be stated for OpenVMS environments i.e. unless there

is a

Post by Kerry Main

Post by Kerry Main
COTS or some other driver that requires Apache, OpenVMS

environments

Post by Kerry Main

Post by Kerry Main
would be better suited to run the WASD web server which is

specifically

Post by Kerry Main

Post by Kerry Main
designed to take advantage of OpenVMS native features.

It is not so much about using native features or about some COTS
requirements.
It is about what thet want to use the web server for and what
the application platform is.
If you want to run ASP.NET on Windows then you need IIS.
If you want to run PHP on Windows then you most likely use Apache (even
though IIS can run PHP).
What does people want to use the web server for on VMS?
Access VMS HELP or monitor VMS system? Absolutely no need for Apache.
Run DCL CGI? Absolutely no need for Apache.
Run PHP? Most likely they will want Apache even though WASD can

run

Post by Kerry Main

PHP.

Use PHP and WASD.
Works very well and PHP on OpenVMS is very current 7.1.15 (March

2018 release).

Post by Kerry Main
<https://theberrymans.com/php_kits/>

That does not change that PHP as Apache module (DSO) and PHP
as CGI/FASTCGI has some slight differences. I assume WASD RTE
also has.
Why bother with that if you can get Apache.

Because Apache design is based on UNIX way of doing things. Yes, the port makes it work on OpenVMS, but WASD was designed and built from the ground up on OpenVMS.

Same could be stated for using IIS on Windows.

Post by Kerry Main

Proxy servlet container? They need Apache to run mod_jk.
DMZ proxy? They need Apache to run mod_security.

Use WASD proxy services.

<http://wasd.vsm.com.au/wasd_root/doc/features/features_0700.html
I am aware that WASD can proxy.
It does have what mod_reverse_proxy and sub modules provides.
But I wrote mod_security. That is sort of a simple WAF.

Post by Kerry Main

From 2006 - (still applicable) Apache vs WASD

<https://wasd.vsm.com.au/other/d215_wasd_apache.ppt>

There are many good reasons to chose WASD.
But doing the "standard stuff" the "standard way"
is not it.
The all standard approach may not be better than the WASD
approach. But being all standard is a goal in itself.
Arne

I am sure all those Windows environments using IIS would disagree with you on the "standards" hype .. Good luck getting those IIS sites to switch to Apache.

Yes, being all standard is a nice theoretical goal, but that is how UNIX started - before it spun off into how many different variants today?

Note - nothing wrong with Apache (the OpenVMS port actually supports A-A OpenVMS clusters as well), but if there is a product like WASD or in Windows, IIS, that is much better integrated with the native platform, there are many who will choose that product over the "standard" product that the *nix world is promoting.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Arne Vajhøj]

Post by Kerry Main

Vajhøj via Info-vax
Sent: March 22, 2018 9:56 PM

Post by Kerry Main

Vajhøj via Info-vax
Run PHP? Most likely they will want Apache even though WASD can run PHP.

Use PHP and WASD.
Works very well and PHP on OpenVMS is very current 7.1.15 (March 2018 release).
<https://theberrymans.com/php_kits/>

That does not change that PHP as Apache module (DSO) and PHP
as CGI/FASTCGI has some slight differences. I assume WASD RTE
also has.
Why bother with that if you can get Apache.

Because Apache design is based on UNIX way of doing things. Yes, the
port makes it work on OpenVMS, but WASD was designed and built from the
ground up on OpenVMS.

That does not really provide any value in itself. On the contrary
it send a signal of special / non-standard / hard to find expertise.

Post by Kerry Main
Same could be stated for using IIS on Windows.

Yes. But guess what. Most PHP users prefer Apache on Windows for PHP.

Post by Kerry Main

Post by Kerry Main

From 2006 - (still applicable) Apache vs WASD

<https://wasd.vsm.com.au/other/d215_wasd_apache.ppt>

There are many good reasons to chose WASD.
But doing the "standard stuff" the "standard way"
is not it.
The all standard approach may not be better than the WASD
approach. But being all standard is a goal in itself.

I am sure all those Windows environments using IIS would disagree
with you on the "standards" hype .. Good luck getting those IIS sites to
switch to Apache.

Try read my first reply once more.

PHP users on Windows has switched to Apache.

ASP.NET users use what is standard for that aka IIS.

The key is the applications not the OS.

Post by Kerry Main
Note - nothing wrong with Apache (the OpenVMS port actually supports
A-A OpenVMS clusters as well), but if there is a product like WASD or
in Windows, IIS, that is much better integrated with the native
platform, there are many who will choose that product over the
"standard" product that the *nix world is promoting.

The desire for tight integration with the OS is the exception.

Most want to be independent of the OS.

Arne

[Simon Clubley]

Post by Kerry Main
Because Apache design is based on UNIX way of doing things. Yes, the port
makes it work on OpenVMS, but WASD was designed and built from the ground
up on OpenVMS.

WASD was the VMS specific web server that got whacked by a number of
obvious vulnerabilities when people finally got around to probing it.

See:

https://tools.cisco.com/security/center/viewAlert.x?alertId=4727

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Kerry Main
Because Apache design is based on UNIX way of doing things. Yes, the port
makes it work on OpenVMS, but WASD was designed and built from the ground
up on OpenVMS.

WASD was the VMS specific web server that got whacked by a number of
obvious vulnerabilities when people finally got around to probing it.
https://tools.cisco.com/security/center/viewAlert.x?alertId=4727

Note though that it is from 2002.

Arne

[Jan-Erik Söderholm]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Kerry Main
Because Apache design is based on UNIX way of doing things. Yes, the port
makes it work on OpenVMS, but WASD was designed and built from the ground
up on OpenVMS.

WASD was the VMS specific web server that got whacked by a number of
obvious vulnerabilities when people finally got around to probing it.
https://tools.cisco.com/security/center/viewAlert.x?alertId=4727

Note though that it is from 2002.
Arne

The alart was from sep-2002 and the fix from dec-2002. See:
https://wasd.vsm.com.au/wasd_root/doc/misc/changes.html
and look for "Version 8.1 (December 2002)".

[Arne Vajhøj]

Post by Kerry Main

Post by Arne Vajhøj

Post by Simon Clubley

Post by Kerry Main
Because Apache design is based on UNIX way of doing things. Yes, the port
makes it work on OpenVMS, but WASD was designed and built from the ground
up on OpenVMS.

WASD was the VMS specific web server that got whacked by a number of
obvious vulnerabilities when people finally got around to probing it.
https://tools.cisco.com/security/center/viewAlert.x?alertId=4727

Note though that it is from 2002.

https://wasd.vsm.com.au/wasd_root/doc/misc/changes.html
and look for "Version 8.1  (December 2002)".

My point was that it is a rather old story.

The link already note that it has been fixed.

Arne

[Stephen Hoffman]

Post by Arne Vajhøj
My point was that it is a rather old story.
The link already note that it has been fixed.

The absence of reports does not imply the absence of vulnerabilities.

That nobody's gone looking or that nobody's logged public bug reports
also fits that same data.

This much like counting CVEs tells you how many CVEs you have counted.
At most.

[Jan-Erik Söderholm]

Post by Stephen Hoffman

Post by Arne Vajhøj
My point was that it is a rather old story.
The link already note that it has been fixed.

The absence of reports does not imply the absence of vulnerabilities.

Of course not, as with any software. But I have got the impression
that the maintainer of WASD watch any security reports that concerns
web servers in general and does any updates needed for these that
might targt WASD.

[Arne Vajhøj]

Post by Stephen Hoffman

Post by Arne Vajhøj
My point was that it is a rather old story.
The link already note that it has been fixed.

The absence of reports does not imply the absence of vulnerabilities.

True.

But I don't think that is the topic here.

The topic here is more whether an issue from 2002 that was fixed
indicate anything about level of security today.

And I will tend to say no.

Arne

[Stephen Hoffman]

Post by Arne Vajhøj

Post by Stephen Hoffman

Post by Arne Vajhøj
My point was that it is a rather old story.
The link already note that it has been fixed.

The absence of reports does not imply the absence of vulnerabilities.

True.
But I don't think that is the topic here.
The topic here is more whether an issue from 2002 that was fixed
indicate anything about level of security today.
And I will tend to say no.

This is the same logic as the CVE-count-comparison marketing.

That there were bugs identified back in 2002 didn't indicate anything
notable back in 2002, either.

That beyond that somebody noticed a problem and reported it and
somebody either fixed the problem or — as has happened in various cases
on various platforms, and much less desirably — succeeded in breaking
the then-current reproducer.

The folks that are running security reviews — which may or may not be
the folks responsible for the code — do tend to keep the results to
themselves, at least until those folks then want to or need to deploy
an exploit or a patch. And the exploits and the security patches
aren't uniformly publicized, or variously even noticed.

[Arne Vajhøj]

Post by Stephen Hoffman

Post by Arne Vajhøj

Post by Stephen Hoffman

Post by Arne Vajhøj
My point was that it is a rather old story.
The link already note that it has been fixed.

The absence of reports does not imply the absence of vulnerabilities.

True.
But I don't think that is the topic here.
The topic here is more whether an issue from 2002 that was fixed
indicate anything about level of security today.
And I will tend to say no.

This is the same logic as the CVE-count-comparison marketing.
That there were bugs identified back in 2002 didn't indicate anything
notable back in 2002, either.

No bugs found does not indicate much.

But bugs found can sometimes indicate something.

Not so much based on the existence of bugs but via the nature
of the bugs.

In this case I think it showed that WASD before 2002 had put too
little priority to security. And based on how it was handled
back then I got the clear impression that priorities changed
after that report.

Arne

[Simon Clubley]

Post by Stephen Hoffman

Post by Arne Vajhøj
My point was that it is a rather old story.
The link already note that it has been fixed.

The absence of reports does not imply the absence of vulnerabilities.
That nobody's gone looking or that nobody's logged public bug reports
also fits that same data.
This much like counting CVEs tells you how many CVEs you have counted.
At most.

And that is exactly my point. Just because a security researcher doesn't
consider it worthwhile to probe something doesn't mean that same something
is secure.

And to make the following clear, this is absolutely nothing against
Mark at all, especially given that I've just done the same to VMS itself.
It's a comment on the nature of software in general.

15 years ago, someone decided that it was worthwhile to probe a VMS
specific web server and promptly broke it in a number of obvious ways.
The code got fixed and new versions were shipped.

It doesn't mean however that there aren't other issues waiting to be
found. IOW, just because something is written for VMS it doesn't mean
that it is automatically secure.

Given two similar pieces of software with a similar development methodology
(ie: both written without formal methods, both written using similar
languages, etc), the one which is likely to be the most secure is the
one which is probed most heavily.

This is no different to VMS itself. Getting on for a decade ago, some
researchers finally decided to was worthwhile to explore VMS using
modern probing techniques and they promptly found some obvious things.

As I have just proven, it doesn't mean they found all the security bugs
in VMS at that one point in time. It just means that the other bugs
remain hidden until someone else comes up with a different way to probe
VMS (or a webserver) and then promptly find a different set of bugs.

So just because someone doesn't consider it worthwhile to probe an
operating system, it doesn't automatically mean that operating system
is secure. The same applies to web servers and any other public facing
software as well.

So to repeat, this is _nothing_ against Mark and his work on WASD.
It's just an observation on the nature of software development itself.

Simon.

[Kerry Main]

-----Original Message-----
Clubley via Info-vax
Sent: March 23, 2018 10:13 AM
Subject: Re: [Info-vax] updated mod-ssl for web server 2.2 on Alpha?

Post by Kerry Main
Because Apache design is based on UNIX way of doing things. Yes, the

port

Post by Kerry Main
makes it work on OpenVMS, but WASD was designed and built from

the ground

Post by Kerry Main
up on OpenVMS.

WASD was the VMS specific web server that got whacked by a number of
obvious vulnerabilities when people finally got around to probing it.
https://tools.cisco.com/security/center/viewAlert.x?alertId=4727
Simon.

Simon - great work on that google investigation. The link is from 2002, but great work.

😊

No product is 100% secure and the issues were addressed.
<https://wasd.vsm.com.au/wasd_root/doc/misc/wasd_advisory_020925.txt>

In terms of WASD security awareness and planning, reference:
<https://wasd.vsm.com.au/doc/config/>


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Jan-Erik Söderholm]

Post by Kerry Main

-----Original Message-----
Clubley via Info-vax
Sent: March 23, 2018 10:13 AM
Subject: Re: [Info-vax] updated mod-ssl for web server 2.2 on Alpha?

Post by Kerry Main
Because Apache design is based on UNIX way of doing things. Yes, the

port

Post by Kerry Main
makes it work on OpenVMS, but WASD was designed and built from

the ground

Post by Kerry Main
up on OpenVMS.

WASD was the VMS specific web server that got whacked by a number of
obvious vulnerabilities when people finally got around to probing it.
https://tools.cisco.com/security/center/viewAlert.x?alertId=4727
Simon.

Simon - great work on that google investigation. The link is from 2002, but great work.
😊
No product is 100% secure and the issues were addressed.
<https://wasd.vsm.com.au/wasd_root/doc/misc/wasd_advisory_020925.txt>
<https://wasd.vsm.com.au/doc/config/>
Regards,
Kerry Main
Kerry dot main at starkgaming dot com

Note that what happend was that there was a couple of settings in the
WASD config that had before been installed by default "on" that now,
with the changes made in 2002, are installed default "off".

There was nothing in the basic core design that was wrong. A few changes
was done to the code, but most of the changes was in how some options
i the config files was setup at install time.

[Simon Clubley]

Post by Kerry Main
Simon - great work on that google investigation. The link is from 2002, but great work.

You are quite welcome Kerry; it's always nice to be appreciated for the
effort involved in a 15 second Google search.

BTW, I noticed you substituted sarcasm for attention to detail because
you totally forgot the bit about how just because no-one's looking for
vulnerabilities in a product, it doesn't mean it's secure.

I assume this omission will be addressed next time around. :-)

Simon.

[Kerry Main]

-----Original Message-----
Clubley via Info-vax
Sent: March 26, 2018 8:13 AM
Subject: Re: [Info-vax] updated mod-ssl for web server 2.2 on Alpha?

Post by Kerry Main
Simon - great work on that google investigation. The link is from 2002,

but great work.
You are quite welcome Kerry; it's always nice to be appreciated for the
effort involved in a 15 second Google search.
BTW, I noticed you substituted sarcasm for attention to detail because
you totally forgot the bit about how just because no-one's looking for
vulnerabilities in a product, it doesn't mean it's secure.
I assume this omission will be addressed next time around. :-)
Simon.

Ahh yes, you are right .. just because an OS controls banks, telecom, stock exchanges, lotteries, ISP sites, core manufacturing and little things like nuclear plants is not any reason for anyone to be looking for vulnerabilities.

I wonder what types of environments those looking for vulnerabilities really want to attack?

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Stephen Hoffman]

Post by Kerry Main
The analogy would be that while Apache is available for Windows
platforms, most Windows Customers tend to use the native IIS web server
built specifically to take advantage of native Windows features.

Just spitballing here, but I'd suspect that Microsoft probably has a
few more folks working for them than does VSI. Wouldn't surprise me
to learn that the IIS development team was larger than the entirety of
VSI.

Post by Kerry Main
Same could be stated for OpenVMS environments i.e. unless there is a
COTS or some other driver that requires Apache, OpenVMS environments
would be better suited to run the WASD web server which is specifically
designed to take advantage of OpenVMS native features.

Now VSI just picked up the maintenance and updates of a platform-unique
product, as well as accepting the implicit costs of customers migrating
to WASD.

Years ago, we all went through something similar with Purveyor and
related. Folks wanted and consolidated onto Apache httpd server or
nginx. Want to do custom web-related work and have some staff? Extend
Apache httpd or nginx to be better integrated with OpenVMS. Get Java
10 and current php and python supported. Sorting out the cryptographic
morass that are the certificate and TLS and CDSA APIs on OpenVMS, and
getting APIs and frameworks in place that avoid the need to have to
rebuild the higher-level bits nearly as often as has been past
practice. Integrating Apache httpd or nginx into the base distro as an
optionally-enabled feature; where it really should already be
integrated and always-resident. Whatever.

VSI isn't big enough to have the luxury of bespoke products. Even if
they were, adding undifferentiated bespoke products increases the costs
of training folks to use the platform.

Otherwise, you're now working on ACME2 (mod_md) and HTTP/2 and other
bits that already exist in Apache httpd.

The VSI Apache httpd port of 2.4.12 is right at the edge of HTTP/2
support, but the VSI port seems to lack mod_h2. Apache httpd 2.4.29 is
current.

Then there's the more general and pragmatic... VSI is far better to
integrate with and to avoid competing with open-source projects such as
the Apache httpd server.

As for the current web server market...
https://w3techs.com/technologies/overview/web_server/all

Yes, WASD is a very nice package, and well integrated.

[DaveFroble]

Post by Kerry Main
The analogy would be that while Apache is available for Windows
platforms, most Windows Customers tend to use the native IIS web
server built specifically to take advantage of native Windows features.

Just spitballing here, but I'd suspect that Microsoft probably has a few
more folks working for them than does VSI. Wouldn't surprise me to
learn that the IIS development team was larger than the entirety of VSI.

Post by Kerry Main
Same could be stated for OpenVMS environments i.e. unless there is a
COTS or some other driver that requires Apache, OpenVMS environments
would be better suited to run the WASD web server which is
specifically designed to take advantage of OpenVMS native features.

Now VSI just picked up the maintenance and updates of a platform-unique
product, as well as accepting the implicit costs of customers migrating
to WASD.
Years ago, we all went through something similar with Purveyor and
related. Folks wanted and consolidated onto Apache httpd server or
nginx. Want to do custom web-related work and have some staff? Extend
Apache httpd or nginx to be better integrated with OpenVMS. Get Java
10 and current php and python supported. Sorting out the cryptographic
morass that are the certificate and TLS and CDSA APIs on OpenVMS, and
getting APIs and frameworks in place that avoid the need to have to
rebuild the higher-level bits nearly as often as has been past
practice. Integrating Apache httpd or nginx into the base distro as an
optionally-enabled feature; where it really should already be integrated
and always-resident. Whatever.
VSI isn't big enough to have the luxury of bespoke products. Even if
they were, adding undifferentiated bespoke products increases the costs
of training folks to use the platform.
Otherwise, you're now working on ACME2 (mod_md) and HTTP/2 and other
bits that already exist in Apache httpd.
The VSI Apache httpd port of 2.4.12 is right at the edge of HTTP/2
support, but the VSI port seems to lack mod_h2. Apache httpd 2.4.29 is
current.
Then there's the more general and pragmatic... VSI is far better to
integrate with and to avoid competing with open-source projects such as
the Apache httpd server.
As for the current web server market...
https://w3techs.com/technologies/overview/web_server/all
Yes, WASD is a very nice package, and well integrated.

I'm to understand that WASD is now available to any VMS user that desires it.
So help me out here, what more is required?

Why should VSI do anything with WASD, other than notify their customers about
how to find it?

I don't understand the problem, unless, some wish to get rid of all third party
software vendors? And then where would open source be?

[Stephen Hoffman]

Post by DaveFroble
I'm to understand that WASD is now available to any VMS user that
desires it. So help me out here, what more is required?
Why should VSI do anything with WASD, other than notify their customers
about how to find it?
I don't understand the problem, unless, some wish to get rid of all
third party software vendors? And then where would open source be?

The folks are suggesting that VSI adopt and use it as a replacement for
Apache or nginx. If VSI should decide to follow that path, I'd hope
they'd at least offer to fund some or all of its development, or make
other arrangements related to its current and continued availability.
Among other details.

[Kerry Main]

-----Original Message-----
Hoffman via Info-vax
Sent: March 23, 2018 1:23 AM
Subject: Re: [Info-vax] updated mod-ssl for web server 2.2 on Alpha?

Post by DaveFroble
I'm to understand that WASD is now available to any VMS user that
desires it. So help me out here, what more is required?
Why should VSI do anything with WASD, other than notify their

customers

Post by DaveFroble
about how to find it?
I don't understand the problem, unless, some wish to get rid of all
third party software vendors? And then where would open source be?

The folks are suggesting that VSI adopt and use it as a replacement for
Apache or nginx. If VSI should decide to follow that path, I'd hope
they'd at least offer to fund some or all of its development, or make
other arrangements related to its current and continued availability.
Among other details.

Who was saying drop Apache?

As David stated, its not one or the other but both (and OSU as well)

Some Customers may want the UNIX approach, which UNIX developers state
is the "standard" way to do web serving (Apache/PHP/?) and some may
prefer a more integrated platform on OpenVMS approach with
WASD/OSU/PHP/?.

Both have pro's and con's.

Its no different than why some Customers on Windows prefer IIS over
Apache on the Windows platform.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Arne Vajhøj]

Post by Kerry Main
Who was saying drop Apache?
As David stated, its not one or the other but both (and OSU as well)
Some Customers may want the UNIX approach, which UNIX developers state
is the "standard" way to do web serving (Apache/PHP/?)

It is not what is below but is above.

People want Apache because of the modules available that
provides various functionality in a way that their
applications and operations expect.

The fact that it may have Unix'ism is not important.

Post by Kerry Main
and some may
prefer a more integrated platform on OpenVMS approach with
WASD/OSU/PHP/?.
Both have pro's and con's.
Its no different than why some Customers on Windows prefer IIS over
Apache on the Windows platform.

Again it is not what is below but is above.

You chose IIS if you have an ASP.NET application (or god forbid
it - an ASP application).

It is relative rare that the application is that Windows
integrated. ASP.NET usually stays with System.* stuff
and don't use any Microsoft.* stuff. Even the COM stuff
used in old ASP is not really Windows integration but just
database access, XML access etc..

Arne

[Stephen Hoffman]

Post by Kerry Main
Who was saying drop Apache?

Effectively, that'd be everybody that's recommending integrating and
shipping WASD. VSI cannot afford to run multiple parallel competing
capabilities.

If VSI does decide to pick up WASD as the preferred web server, then
they additionally either have to implement the evolving standards, or
fund that work. Basically, adopting WASD means VSI is now not just
funding parallel efforts, it's also now going to be measured against
what Apache httpd developers are implementing.

Post by Kerry Main
As David stated, its not one or the other but both (and OSU as well)

VSI cannot afford to run parallel projects with common requirements.
Pick one. Invest. Picking several different web servers? That'll
mean everybody gets to test multiple servers, too.

Post by Kerry Main
Some Customers may want the UNIX approach, which UNIX developers state
is the "standard" way to do web serving (Apache/PHP/?) and some may
prefer a more integrated platform on OpenVMS approach with
WASD/OSU/PHP/?.

There'll always be a variety of disparate and conflicting requirements
and expectation from customers, too.

VSI is not in a position to fund multiple efforts, and will be
obligated to put their efforts behind fewer projects.

Which means that VSI gets to pick what they think the most customers
will accept.

Post by Kerry Main
Both have pro's and con's.

The bigger issue is what VSI can afford to fund, integrate and maintain.

Post by Kerry Main
Its no different than why some Customers on Windows prefer IIS over
Apache on the Windows platform.

Few places have reasons to fund and test and run competing projects.
Pick one, focus on it, make it work. Make it work, and make it work
well with OpenVMS.

As for the comparison, Microsoft funds the IIS development work.

As compared with VSI, Microsoft actually does have the scale of budget
and staffing to allow it to compete with itself, and that has the scale
to develop bespoke web services and a bespoke web browser and various
bespoke interconnected products and services, and not the least of
which are Office and Office365 and Azure and SharePoint. VSI... does
not have the same scale, nor the same funding, nor is OpenVMS presently
particularly integrated with IP networking much less with web services.
VSI is not comparable to the far-larger Microsoft, whether discussing
relative budgets, revenues, bureaucracy, staff, volume of open source
development work, or otherwise.

Pick one web server. Focus on it. Integrate it. Make it the best
that current budget and current staff allows. Don't split the effort,
whether for VSI or for ISVs.

[Mark Daniel]

'Scuse the top-post (it's not really a follow-up, more an interjection).

There seems to be lot of effort expended discussing something that seems
incredibly unlikely to happen. Not that marginal investments are
unknown to the forum. IMO (and only commenting as the author of a
discussed package) ditching Apache for WASD would be a mistake. For all
the critical points made in this thread, and then some. Comparable to
VSI rolling its own in-house TLS or TCP/IP stack.

In days of yore there was a (VMS) choice between a single-threaded CERN
HTTP server and an incipient OSU. That WASD is on the cusp of a
quarter-century development and deployment is remarkable. That some
sites still choose it over Apache means that at least some of its
particular attributes have greater value than the cost of its quirks.
For them. Others find such integration unnecessary or
counter-productive. And while the word "quirk" lingers in the air,
let's not forget that Apache on VMS has had and continues to have it's own.

Whatever the xenografts end up being, unlike the previous custodians of
VMS, VSI are going to need to invest in real terms, maintaining the
currency, improving capability, and ... in VMS integration.

Post by Stephen Hoffman

Post by Kerry Main
Who was saying drop Apache?

Effectively, that'd be everybody that's recommending integrating and
shipping WASD.   VSI cannot afford to run multiple parallel competing
capabilities.
If VSI does decide to pick up WASD as the preferred web server, then
they additionally either have to implement the evolving standards, or
fund that work.  Basically, adopting WASD means VSI is now not just
funding parallel efforts, it's also now going to be measured against
what Apache httpd developers are implementing.

Post by Kerry Main
As David stated, its not one or the other but both (and OSU as well)

VSI cannot afford to run parallel projects with common requirements.
Pick one.  Invest.  Picking several different web servers?  That'll mean
everybody gets to test multiple servers, too.

Post by Kerry Main
Some Customers may want the UNIX approach, which UNIX developers state
is the "standard" way to do web serving (Apache/PHP/?) and some may
prefer a more integrated platform on OpenVMS approach with
WASD/OSU/PHP/?.

There'll always be a variety of disparate and conflicting requirements
and expectation from customers, too.
VSI is not in a position to fund multiple efforts, and will be obligated
to put their efforts behind fewer projects.
Which means that VSI gets to pick what they think the most customers
will accept.

Post by Kerry Main
Both have pro's and con's.

The bigger issue is what VSI can afford to fund, integrate and maintain.

Post by Kerry Main
Its no different than why some Customers on Windows prefer IIS over
Apache on the Windows platform.

Few places have reasons to fund and test and run competing projects.
Pick one, focus on it, make it work.  Make it work, and make it work
well with OpenVMS.
As for the comparison, Microsoft funds the IIS development work.
As compared with VSI, Microsoft actually does have the scale of budget
and staffing to allow it to compete with itself, and that has the scale
to develop bespoke web services and a bespoke web browser and various
bespoke interconnected products and services, and not the least of which
are Office and Office365 and Azure and SharePoint.  VSI... does not have
the same scale, nor the same funding, nor is OpenVMS presently
particularly integrated with IP networking much less with web services.
VSI is not comparable to the far-larger Microsoft, whether discussing
relative budgets, revenues, bureaucracy, staff, volume of open source
development work, or otherwise.
Pick one web server.  Focus on it.  Integrate it.   Make it the best
that current budget and current staff allows.  Don't split the effort,
whether for VSI or for ISVs.

[Kerry Main]

-----Original Message-----
Hoffman via Info-vax
Sent: March 22, 2018 9:45 PM
Subject: Re: [Info-vax] updated mod-ssl for web server 2.2 on Alpha?

Post by Kerry Main
The analogy would be that while Apache is available for Windows
platforms, most Windows Customers tend to use the native IIS web

server

Post by Kerry Main
built specifically to take advantage of native Windows features.

Just spitballing here, but I'd suspect that Microsoft probably has a
few more folks working for them than does VSI. Wouldn't surprise me
to learn that the IIS development team was larger than the entirety of
VSI.

Post by Kerry Main
Same could be stated for OpenVMS environments i.e. unless there is a
COTS or some other driver that requires Apache, OpenVMS

environments

Post by Kerry Main
would be better suited to run the WASD web server which is

specifically

Post by Kerry Main
designed to take advantage of OpenVMS native features.

Now VSI just picked up the maintenance and updates of a platform-
unique
product, as well as accepting the implicit costs of customers

migrating

to WASD.

Not sure what your point is. There is nothing wrong with adopting a long
range strategy that emphasizes products that are heavily integrated with
your native platform vs, other "standard" products that were designed
for another OS platform.

Years ago, we all went through something similar with Purveyor and
related. Folks wanted and consolidated onto Apache httpd server or
nginx. Want to do custom web-related work and have some staff?
Extend
Apache httpd or nginx to be better integrated with OpenVMS. Get Java
10 and current php and python supported. Sorting out the

cryptographic

morass that are the certificate and TLS and CDSA APIs on OpenVMS, and
getting APIs and frameworks in place that avoid the need to have to
rebuild the higher-level bits nearly as often as has been past
practice. Integrating Apache httpd or nginx into the base distro as an
optionally-enabled feature; where it really should already be
integrated and always-resident. Whatever.

All good things to do - not for just Apache, but for all the other apps
as well.

VSI isn't big enough to have the luxury of bespoke products. Even if
they were, adding undifferentiated bespoke products increases the costs
of training folks to use the platform.
Otherwise, you're now working on ACME2 (mod_md) and HTTP/2 and
other
bits that already exist in Apache httpd.

They also exist today in WASD.

The VSI Apache httpd port of 2.4.12 is right at the edge of HTTP/2
support, but the VSI port seems to lack mod_h2. Apache httpd 2.4.29 is
current.
Then there's the more general and pragmatic... VSI is far better to
integrate with and to avoid competing with open-source projects such as
the Apache httpd server.
As for the current web server market...
https://w3techs.com/technologies/overview/web_server/all
Yes, WASD is a very nice package, and well integrated.

There is a place for both products.

To address those Customers that have bought into the "standard" Apache
i.e. UNIX way of doing things, then absolutely, VSI needs the best
Apache port it can create.

To address those Customers that want products that are heavily
integrated into the native platform - perhaps for better performance,
ease of troubleshooting etc., then VSI needs products like WASD which
btw, is very current with Web standards.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Stephen Hoffman]

Post by Kerry Main
Not sure what your point is. There is nothing wrong with adopting a
long range strategy that emphasizes products that are heavily
integrated with your native platform vs, other "standard" products that
were designed for another OS platform.

Sure, if you have the staff and the budget for it, and if whatever
you're working on has enough of a differentiation that the customers
are willing to expend the extra effort involved.

If the work is not enough of a differentiation or if it incurs
additional costs, then you're better off investing more of that time
and effort elsewhere, and in porting and integrating the open source.

If VSI were operating at an appreciable fraction of the Microsoft staff
and budget and requirements — or 1990s-era DEC investments in OpenVMS,
for that matter — then the calculation here might or will differ.

Then there's the management discussion of having to fund and track and
stay current with the web standards and web server expectations, or
whether you're willing to fall behind there and with all that entails.
There's also a shedload of stuff supported by Apache in general, with a
subset of that ported to OpenVMS. But then I'm also dealing with
Apache httpd servers that are tied into LDAP, and other related
integration. Folks are increasingly expecting this integration and
these extensions, too.

If you're willing to try to compete with an open source at this scale
with a bespoke offering, well, have at. That investment probably won't
end all that well, unless that competition is most or all of your
entire business.

Of the available approaches, I'd rather see Apache httpd integrated
into the base distribution, and tied directly into OpenVMS, and with
the changes either merged upstream or automated.

And then there's the discussion that OpenVMS has just never been good
at tools for importing and exporting configuration files; at making
migrations from other platforms to OpenVMS easier. In this case, tools
for migrating from Apache httpd or nginx to the WASD server or
otherwise. Because if it's bespoke, customers are going to be
importing and exporting web server configuration files, and setting up
profiles and related for deployments.

[IanD]

+1 WASD

It's built specifically for OpenVMS and is cluster aware

Runs across all 3 architectures of OpenVMS (Vax, Aloha, Itanium). Vax is marooned at certain levels though, which is understandable

It's code is open source (can't remember now which flavor) and written in C.
There's quite a few bolt on's available for it as well. It had support for websockets very early on

Mark Daniel's frequents this place every now and again (he's the custodian of it)

Don't know if VSI ever approached him to use it internally within OpenVMS or not, perhaps they should.

He's written stuff that creates a web interface to OpenVMS mail as well as an awesome probe tool to have the webserver debug requests with increasing levels of granularity all selectable via a web interface.

OpenVMS doc/help us all easily accessible via the web interface as well, far better than bookreader ever was

Certainly worth a look. On OpenVMS it outperforms Apache easily

https://wasd.vsm.com.au