Just got an email from VSI, their version of SSL V3 is now available. This
should be a good thing, bringing some of the latest SSL stuff to VMS.

Some good news.

Now if only a decent TCP/IP was available.

Still, lots of hope for VMS capabilities. Be nice if some new customers came along.

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

On 2/15/2022 10:56 PM, Dave Froble wrote:
> Just got an email from VSI, their version of SSL V3 is now available.
> This should be a good thing, bringing some of the latest SSL stuff to VMS.

I assume OpenSSL software version 3.x and not SSL protocol version 3.0.

OpenSSL 3.x is latest and greatest. SSL 3.0 is very much obsolete and
deprecated - only TLS 1.2 and 1.3 should be used - and obviously OpenSSL
3.x support those.

> Still, lots of hope for VMS capabilities.  Be nice if some new customers
> came along.

Yes!!

Arne

On 2/16/22 7:31 AM, Arne Vajhøj wrote:
> On 2/15/2022 10:56 PM, Dave Froble wrote:
>> Just got an email from VSI, their version of SSL V3 is now available.
>> This should be a good thing, bringing some of the latest SSL stuff to
>> VMS.
>
> I assume OpenSSL software version 3.x and not SSL protocol version 3.0.
>
> OpenSSL 3.x is latest and greatest. SSL 3.0 is very much obsolete and
> deprecated - only TLS 1.2 and 1.3 should be used - and obviously OpenSSL
> 3.x support those.

Yes, they are calling it OpenSSL v3.0-1, which presumably corresponds to
OpenSSL 3.0.1. The product name is SSL3. Since binary compatibility is
now guaranteed for anything with the same major version number, we
should not have a repeat of the product naming madness that resulted in
SSL111.

On 2/16/2022 8:52 AM, Craig A. Berry wrote:
> On 2/16/22 7:31 AM, Arne Vajhøj wrote:
>> On 2/15/2022 10:56 PM, Dave Froble wrote:
>>> Just got an email from VSI, their version of SSL V3 is now available.
>>> This should be a good thing, bringing some of the latest SSL stuff to
>>> VMS.
>>
>> I assume OpenSSL software version 3.x and not SSL protocol version 3.0.
>>
>> OpenSSL 3.x is latest and greatest. SSL 3.0 is very much obsolete and
>> deprecated - only TLS 1.2 and 1.3 should be used - and obviously OpenSSL
>> 3.x support those.
>
> Yes, they are calling it OpenSSL v3.0-1, which presumably corresponds to
> OpenSSL 3.0.1.  The product name is SSL3.  Since binary compatibility is
> now guaranteed for anything with the same major version number, we
> should not have a repeat of the product naming madness that resulted in
> SSL111.

Retain open source name and VMSify version number from x.y.z to x.y-z is
all fine. No confusion.

I just wanted to ensure that everyone know the difference between
OpenSSL 3.x and SSL 3 - the SSL 3 protocol is banned everywhere
as insecure (or at least should be).

Arne

On 2022-02-16, Craig A. Berry <craigberry@nospam.mac.com> wrote:
>
> On 2/16/22 7:31 AM, Arne Vajhøj wrote:
>> On 2/15/2022 10:56 PM, Dave Froble wrote:
>>> Just got an email from VSI, their version of SSL V3 is now available.
>>> This should be a good thing, bringing some of the latest SSL stuff to
>>> VMS.
>>
>> I assume OpenSSL software version 3.x and not SSL protocol version 3.0.
>>
>> OpenSSL 3.x is latest and greatest. SSL 3.0 is very much obsolete and
>> deprecated - only TLS 1.2 and 1.3 should be used - and obviously OpenSSL
>> 3.x support those.
>
> Yes, they are calling it OpenSSL v3.0-1, which presumably corresponds to
> OpenSSL 3.0.1. The product name is SSL3. Since binary compatibility is
> now guaranteed for anything with the same major version number, we
> should not have a repeat of the product naming madness that resulted in
> SSL111.
>

I wish people would not rename an open source product with a
slightly different VMS-specific name. It's bloody confusing
and completely unnecessary. :-(

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-02-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 2/16/2022 8:52 AM, Craig A. Berry wrote:
>>
>> Yes, they are calling it OpenSSL v3.0-1, which presumably corresponds to
>> OpenSSL 3.0.1.  The product name is SSL3.  Since binary compatibility is
>> now guaranteed for anything with the same major version number, we
>> should not have a repeat of the product naming madness that resulted in
>> SSL111.
>
> Retain open source name and VMSify version number from x.y.z to x.y-z is
> all fine. No confusion.
>

What about 6 months from now when people are asking if this is a
patch for v3.0 or is really a renamed v3.0.1 ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2/16/2022 9:08 AM, Simon Clubley wrote:
> On 2022-02-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/16/2022 8:52 AM, Craig A. Berry wrote:
>>> Yes, they are calling it OpenSSL v3.0-1, which presumably corresponds to
>>> OpenSSL 3.0.1.  The product name is SSL3.  Since binary compatibility is
>>> now guaranteed for anything with the same major version number, we
>>> should not have a repeat of the product naming madness that resulted in
>>> SSL111.
>>
>> Retain open source name and VMSify version number from x.y.z to x.y-z is
>> all fine. No confusion.
>
> What about 6 months from now when people are asking if this is a
> patch for v3.0 or is really a renamed v3.0.1 ?

Then somebody tell them that VMS version number convention is
not major.minor.release.patchlevel but
major.minor-release ECOpatchlevel.

Arne

Den 2022-02-16 kl. 15:46, skrev Arne Vajhøj:
> On 2/16/2022 9:08 AM, Simon Clubley wrote:
>> On 2022-02-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 2/16/2022 8:52 AM, Craig A. Berry wrote:
>>>> Yes, they are calling it OpenSSL v3.0-1, which presumably corresponds to
>>>> OpenSSL 3.0.1.  The product name is SSL3.  Since binary compatibility is
>>>> now guaranteed for anything with the same major version number, we
>>>> should not have a repeat of the product naming madness that resulted in
>>>> SSL111.
>>>
>>> Retain open source name and VMSify version number from x.y.z to x.y-z is
>>> all fine. No confusion.
>>
>> What about 6 months from now when people are asking if this is a
>> patch for v3.0 or is really a renamed v3.0.1 ?
>
> Then somebody tell them that VMS version number convention is
> not major.minor.release.patchlevel but
> major.minor-release ECOpatchlevel.
>
> Arne
>
>

It's the same as Oracle Rdb 7.4.1.1.0 being called V7.4-110 in VMS itself.

So, Simon, what should it be called? My understading is that there are
rules used by VMS on how to format a vesion number.

On 2022-02-16 03:56:17 +0000, Dave Froble said:

> Just got an email from VSI, their version of SSL V3 is now available.
> This should be a good thing, bringing some of the latest SSL stuff to
> VMS.

OpenSSL 3.0.1 (SSL3 kit on OpenVMS, as differentiated from SSLv3) and
OpenSSH 8.8 both.

> Some good news.

Ayup. Definitely.

> Now if only a decent TCP/IP was available.

Getting more current SSL and more current ssh are a big part of that,
with more networking work and more networking integration work awaiting
VSI.

The network configuration tool is unnecessarily complex and error-prone
and unintegrated, for instance. It's blown up on me several times over
recent months, crashing out with missing symbols. Not that getting any
of the existing network configs over into some newer scheme will be
trivial, or will even be attempted, or won't otherwise run afoul of
existing UIC allocations or usernames selected. That OpenSSL 3.0.1 is
correctly but confusingly known as the SSL3 kit on OpenVMS—as
differentiated from the ancient SSLv3 version—is another area that
would disappear with networking integration, too. IP networking and SSL
shouldn't be separate installation kits or otherwise visible to an
installer. Not any more. But VSI necessarily has much bigger
priorities, not the least of which is the completion of the x86-64
port. Fixing an ever-more complex management UI likely isn't at the top
of any schedule or any priority list, but it is a cost that accretes.

--
Pure Personal Opinion | HoffmanLabs LLC

On 16/2/22 2:26 pm, Dave Froble wrote:
> Just got an email from VSI, their version of SSL V3 is now available.

Dave, would you mind posting the relevant section(s) of this advice.

I have been building OpenSSL 3.0.0 and 3.0.1 since release and currently
have an unresolved performance issue open

https://github.com/openssl/openssl/issues/16552

As VSI have released

VSI X86VMS SSL111 V1.1-1MA Full LP Install Val 04-FEB-2022

only in the last couple of weeks, the announcement seems a little odd.

> This should be a good thing, bringing some of the latest SSL stuff to VMS.
>
> Some good news.
>
> Now if only a decent TCP/IP was available.
>
> Still, lots of hope for VMS capabilities.  Be nice if some new customers
> came along.

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

On 17/2/22 2:44 am, Mark Daniel wrote:
> On 16/2/22 2:26 pm, Dave Froble wrote:
>> Just got an email from VSI, their version of SSL V3 is now available.
>
> Dave, would you mind posting the relevant section(s) of this advice.

Thanks but don't bother. Found it myself.

https://vmssoftware.com/products/ssl3/

> I have been building OpenSSL 3.0.0 and 3.0.1 since release and currently
> have an unresolved performance issue open
>
> https://github.com/openssl/openssl/issues/16552
>
> As VSI have released
>
> VSI X86VMS SSL111 V1.1-1MA    Full LP   Install    Val 04-FEB-2022
>
> only in the last couple of weeks, the announcement seems a little odd.
>
>> This should be a good thing, bringing some of the latest SSL stuff to
>> VMS.
>>
>> Some good news.
>>
>> Now if only a decent TCP/IP was available.
>>
>> Still, lots of hope for VMS capabilities.  Be nice if some new
>> customers came along.

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

On 2022-02-16 16:44:54 +0000, Mark Daniel said:

> On 16/2/22 2:26 pm, Dave Froble wrote:
>> Just got an email from VSI, their version of SSL V3 is now available.
>
> Dave, would you mind posting the relevant section(s) of this advice.
>
> I have been building OpenSSL 3.0.0 and 3.0.1 since release and
> currently have an unresolved performance issue open
>
> https://github.com/openssl/openssl/issues/16552
>
> As VSI have released
>
> VSI X86VMS SSL111 V1.1-1MA Full LP Install Val 04-FEB-2022
>
> only in the last couple of weeks, the announcement seems a little odd.

I'd expect to see both OpenSSL v1.1-1 / SSL111 / OpenSSL 1.1.1 and
OpenSSL v3.0-1 / SSL3 / OpenSSL 3.0.1 released in parallel for a while
and each with occasional updates, to give folks the opportunity to
migrate apps to OpenSSL v3.0-1 / SSL3 / OpenSSL 3.0.1.

The OpenSSL v3.0-1 release notes make it very clear that this is to be
a rolling migration, and that "under no circumstances should [OpenSSL
1.1.1] be removed". That advice will undoubtedly change as VSI and
third-parties and end-users all complete the migration.

The newly-announced OpenSSH 8.8 kit is currently available (only) for
OpenVMS x86-64 V9.1A and later.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2/16/2022 11:14 AM, Mark Daniel wrote:
> On 16/2/22 2:26 pm, Dave Froble wrote:
>> Just got an email from VSI, their version of SSL V3 is now available.
>
> Dave, would you mind posting the relevant section(s) of this advice.
>
> I have been building OpenSSL 3.0.0 and 3.0.1 since release and currently
> have an unresolved performance issue open
>
> https://github.com/openssl/openssl/issues/16552
>
> As VSI have released
>
> VSI X86VMS SSL111 V1.1-1MA    Full LP   Install    Val 04-FEB-2022
>
> only in the last couple of weeks, the announcement seems a little odd.

Their web site got:

https://vmssoftware.com/products/ssl3/

Arne

On 2/16/22 10:14 AM, Mark Daniel wrote:
> On 16/2/22 2:26 pm, Dave Froble wrote:
>> Just got an email from VSI, their version of SSL V3 is now available.
>
> Dave, would you mind posting the relevant section(s) of this advice.

I'm not sure what advice you refer to, but the announcement did
emphasize that people should not try to uninstall SSL111 and that the
3.x kit was being made available so people could start investigating
compatibility and migration.

> I have been building OpenSSL 3.0.0 and 3.0.1 since release and currently
> have an unresolved performance issue open
>
> https://github.com/openssl/openssl/issues/16552
>
> As VSI have released
>
> VSI X86VMS SSL111 V1.1-1MA    Full LP   Install    Val 04-FEB-2022
>
> only in the last couple of weeks, the announcement seems a little odd.

I think the only news here for you is that other people who rely on an
installation kit can now find the problems you've already found by
building your own from source.

Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>
> The OpenSSL v3.0-1 release notes make it very clear…
>
[to me] that I have no reason to envy anyone the task of dealing with this
hash (that is, mess).

On 2022-02-16 16:58:13 +0000, Galen said:

> Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>
>> The OpenSSL v3.0-1 release notes make it very clear…
>>
> [to me] that I have no reason to envy anyone the task of dealing with
> this hash (that is, mess).

The upgrade from OpenSSL 0.9.x to OpenSSL 1—known as SSL V1.3 to SSL
V1.4 on OpenVMS, back when the OpenVMS versions didn't parallel the
upstream versions—required everything else linked with SSL to upgrade.
Locally, there were a couple of other products affected, but some sites
had a half-dozen or more apps or tools that needed upgrades parallel to
the SSL V1.4 upgrade.

That this area is still a bit of a hash—though somewhat less so, as a
rolling upgrade of apps and products is now usually possible—is also
why there are somewhat more stable networking frameworks available on
some other platforms. Some of those frameworks include easier handling
of the rest of of app networking; of DNS or mDNS, IPv4 and IPv6
transparency, and related error handling and recovery and
authentication.

[Ponders whether the existing multi-version support within OpenVMS
would permit a parallel installation of LibreSSL and its libtls API, as
an alternative to OpenSSL and its API on OpenVMS.]

--
Pure Personal Opinion | HoffmanLabs LLC

On 17/2/22 3:08 am, Craig A. Berry wrote:
>
> On 2/16/22 10:14 AM, Mark Daniel wrote:
>> On 16/2/22 2:26 pm, Dave Froble wrote:
>>> Just got an email from VSI, their version of SSL V3 is now available.
>>
>> Dave, would you mind posting the relevant section(s) of this advice.
>
> I'm not sure what advice you refer to, but the announcement did
> emphasize that people should not try to uninstall SSL111 and that the
> 3.x kit was being made available so people could start investigating
> compatibility and migration.

See that now I've installed the kit.

>> I have been building OpenSSL 3.0.0 and 3.0.1 since release and
>> currently have an unresolved performance issue open
>>
>> https://github.com/openssl/openssl/issues/16552
>>
>> As VSI have released
>>
>> VSI X86VMS SSL111 V1.1-1MA    Full LP   Install    Val 04-FEB-2022
>>
>> only in the last couple of weeks, the announcement seems a little odd.
>
> I think the only news here for you is that other people who rely on an
> installation kit can now find the problems you've already found by
> building your own from source.

The released kit contains the described performance issue.

https://github.com/openssl/openssl/issues/16552

$ @build_sesola3.com 1
$ mcr []sesola3
OpenSSL 1.1.1k 25 Mar 2021
value: 1
ELAPSED: 0 00:00:00.20 CPU: 0:00:00.19 BUFIO: 4 DIRIO: 7 FAULTS: 158
$ @build_sesola3.com 3
$ mcr []sesola3
OpenSSL 3.0.1 14 Dec 2021
value: 1
ELAPSED: 0 00:00:06.63 CPU: 0:00:06.58 BUFIO: 4 DIRIO: 7 FAULTS: 237

On the BRIGHT SIDE - VSI being proactive on these essential tools is a
refreshing change from the previous incumbents' approach of only
releasing at version EOL or when containing *absolutely* critical fixes.

Might be able to give the WASD-specific builds away if they can keep
this up.

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

On 2022-02-16, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>
> It's the same as Oracle Rdb 7.4.1.1.0 being called V7.4-110 in VMS itself.
>

That's just yucky. :-)

However, that's also not something which is known by a different name
on (say) Linux.

> So, Simon, what should it be called? My understading is that there are
> rules used by VMS on how to format a vesion number.

VMS isn't the centre of the world anymore Jan-Erik.

Quite a lot of what VMS is running these days was written on another
operating system and to avoid confusion on VMS, the VMS name should
be as close to the real name as possible.

If VSI make some VMS-specific changes _then_ they can call it an ECO
or create a VMS format -release. Until then it should be the real
version of the project that is used.

In addition to version number confusion, open source projects in
the past have been renamed for no good reason on VMS (Apache becoming
CSWS would be one good example). I hope VSI _never_ start doing that.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-02-16, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>
> I'd expect to see both OpenSSL v1.1-1 / SSL111 / OpenSSL 1.1.1 and
> OpenSSL v3.0-1 / SSL3 / OpenSSL 3.0.1 released in parallel for a while
> and each with occasional updates, to give folks the opportunity to
> migrate apps to OpenSSL v3.0-1 / SSL3 / OpenSSL 3.0.1.
>

Is it 3.0.0 or 3.0.1 that's being shipped by VSI ?

The release notes claim 3.0.1 but the VSI website points to the old 3.0.0
releases at https://www.openssl.org/source/old/3.0/

Also, the kit name is SSL3, but given that there are multiple SSL libraries
available, that should really be OPENSSL3. This might not matter to those
of us who keep a mental matrix of VMS versions to real versions, but
to others, it's just another source of unnecessary confusion about what
exactly is running on VMS.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Den 2022-02-16 kl. 20:19, skrev Simon Clubley:
> On 2022-02-16, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>>
>> It's the same as Oracle Rdb 7.4.1.1.0 being called V7.4-110 in VMS itself.
>>
>
> That's just yucky. :-)

Maybe, but it is nt a problem as such.

>
> However, that's also not something which is known by a different name
> on (say) Linux.
>
>> So, Simon, what should it be called? My understading is that there are
>> rules used by VMS on how to format a vesion number.
>
> VMS isn't the centre of the world anymore Jan-Erik.

What has that to do with internal rules for formatting a version number?

>
> Quite a lot of what VMS is running these days was written on another
> operating system and to avoid confusion on VMS, the VMS name should
> be as close to the real name as possible.

And what if that is simply no technically possible?
How much effort do you think should be put into *this* quite
made-up "problem"?

>
> If VSI make some VMS-specific changes _then_ they can call it an ECO
> or create a VMS format -release. Until then it should be the real
> version of the project that is used.

And what if that simply isn't possible?

>
> In addition to version number confusion, open source projects in
> the past have been renamed for no good reason on VMS (Apache becoming
> CSWS would be one good example). I hope VSI _never_ start doing that.
>
> Simon.
>

On 17/2/22 4:06 am, Mark Daniel wrote:

8< snip 8<>>> I have been building OpenSSL 3.0.0 and 3.0.1 since release
and
>>> currently have an unresolved performance issue open
>>>
>>> https://github.com/openssl/openssl/issues/16552
>>>
>>> As VSI have released
>>>
>>> VSI X86VMS SSL111 V1.1-1MA    Full LP   Install    Val 04-FEB-2022
>>>
>>> only in the last couple of weeks, the announcement seems a little odd.
>>
>> I think the only news here for you is that other people who rely on an
>> installation kit can now find the problems you've already found by
>> building your own from source.
>
> The released kit contains the described performance issue.
>
> https://github.com/openssl/openssl/issues/16552
>
> $ @build_sesola3.com 1
> $ mcr []sesola3
> OpenSSL 1.1.1k  25 Mar 2021
> value: 1
> ELAPSED: 0 00:00:00.20 CPU: 0:00:00.19 BUFIO: 4 DIRIO: 7 FAULTS: 158
> $ @build_sesola3.com 3
> $ mcr []sesola3
> OpenSSL 3.0.1 14 Dec 2021
> value: 1
> ELAPSED: 0 00:00:06.63 CPU: 0:00:06.58 BUFIO: 4 DIRIO: 7 FAULTS: 237
8< snip 8<

The recent OpenSSL 3.0.2 release does not address the issue, in fact
it's gone backwards. Freshly built and executed.

$ mcr []sesola3.EXE
OpenSSL 1.1.1k 25 Mar 2021
value: 1
ELAPSED: 0 00:00:00.19 CPU: 0:00:00.19 BUFIO: 4 DIRIO: 7 FAULTS: 159

$ mcr []sesola3.EXE
OpenSSL 3.0.1 14 Dec 2021
value: 1
ELAPSED: 0 00:00:06.50 CPU: 0:00:06.39 BUFIO: 4 DIRIO: 7 FAULTS: 142

$ mcr []sesola3.EXE
OpenSSL 3.0.2 15 Mar 2022
value: 1
ELAPSED: 0 00:00:08.33 CPU: 0:00:08.29 BUFIO: 4 DIRIO: 7 FAULTS: 155

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

On 17/3/22 12:49 pm, Mark Daniel wrote:
> On 17/2/22 4:06 am, Mark Daniel wrote:
>
> 8< snip 8<>>> I have been building OpenSSL 3.0.0 and 3.0.1 since release
> and
>>>> currently have an unresolved performance issue open
>>>>
>>>> https://github.com/openssl/openssl/issues/16552
>>>>
>>>> As VSI have released
>>>>
>>>> VSI X86VMS SSL111 V1.1-1MA    Full LP   Install    Val 04-FEB-2022
>>>>
>>>> only in the last couple of weeks, the announcement seems a little odd.
>>>
>>> I think the only news here for you is that other people who rely on an
>>> installation kit can now find the problems you've already found by
>>> building your own from source.
>>
>> The released kit contains the described performance issue.
>>
>> https://github.com/openssl/openssl/issues/16552
>>
>> $ @build_sesola3.com 1
>> $ mcr []sesola3
>> OpenSSL 1.1.1k  25 Mar 2021
>> value: 1
>> ELAPSED: 0 00:00:00.20 CPU: 0:00:00.19 BUFIO: 4 DIRIO: 7 FAULTS: 158
>> $ @build_sesola3.com 3
>> $ mcr []sesola3
>> OpenSSL 3.0.1 14 Dec 2021
>> value: 1
>> ELAPSED: 0 00:00:06.63 CPU: 0:00:06.58 BUFIO: 4 DIRIO: 7 FAULTS: 237
> 8< snip 8<
>
> The recent OpenSSL 3.0.2 release does not address the issue, in fact
> it's gone backwards.  Freshly built and executed.
>
> $ mcr []sesola3.EXE
> OpenSSL 1.1.1k 25 Mar 2021
> value: 1
> ELAPSED: 0 00:00:00.19 CPU: 0:00:00.19 BUFIO: 4 DIRIO: 7 FAULTS: 159
>
> $ mcr []sesola3.EXE
> OpenSSL 3.0.1 14 Dec 2021
> value: 1
> ELAPSED: 0 00:00:06.50 CPU: 0:00:06.39 BUFIO: 4 DIRIO: 7 FAULTS: 142
>
> $ mcr []sesola3.EXE
> OpenSSL 3.0.2 15 Mar 2022
> value: 1
> ELAPSED: 0 00:00:08.33 CPU: 0:00:08.29 BUFIO: 4 DIRIO: 7 FAULTS: 155

Quoting from the github thread

https://github.com/openssl/openssl/issues/16552

**** NO CHANGE IN BEHAVIOUR OVER THREE ITERATIONS AND EIGHT MONTHS *****

$ mcr []sesola3
OpenSSL 1.1.1n 15 Mar 2022
value: 1
ELAPSED: 0 00:00:00.23 CPU: 0:00:00.22 BUFIO: 4 DIRIO: 8 FAULTS: 205

$ mcr []sesola3
OpenSSL 3.0.3 3 May 2022
value: 1
ELAPSED: 0 00:00:06.16 CPU: 0:00:06.14 BUFIO: 4 DIRIO: 7 FAULTS: 153

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

On 17/5/22 8:50 pm, Mark Daniel wrote:
> On 17/3/22 12:49 pm, Mark Daniel wrote:
>> On 17/2/22 4:06 am, Mark Daniel wrote:
>>
>> 8< snip 8<>>> I have been building OpenSSL 3.0.0 and 3.0.1 since
>> release and
>>>>> currently have an unresolved performance issue open
>>>>>
>>>>> https://github.com/openssl/openssl/issues/16552
>>>>>
>>>>> As VSI have released
>>>>>
>>>>> VSI X86VMS SSL111 V1.1-1MA    Full LP   Install    Val 04-FEB-2022
>>>>>
>>>>> only in the last couple of weeks, the announcement seems a little odd.
>>>>
>>>> I think the only news here for you is that other people who rely on an
>>>> installation kit can now find the problems you've already found by
>>>> building your own from source.
>>>
>>> The released kit contains the described performance issue.
>>>
>>> https://github.com/openssl/openssl/issues/16552
>>>
>>> $ @build_sesola3.com 1
>>> $ mcr []sesola3
>>> OpenSSL 1.1.1k  25 Mar 2021
>>> value: 1
>>> ELAPSED: 0 00:00:00.20 CPU: 0:00:00.19 BUFIO: 4 DIRIO: 7 FAULTS: 158
>>> $ @build_sesola3.com 3
>>> $ mcr []sesola3
>>> OpenSSL 3.0.1 14 Dec 2021
>>> value: 1
>>> ELAPSED: 0 00:00:06.63 CPU: 0:00:06.58 BUFIO: 4 DIRIO: 7 FAULTS: 237
>> 8< snip 8<
>>
>> The recent OpenSSL 3.0.2 release does not address the issue, in fact
>> it's gone backwards.  Freshly built and executed.
>>
>> $ mcr []sesola3.EXE
>> OpenSSL 1.1.1k 25 Mar 2021
>> value: 1
>> ELAPSED: 0 00:00:00.19 CPU: 0:00:00.19 BUFIO: 4 DIRIO: 7 FAULTS: 159
>>
>> $ mcr []sesola3.EXE
>> OpenSSL 3.0.1 14 Dec 2021
>> value: 1
>> ELAPSED: 0 00:00:06.50 CPU: 0:00:06.39 BUFIO: 4 DIRIO: 7 FAULTS: 142
>>
>> $ mcr []sesola3.EXE
>> OpenSSL 3.0.2 15 Mar 2022
>> value: 1
>> ELAPSED: 0 00:00:08.33 CPU: 0:00:08.29 BUFIO: 4 DIRIO: 7 FAULTS: 155
>
> Quoting from the github thread
>
> https://github.com/openssl/openssl/issues/16552
>
> **** NO CHANGE IN BEHAVIOUR OVER THREE ITERATIONS AND EIGHT MONTHS *****
>
> $ mcr []sesola3
> OpenSSL 1.1.1n 15 Mar 2022
> value: 1
> ELAPSED: 0 00:00:00.23 CPU: 0:00:00.22 BUFIO: 4 DIRIO: 8 FAULTS: 205
>
> $ mcr []sesola3
> OpenSSL 3.0.3 3 May 2022
> value: 1
> ELAPSED: 0 00:00:06.16 CPU: 0:00:06.14 BUFIO: 4 DIRIO: 7 FAULTS: 153

Well it's not going to get any faster. Apparently this overhead is
inherent in OpenSSL 3.0.n

"There were significant fixes in the internal algorithm fetching caching
which impacts certificate decoding. Unfortunately it will be very hard
if not impossible to progress further. The decoding is much more complex
process in openssl-3.0 in comparison to openssl-1.1.1."

The solution for multiple service initializations is (where possible)
instead of SSL_CTX_load_verify_locations() for every SSL context to
perform this for only the first, then SSL_CTX_set1_cert_store() for
subsequent contexts. Thanks Richard Levitte.

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

On 2/15/2022 10:56 PM, Dave Froble wrote:
> Just got an email from VSI, their version of SSL V3 is now available. This
> should be a good thing, bringing some of the latest SSL stuff to VMS.
>
> Some good news.
>
> Now if only a decent TCP/IP was available.
>
> Still, lots of hope for VMS capabilities. Be nice if some new customers came
> along.
>

New from VSI this morning:

VSI SSL111 V0101-1O-1 (Secure Sockets Layer) is based on the OpenSSL V1.1.1o
release from the OpenSSL Group.

Perhaps the bad old days of neglect from HP are now behind us?

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

On 6/28/2022 9:59 AM, Dave Froble wrote:

> New from VSI this morning:
>
> VSI SSL111 V0101-1O-1 (Secure Sockets Layer) is based on the OpenSSL V1.1.1o
> release from the OpenSSL Group.
>
> Perhaps the bad old days of neglect from HP are now behind us?

I do think that we (VSI) have made a much better effort at providing open source
work than HP(E) ever did for VMS.

--
-- Rob