VSI has released 9.2-1

[John Dallman]

* AMD CPUs compatibility
* Initial support for KVM SCSI VirtIO
* Built-in SSL3
* Numerous fixes and improvements to the debugger and dump analyzer
* Many native compilers, such as C, C++, Fortran, and Macro, are now
available for field test. A new set that includes Bliss, COBOL, and
BASIC is expected to become available soon
* Support for newer VMWare hypervisors versions
* Additional entropy collection mechanism

https://vmssoftware.com/about/news/2023-06-15-openvms-v9-2-1-release/

"SSL3" seems to mean OpenSSL v3, not the SSL v3 protocol, which has been
deprecated for years.

John

[Jan-Erik Söderholm]

Nice, good to hear.

Now, my last VMS work seem to have come to an end the 30th June.
So I'll probably never be able to work with this new VMS version.
I was 64 in may -23 so I will probably simple retire...

Ah well, 30+ years with VMS is not that bad anyway... :-)

Jan-Erik.

[Chris Townley]

Any idea if we can upgrade from E9.2-1 or is a reinstall required?

--
Chris

[Chris Townley]

Well at least you can get the community license and play with it.
I lost VMS at work in 2013, and am now retired, but I still enjoy
messing around with VMS

--
Chris

[Robert A. Brooks]

Probably not supported.

Try it and see what happens; when I did that upgrade, it
worked, but I'm pretty sure that we state that upgrading
from a field test version is not supported.

--

--- Rob

[Arne Vajhøj]

On 6/15/2023 6:26 PM, John Dallman wrote:
> * AMD CPUs compatibility
> * Initial support for KVM SCSI VirtIO
> * Built-in SSL3
> * Numerous fixes and improvements to the debugger and dump analyzer
> * Many native compilers, such as C, C++, Fortran, and Macro, are now
> available for field test. A new set that includes Bliss, COBOL, and
> BASIC is expected to become available soon
> * Support for newer VMWare hypervisors versions
> * Additional entropy collection mechanism
>
> https://vmssoftware.com/about/news/2023-06-15-openvms-v9-2-1-release/

Lots of useful stuff (I don't get the entropy thing - sure it is
important, but there are many other things more important IMHO).

I got a notification email with what I think is an important paragraph:

<quote>
OpenVMS on x86 will be available for commercial orders on September 1, 2023.
<quote>

commercial order => revenue !!

> "SSL3" seems to mean OpenSSL v3, not the SSL v3 protocol, which has been
> deprecated for years.

Yes. That is VMS terminology.

Arne

[Chris Townley]

Thanks. I will probably do a fresh install, but also try an upgrade on
my current setup. Aren't VMs great!

--
Chris

[Simon Clubley]

On 2023-06-15, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>
> Now, my last VMS work seem to have come to an end the 30th June.

Sorry to hear that. Are you allowed to say what VMS was replaced with ?

> So I'll probably never be able to work with this new VMS version.
> I was 64 in may -23 so I will probably simple retire...
>

I hope you enjoy your retirement, Jan-Erik.

Simon.

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

[Jan-Erik Söderholm]

Den 2023-06-16 kl. 14:09, skrev Simon Clubley:
> On 2023-06-15, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>
>> Now, my last VMS work seem to have come to an end the 30th June.
>
> Sorry to hear that. Are you allowed to say what VMS was replaced with ?

Why do you think that VMS was replaced? :-)
It is just my agreement that will not be prolonged.

> I hope you enjoy your retirement, Jan-Erik.

Sure. I might spend more time on my other technical hobbies.
Like the 8-bit MCUs from Microchip (PIC processors)...

Thanks för asking anyway... :-)

Jan-Erik.

[Simon Clubley]

On 2023-06-15, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 6/15/2023 6:26 PM, John Dallman wrote:
>> * AMD CPUs compatibility
>> * Initial support for KVM SCSI VirtIO
>> * Built-in SSL3
>> * Numerous fixes and improvements to the debugger and dump analyzer
>> * Many native compilers, such as C, C++, Fortran, and Macro, are now
>> available for field test. A new set that includes Bliss, COBOL, and
>> BASIC is expected to become available soon
>> * Support for newer VMWare hypervisors versions
>> * Additional entropy collection mechanism
>>
>> https://vmssoftware.com/about/news/2023-06-15-openvms-v9-2-1-release/
>
> Lots of useful stuff (I don't get the entropy thing - sure it is
> important, but there are many other things more important IMHO).
>

The entropy stuff is a critical part of getting "the world's most
secure operating system" actually back up the standards of modern
operating systems. Before this, random number generation on VMS
was hopeless from a security point of view.

It's also vital that it's in x86-64 VMS _before_ the first commercial
releases so that software that should be using it can rely on it actually
being present so it does get used in code.

The amount of effort that VSI are spending on this, at this point in time,
is well justified.

> I got a notification email with what I think is an important paragraph:
>

[snip]

The bit that caught my attention was the following:

|Note: With this release, VMS Software announces an end to standard support
|for V9.2. We encourage everyone who runs V9.2 or earlier x86 builds on
|their systems to migrate to V9.2-1 immediately. Only customers with an
|extended engineering support contract with VMS Software Inc. will receive
|support on OpenVMS V9.2. Patches will no longer be developed for V9.2. Bug
|reports will not be investigated until reporters can reproduce the issue on
|V9.2-1.

I hope that isn't going to be the policy when production releases are
produced. There needs to be a support overlap between the prior releases
and the current release for all customers, even when the current release
is a point release.

[John Reagan]

On Friday, June 16, 2023 at 8:21:27 AM UTC-4, Simon Clubley wrote:

>
> The bit that caught my attention was the following:
>
> |Note: With this release, VMS Software announces an end to standard support
> |for V9.2. We encourage everyone who runs V9.2 or earlier x86 builds on
> |their systems to migrate to V9.2-1 immediately. Only customers with an
> |extended engineering support contract with VMS Software Inc. will receive
> |support on OpenVMS V9.2. Patches will no longer be developed for V9.2. Bug
> |reports will not be investigated until reporters can reproduce the issue on
> |V9.2-1.
>
> I hope that isn't going to be the policy when production releases are
> produced. There needs to be a support overlap between the prior releases
> and the current release for all customers, even when the current release
> is a point release.
> Simon.
>

My view is this is a one time thing. V9.2 and V9.2update2 have enough sharp edges
that we really REALLY REALLY! want sites to upgrade.

For example, I'm about to refresh the native compiler FT kits on the portal. Those were built/linked
on V9.2update2. Going forward, I'll switch to build/link against V9.2-1. I'll probably stick
with using V9.2-1 headers/libraries even for future kits to ensure backwards compatibility. I won't
bump forward for the rest of the year at least (unless something forces me).

[Single Stage to Orbit]

On Fri, 2023-06-16 at 00:15 +0100, Chris Townley wrote:
> > Try it and see what happens; when I did that upgrade, it
> > worked, but I'm pretty sure that we state that upgrading
> > from a field test version is not supported.
> >
>
> Thanks. I will probably do a fresh install, but also try an upgrade
> on my current setup. Aren't VMs great!

Same here, just took a VM snapshot ready to revert should the upgrade
fail. In the event of failure, I plan to do a fresh install and cluster
it to the older VM and copy my files across.
--
Tactical Nuclear Kittens

[David Jones]

> --- Rob

I upgraded from the field test and the only glitch seems to be that SYSINIT
complained about not finding <SYS$LDR>NET$MESSAGE.EXE. The field
test originally had DECNET_PLUS, but I uninstalled it and replaced it with
DECNET_PHASE_IV. The upgrade said it would replace the Phase IV install
with a new Phase IV, so I don't know why it was looking for a Phase V file.

I manually extracted net$message.exe from the decnet_plus kit on the ISO,
built a new memory disk image with sys$md.com, and the error messages
ceased.

I re-built SQLite and ran its speedtest program. The CPU time was pretty much
exactly half the previous run on 28-MAY-2023. The benchmark is I/O bound, so
the I/O processing overhead appears to be much improved.

Running a re-built Bytemark program under the new release is a wash, speedwise.

[Arne Vajhøj]

On 6/16/2023 7:05 PM, David Jones wrote:
> I re-built SQLite and ran its speedtest program. The CPU time was pretty much
> exactly half the previous run on 28-MAY-2023. The benchmark is I/O bound, so
> the I/O processing overhead appears to be much improved.

Nice.

> Running a re-built Bytemark program under the new release is a wash, speedwise.

That is CPU bound right?

So it is sort of expected that it depends more on compiler
than on OS.

Arne

[Arne Vajhøj]

On 6/16/2023 8:21 AM, Simon Clubley wrote:
> On 2023-06-15, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> Lots of useful stuff (I don't get the entropy thing - sure it is
>> important, but there are many other things more important IMHO).
>
> The entropy stuff is a critical part of getting "the world's most
> secure operating system" actually back up the standards of modern
> operating systems. Before this, random number generation on VMS
> was hopeless from a security point of view.
>
> It's also vital that it's in x86-64 VMS _before_ the first commercial
> releases so that software that should be using it can rely on it actually
> being present so it does get used in code.
>
> The amount of effort that VSI are spending on this, at this point in time,
> is well justified.

How many more VMS licenses will VSI sell because of that feature?

My guess: zero.

The OpenSSL maintainers may be happy that they get better entropy
with less code.

The security interested people may think it is nice to get
better entropy.

But when it comes to sales I see zero extra sale.

Sale will be driven by other things:
* getting the last traditional compilers available (Cobol and Basic)
* getting Java and Python available
* making sure Oracle get Rdb available
* convince Synergex to get DBL available
* getting all other platform-software currently available
on Alpha and/or Itanium available
* get some new stuff not currently available
on Alpha and/or Itanium (like RabbitMQ, RocksDB etc.)
available
* getting the OS build with native optimizing
compilers
* enhance RTL to support some of all the "newer" stuff
(like HTTP, JSON etc.)
* get a modern Fortran compiler available
* etc.

Arne

[Crni Mrki]

Hi.
How and from which source are you installed SQLite?
Thank you.

[Craig A. Berry]

On 6/17/23 2:55 PM, Crni Mrki wrote:
> Hi.
> How and from which source are you installed SQLite?
> Thank you.

He maintains his own port. I think it's this one:

https://sourceforge.net/projects/vms-ports/files/SQLITE3/

[David Jones]

On Saturday, June 17, 2023 at 4:18:26 PM UTC-4, Craig A. Berry wrote:
> On 6/17/23 2:55 PM, Crni Mrki wrote:
> > Hi.
> > How and from which source are you installed SQLite?
> > Thank you.
> He maintains his own port. I think it's this one:
>
> https://sourceforge.net/projects/vms-ports/files/SQLITE3/

Yes, that's the one. I started 8 years ago with 3.8.11 and now they are
at 3.42.0. They used to have a lot more 3.n.x+1 releases before going
to the 3.n+1.0 update. The additional features have ballooned the core
library source file by ~50% while the command line tool (shell.c) is over
5 times bigger.

Since the VMS-specific stuff is mostly isolated in a separate VFS
implementation, the only changes usually needed for a new SQLite
release are updates to the symbol vectors and image IDs.

[kemain...@gmail.com]

Might not apply here, but in other vendors FT versions of code, it was (is?)
common to leave debug code in for better support in resolving functionality
issues until the release became official. This would typically make FT
versions slower than the final release.

Walk down memory lane - Microsoft left the debug code in PROD versions of
Alpha Windows NT Office and the Alpha Windows benchmarks were still
significantly better than the x86 versions of the time.

We (Digital NT Wizards program at DEC) never could convince MS to release
Prod Alpha NT versions without the debug code.

Ah well .. and the rest is history.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com






--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

[Simon Clubley]

On 2023-06-16, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 6/16/2023 8:21 AM, Simon Clubley wrote:
>> On 2023-06-15, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>> Lots of useful stuff (I don't get the entropy thing - sure it is
>>> important, but there are many other things more important IMHO).
>>
>> The entropy stuff is a critical part of getting "the world's most
>> secure operating system" actually back up the standards of modern
>> operating systems. Before this, random number generation on VMS
>> was hopeless from a security point of view.
>>
>> It's also vital that it's in x86-64 VMS _before_ the first commercial
>> releases so that software that should be using it can rely on it actually
>> being present so it does get used in code.
>>
>> The amount of effort that VSI are spending on this, at this point in time,
>> is well justified.
>
> How many more VMS licenses will VSI sell because of that feature?
>
> My guess: zero.
>

This is not about selling new systems. This is about being a part of
work to make sure that existing sites don't get forced to move away
from VMS because VMS no longer meets the industry standard security standards.

You can have a nice piece of software running on VMS, but that's no
good unless those VMS systems are secure by modern standards. VMS systems
_WILL_ be dropped in many areas if they are regarded as no longer being
secure by today's standards.

> The OpenSSL maintainers may be happy that they get better entropy
> with less code.
>

Replace "better entropy" with "now-acceptable entropy". The new entropy
engine running within the kernel offers a brand-new capability for VMS
that is considered to be standard elsewhere.

To put this another way, the previous solutions for generating entropy
within user mode that I am aware of were not suitable by today's standards.

Look at previous discussions here about trying to find sources to get
a bit more entropy while running in user mode.

> The security interested people may think it is nice to get
> better entropy.
>
> But when it comes to sales I see zero extra sale.
>

I am not exactly a fan of some things that VSI are doing :-), but this
is one thing I _strongly_ agree with and it was a pleasant surprise to
see VSI spending the time to implement this. Well done to VSI.

Maybe I am seeing something here you are missing ?

[Pizza RAC]

On Thursday, June 15, 2023 at 6:43:08 PM UTC-4, Jan-Erik Söderholm wrote:
>
> Now, my last VMS work seem to have come to an end the 30th June.
> So I'll probably never be able to work with this new VMS version.
> I was 64 in may -23 so I will probably simple retire...
>
> Ah well, 30+ years with VMS is not that bad anyway... :-)
>
> Jan-Erik.

come to the U.S. with Biden in charge no one will ever be able to retire :)

[Johnny Billquist]

Yeah. I guess that concept only exist in socialist countries, like Sweden.

Johnny

[Robert A. Brooks]

If only the data backed up that baseless statement that the economy suffers
under a Democrat in the White House.

https://www.nytimes.com/2021/02/02/opinion/sunday/democrats-economy.html

https://en.wikipedia.org/wiki/U.S._economic_performance_under_Democratic_and_Republican_presidents

https://www.thebalancemoney.com/democrats-vs-republicans-which-is-better-for-the-economy-4771839

https://newrepublic.com/article/166274/economy-record-republicans-vs-democrats

https://www.newsweek.com/us-jobs-income-gdp-growth-startlingly-higher-under-democratic-presidents-analysis-1566313



--

--- Rob

[Simon Clubley]

On 2023-06-19, Pizza RAC <pizzara...@gmail.com> wrote:
>
> come to the U.S. with Biden in charge no one will ever be able to retire :)

You are delusional if you think only one party is responsible.

Looking at your country from Europe, I am filled with a mixture of
horror and sadness at what you are doing to yourselves.

The Democrats are destroying your social fabric (look at your major
cities in general and San Francisco in particular).

The Republicans are destroying your business and intellectual fabric
in the name of short term profit and the Democrats have no interest
in reversing that.

Both parties have no interest in getting your debt under control and
only offer short-term solutions that put off the day of reckoning and
will make the collapse when it comes just more massive than it would
be if it happened today.

You are now so weak and cripplied by your short-term thinking, you can
only threaten China (and bully your traditional allies) with sanctions
to try and stop China becoming a bigger competitor, instead of competing
with them as a business rival.

The US is currently in the early stages of the modern day version of
the fall of the Roman Empire.

[Simon Clubley]

That's all well and good Rob, but what happens when China grows a bit
stronger and then decides to show you who the boss is by cutting off
your imports ?

Outside of that, what happens when changing world relationships result
in a decline of the dollar as a reserve currency ? That's where the US
currently gets most of its bullying power from.

In the old days, your military had to worry about protecting your
industrial base from an enemy. These days, all your enemy needs to
do is to threaten to stop sending you the goods they now produce
for you.

Unlike you, China has a strong industrial base, and so is far better
placed to handle that situation than you are. They don't need to
produce the best product on the market to survive the destruction of
the US economy (if they decide to do that), they just need to produce
a product that is good enough.

Think about that if they decide to destroy the Taiwan fabs. They will
survive that (even though they will be badly damaged initially), but
your economy will not.

Both your parties are equally to blame for the situation you are in
and it is a very sad and worrying sight to see.

[Johnny Billquist]

On 2023-06-19 19:27, Simon Clubley wrote:
> On 2023-06-19, Pizza RAC <pizzara...@gmail.com> wrote:
>>
>> come to the U.S. with Biden in charge no one will ever be able to retire :)
>
> You are delusional if you think only one party is responsible.
>
> Looking at your country from Europe, I am filled with a mixture of
> horror and sadness at what you are doing to yourselves.
>
> The Democrats are destroying your social fabric (look at your major
> cities in general and San Francisco in particular).
>
> The Republicans are destroying your business and intellectual fabric
> in the name of short term profit and the Democrats have no interest
> in reversing that.
>
> Both parties have no interest in getting your debt under control and
> only offer short-term solutions that put off the day of reckoning and
> will make the collapse when it comes just more massive than it would
> be if it happened today.
>
> You are now so weak and cripplied by your short-term thinking, you can
> only threaten China (and bully your traditional allies) with sanctions
> to try and stop China becoming a bigger competitor, instead of competing
> with them as a business rival.
>
> The US is currently in the early stages of the modern day version of
> the fall of the Roman Empire.

I really shouldn't be adding posts to this stupid topic.

Competing with China is nothing like a business rivalry. At some point
this needs to be addressed properly.

https://youtu.be/0xlq4WSpUH8

Johnny

[bill]

I was forced to retire at 61 from the Army and at 65 from the
University. I would gladly go back to work even with my current
health problems because being retired sucks.

Retirement in the US isn't going away. Finding a decent job if
your over 60 (or in many cases even 50) is much more of a problem.

bill

[Dave Froble]

On 6/19/2023 11:57 AM, Johnny Billquist wrote:

I think that is also possible in a possibly non-socialist country, but it sure
isn't helped by fascist Republicans, and the US seems to growing some of them.

I know this isn't the venue for politics. But I grow tired of seeing the same
old thing over and over again. One would think that supposedly intellegent
humans would sooner or later learn. But apparently not.

In the 1930s a great evil arose. Many bad things happened. And now, 90 years
later, it's happening again.

Racism in the US and elsewhere.

We see attempts to silence political opponents in other countries, but that
would never happen in the USA, right? Too bad nobody mentioned that to the
"dangerous" idiot in Florida.

I guess some in Israel feel it's their turn, and are doing to the Palestinians
what the Nazis did to them. Wonder when they will schedule their "crystal night".

But the biggest thing I'm really pissed off about, "find me 11,800 votes".

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

On 6/19/2023 12:33 PM, Robert A. Brooks wrote:
> On 6/19/2023 10:41 AM, Pizza RAC wrote:
>> On Thursday, June 15, 2023 at 6:43:08 PM UTC-4, Jan-Erik Söderholm wrote:
>>>
>>> Now, my last VMS work seem to have come to an end the 30th June.
>>> So I'll probably never be able to work with this new VMS version.
>>> I was 64 in may -23 so I will probably simple retire...
>>>
>>> Ah well, 30+ years with VMS is not that bad anyway... :-)
>>>
>>> Jan-Erik.
>>
>> come to the U.S. with Biden in charge no one will ever be able to retire :)
>
> If only the data backed up that baseless statement that the economy suffers
> under a Democrat in the White House.

I will agree with that, to a point. What really amazes me is that with 330
million or so people, we cannot find even one better than the last 2. And it's
looking worse each day.

Just remember, we got Trump because the Democrats were leaning way too far left.
He is their fault. Can't we find anyone in the middle.

[kemain...@gmail.com]

> -----Original Message-----
> From: Info-vax <info-vax...@rbnsn.com> On Behalf Of bill via Info-vax
> Sent: Monday, June 19, 2023 3:40 PM
> To: info...@rbnsn.com
> Cc: bill <bill.gu...@gmail.com>
> Subject: Re: [Info-vax] VSI has released 9.2-1
>

I would tend to agree, but the challenge is that to many people think 60-65 means your work career(s) are over.

If one works 30 years and decides to retire at age 60-65, then given the additional longevity of relatively health people's age expectations, the question needs to be asked "what are you going to do with your remaining 25-30 years?"

Playing golf is only an answer if you are an avid golfer and can afford the high expenses associated with golf. Hobbies? Sure, but every day?

Imho, after 60, you are only getting started and one should take this age to determine what you want to take on as a second career or job that is perhaps based on something you really like to do - even if it means volunteering. Joining a gym is a great activity for all of us who have avoided this for many years. Private consulting using years of experience is an option for some - especially if willing to get new certs like VMware, network, security related.

One thing for sure - everyone needs a reason to get out of bed in the morning and have activities on your daily schedule that you are looking forward to doing.

😊

[Arne Vajhøj]

On 6/19/2023 5:35 PM, Dave Froble wrote:
> I will agree with that, to a point.  What really amazes me is that with
> 330 million or so people, we cannot find even one better than the last
> 2.  And it's looking worse each day.
>
> Just remember, we got Trump because the Democrats were leaning way too
> far left.  He is their fault.  Can't we find anyone in the middle.

You can probably find some people in the middle.

But getting them elected may be difficult.

The US inherited the winner takes all from the British.
Most votes in a house district get the seat - other votes
doesn't count. Most votes in the state for senate get the
seat - other votes doesn't count. Most votes in the state
for president (for most states) get all electors. That
system tend to lead to a two party system. Small parties
do not have many chances.

On top of that the US got the public primaries. To
become a candidate for one of the two parties the
potential candidates need to get most votes from
the registered voters for that party (if closed primary,
which is still very common). That favors candidates
that are in the middle of the party's registered voters
over candidates that are in middle of all voters. It tend
to lead to more extreme candidates.

So the system push for a two party system with extreme
candidates.

In many countries in continental Europe there is a
totally different system. Seats in parliament is distributed
to parties according to their share of votes. And at least
some countries got low minimum to get seats.

That makes it easy for new small parties to get in. So it is not
unusual with 5-10 parties in parliament.

And the prime minister is elected by parliament. And a typical
parliament looks like:

right parties
right-center parties
center parties
left-center parties
left parties

and it very often end up that the center parties control who
become prime minister.

And that tend to result in center oriented prime ministers.
Tradition is not for the center parties to get the prime
minister role for themselves, instead they pick someone from
either right-center or left-center that is willing to compromise
over the middle.

That system also has its drawbacks. It often frustrates the
voters that there are so little differences between how
different prime ministers actually govern.

But people in the political center get elected. Almost
every time!

Arne

[Arne Vajhøj]

On 6/19/2023 1:43 PM, Simon Clubley wrote:
> That's all well and good Rob, but what happens when China grows a bit
> stronger and then decides to show you who the boss is by cutting off
> your imports ?

Americans can no longer get cheap furniture, cheap tools and all
sorts of cheap junk from China.

They will survive.

> Outside of that, what happens when changing world relationships result
> in a decline of the dollar as a reserve currency ?

That would fix the US trade deficit. The dollar would drop and
that would make foreign goods in the US more expensive and
US goods abroad cheaper.

There is probably a reason why China has fought so hard
to keep its currency low to the dollar.

> That's where the US
> currently gets most of its bullying power from.

It doesn't really give any power.

> In the old days, your military had to worry about protecting your
> industrial base from an enemy. These days, all your enemy needs to
> do is to threaten to stop sending you the goods they now produce
> for you.

If the goods are critical yes.

But China export is mostly consumer stuff.

> Unlike you, China has a strong industrial base, and so is far better
> placed to handle that situation than you are. They don't need to
> produce the best product on the market to survive the destruction of
> the US economy (if they decide to do that), they just need to produce
> a product that is good enough.

China is relative self sufficient. But there are a few things
they need. Including oil.

> Think about that if they decide to destroy the Taiwan fabs. They will
> survive that (even though they will be badly damaged initially), but
> your economy will not.

That is a risk.

But both the US and to some extent Europe are building
semi-conductor fabs to counter that scenario.

Arne

[Arne Vajhøj]

On 6/19/2023 1:27 PM, Simon Clubley wrote:
> You are now so weak and cripplied by your short-term thinking, you can
> only threaten China (and bully your traditional allies) with sanctions
> to try and stop China becoming a bigger competitor,

The US sanctions Russia, Iran, North Korea etc..

The US is starting to put some restrictions that probably
can be compared to sanctions on China as well.

I am pretty sure that US has not put any sanctions on its
traditional allies.

> instead of competing
> with them as a business rival.

So should the US back in 1940 had ditched the UK and
"competed with Germany as business rivals" or during the
cold war ditched Europe and "competed with USSR
as business rivals"?

I don't think so.

And why should the US do so with Russia or China today??

> The US is currently in the early stages of the modern day version of
> the fall of the Roman Empire.

Maybe.

But other countries seems closer.

Arne

[Arne Vajhøj]

On 6/19/2023 8:20 AM, Simon Clubley wrote:
> On 2023-06-16, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 6/16/2023 8:21 AM, Simon Clubley wrote:
>>> On 2023-06-15, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>> Lots of useful stuff (I don't get the entropy thing - sure it is
>>>> important, but there are many other things more important IMHO).
>>>
>>> The entropy stuff is a critical part of getting "the world's most
>>> secure operating system" actually back up the standards of modern
>>> operating systems. Before this, random number generation on VMS
>>> was hopeless from a security point of view.
>>>
>>> It's also vital that it's in x86-64 VMS _before_ the first commercial
>>> releases so that software that should be using it can rely on it actually
>>> being present so it does get used in code.
>>>
>>> The amount of effort that VSI are spending on this, at this point in time,
>>> is well justified.
>>
>> How many more VMS licenses will VSI sell because of that feature?
>>
>> My guess: zero.
>
> This is not about selling new systems. This is about being a part of
> work to make sure that existing sites don't get forced to move away
> from VMS because VMS no longer meets the industry standard security standards.
>
> You can have a nice piece of software running on VMS, but that's no
> good unless those VMS systems are secure by modern standards. VMS systems
> _WILL_ be dropped in many areas if they are regarded as no longer being
> secure by today's standards.

Which security standards mandate direct support for entropy generation
in the OS?

>> The OpenSSL maintainers may be happy that they get better entropy
>> with less code.
>
> Replace "better entropy" with "now-acceptable entropy".

Who is saying that current OpenSSL way is no longer acceptable?

> The new entropy
> engine running within the kernel offers a brand-new capability for VMS
> that is considered to be standard elsewhere.
>
> To put this another way, the previous solutions for generating entropy
> within user mode that I am aware of were not suitable by today's standards.

So you say.

I would really like to get some sources.

> Look at previous discussions here about trying to find sources to get
> a bit more entropy while running in user mode.

The topic has been discussed.

And the maintainer of the OpenSSL VMS code has indeed asked
some questions.

But I do not remember him saying that the current code was
not acceptable.

> Maybe I am seeing something here you are missing ?

Possible. I miss a lot of things. So just post links
to the standards, best practice documents etc. specifying
the need for direct OS entropy.

Arne

[Dave Froble]

Simon sez ...

:-)

>>> The OpenSSL maintainers may be happy that they get better entropy
>>> with less code.
>>
>> Replace "better entropy" with "now-acceptable entropy".
>
> Who is saying that current OpenSSL way is no longer acceptable?

Simon sez ...

>> The new entropy
>> engine running within the kernel offers a brand-new capability for VMS
>> that is considered to be standard elsewhere.
>>
>> To put this another way, the previous solutions for generating entropy
>> within user mode that I am aware of were not suitable by today's standards.
>
> So you say.
>
> I would really like to get some sources.
>
>> Look at previous discussions here about trying to find sources to get
>> a bit more entropy while running in user mode.
>
> The topic has been discussed.
>
> And the maintainer of the OpenSSL VMS code has indeed asked
> some questions.
>
> But I do not remember him saying that the current code was
> not acceptable.
>
>> Maybe I am seeing something here you are missing ?
>
> Possible. I miss a lot of things. So just post links
> to the standards, best practice documents etc. specifying
> the need for direct OS entropy.

People who count for encryption to provide protection don't really care all that
much. Do enough to check the appropriate box, then not their problem.

People who really care about security of course may use SSL, but then what
happens when the encryption is broken? The user's data is available to the
hackers. But what if the app developers insured that the data, if encryption is
defeated, doesn't really mean anything to the hackers. Some custom stuff in
addition to SSL and such. Yeah, even then, some hacker might figure out the
data. But isn't it better to make it as tough for the hacker as one can?

Now I'll hear from some "you got to use standards". I'd ask "why?" The problem
with standards is, everybody knows them.

[Dave Froble]

Go flying?

> Playing golf is only an answer if you are an avid golfer and can afford the
> high expenses associated with golf. Hobbies? Sure, but every day?

Re-build a classic aircraft?

> Imho, after 60, you are only getting started and one should take this age to
> determine what you want to take on as a second career or job that is perhaps
> based on something you really like to do - even if it means volunteering.
> Joining a gym is a great activity for all of us who have avoided this for many
> years. Private consulting using years of experience is an option for some -
> especially if willing to get new certs like VMware, network, security related.
>
> One thing for sure - everyone needs a reason to get out of bed in the
> morning
> and have activities on your daily schedule that you are looking forward to doing.
>

There is the chance to sleep in late now and then ...

I sort of enjoy having less demands on my time. Can't dodge them all.

Wife: Go to the store and get ...

Daughter: When are you going to take care of that tree branch ...

Kids are gone, grandkids are gone, guess who gets to mow 10+ acres ...

As busy now as ever.

[Simon Clubley]

On 2023-06-19, Johnny Billquist <b...@softjar.se> wrote:
>
> I really shouldn't be adding posts to this stupid topic.
>
> Competing with China is nothing like a business rivalry. At some point
> this needs to be addressed properly.
>
> https://youtu.be/0xlq4WSpUH8
>

How does that incident compare to what the US are doing to everyone else ?

[Simon Clubley]

On 2023-06-19, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 6/19/2023 8:20 AM, Simon Clubley wrote:
>>
>> This is not about selling new systems. This is about being a part of
>> work to make sure that existing sites don't get forced to move away
>> from VMS because VMS no longer meets the industry standard security standards.
>>
>> You can have a nice piece of software running on VMS, but that's no
>> good unless those VMS systems are secure by modern standards. VMS systems
>> _WILL_ be dropped in many areas if they are regarded as no longer being
>> secure by today's standards.
>
> Which security standards mandate direct support for entropy generation
> in the OS?
>

You can also do it using external devices, which has been the only option
for VMS until now, because the goal is to be able to meet a set of
specified standards.

>>> The OpenSSL maintainers may be happy that they get better entropy
>>> with less code.
>>
>> Replace "better entropy" with "now-acceptable entropy".
>
> Who is saying that current OpenSSL way is no longer acceptable?
>

OpenSSL on VMS, not OpenSSL in general.

>> The new entropy
>> engine running within the kernel offers a brand-new capability for VMS
>> that is considered to be standard elsewhere.
>>
>> To put this another way, the previous solutions for generating entropy
>> within user mode that I am aware of were not suitable by today's standards.
>
> So you say.
>
> I would really like to get some sources.
>

Fair enough. The current standards are the NIST SP 800-90 series of
standards:

https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final
https://csrc.nist.gov/publications/detail/sp/800-90b/final
https://csrc.nist.gov/publications/detail/sp/800-90c/draft

In each case, the actual standard can be found in the top right of the
page, under the "Publication:" section.

However, since they can be hard to follow in certain parts, here is
a much more readable introduction-level document from Red Hat discussing
these issues from a Linux point of view:

https://www.redhat.com/en/blog/understanding-random-number-generators-and-their-limitations-linux

Look at the sources Linux is using for the entropy pool. You can't duplicate
that in user mode without access to a kernel module (and underlying OS
support) to help you.

>> Look at previous discussions here about trying to find sources to get
>> a bit more entropy while running in user mode.
>
> The topic has been discussed.
>
> And the maintainer of the OpenSSL VMS code has indeed asked
> some questions.
>
> But I do not remember him saying that the current code was
> not acceptable.
>
> > Maybe I am seeing something here you are missing ?
>
> Possible. I miss a lot of things. So just post links
> to the standards, best practice documents etc. specifying
> the need for direct OS entropy.
>

The NIST and earlier standards specify a series of requirements. You can't
meet those requirements in a software-based solution without kernel support
to get direct access to the entropy sources.

[Simon Clubley]

On 2023-06-19, Dave Froble <da...@tsoft-inc.com> wrote:
>
> I will agree with that, to a point. What really amazes me is that with 330
> million or so people, we cannot find even one better than the last 2. And it's
> looking worse each day.
>
> Just remember, we got Trump because the Democrats were leaning way too far left.
> He is their fault. Can't we find anyone in the middle.
>

The current major candidates in both parties are a joke. :-(

Democrats:
1) a guy can't even remember his lines and calls out to dead people or
2) a guy who is a major vaccine denier (with apparently currently over
20% of the Democrat vote).

Republicans:
3) a guy who looks like he will be leading the US from jail if elected or
4) a guy who seems to be a more grown-up version of Trump whose campaign
has fallen completely flat.

[Simon Clubley]

On 2023-06-19, Arne Vajhøj <ar...@vajhoej.dk> wrote:

> On 6/19/2023 1:43 PM, Simon Clubley wrote:
>> That's all well and good Rob, but what happens when China grows a bit
>> stronger and then decides to show you who the boss is by cutting off
>> your imports ?
>
> Americans can no longer get cheap furniture, cheap tools and all
> sorts of cheap junk from China.
>
> They will survive.
>

They also can't get all the medical supplies and critical equipment
now produced in China, and which would need a _serious_ amount of time
to rebuild that infrastructure within the US.

Are you sure about the above ?

>> That's where the US
>> currently gets most of its bullying power from.
>
> It doesn't really give any power.
>

Yes, it does. The US is currently using its power to force its allies
to also impose sanctions. In a more general way, the US imposes a threat
of being frozen out of the US banking system to get its way.

>> In the old days, your military had to worry about protecting your
>> industrial base from an enemy. These days, all your enemy needs to
>> do is to threaten to stop sending you the goods they now produce
>> for you.
>
> If the goods are critical yes.
>
> But China export is mostly consumer stuff.
>

So what happened to the supply chains during Covid was an illusion ?
(And that was with China still trying to meet its obligations!)

BTW, where did the Covid-specific medical supplies come from ?

[Dave Froble]

On 6/20/2023 8:51 AM, Simon Clubley wrote:
> On 2023-06-19, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 6/19/2023 1:43 PM, Simon Clubley wrote:
>>> That's all well and good Rob, but what happens when China grows a bit
>>> stronger and then decides to show you who the boss is by cutting off
>>> your imports ?
>>
>> Americans can no longer get cheap furniture, cheap tools and all
>> sorts of cheap junk from China.
>>
>> They will survive.
>>
>
> They also can't get all the medical supplies and critical equipment
> now produced in China, and which would need a _serious_ amount of time
> to rebuild that infrastructure within the US.

It is my understanding that much of the medical stuff comes from India and other
places. Don't know how much comes from China.

> Are you sure about the above ?

Yes, we would survive. We'd learn the lesson to not be so dependent on others,
but, we'd just have to "onshore" what we'd let go of in the past.

>>> That's where the US
>>> currently gets most of its bullying power from.
>>
>> It doesn't really give any power.
>>
>
> Yes, it does. The US is currently using its power to force its allies
> to also impose sanctions. In a more general way, the US imposes a threat
> of being frozen out of the US banking system to get its way.

True.

>>> In the old days, your military had to worry about protecting your
>>> industrial base from an enemy. These days, all your enemy needs to
>>> do is to threaten to stop sending you the goods they now produce
>>> for you.
>>
>> If the goods are critical yes.
>>
>> But China export is mostly consumer stuff.
>>
>
> So what happened to the supply chains during Covid was an illusion ?
> (And that was with China still trying to meet its obligations!)

It's a bit complex. Consider two people in a rubber life raft. They don't get
along, so, one decides to sink the raft, to harm the other. The first person is
also in the life raft. Both would suffer.

[Johnny Billquist]

On 2023-06-20 14:06, Simon Clubley wrote:
> On 2023-06-19, Johnny Billquist <b...@softjar.se> wrote:
>>
>> I really shouldn't be adding posts to this stupid topic.
>>
>> Competing with China is nothing like a business rivalry. At some point
>> this needs to be addressed properly.
>>
>> https://youtu.be/0xlq4WSpUH8
>>
>
> How does that incident compare to what the US are doing to everyone else ?

Can you provide some facts instead of sweeping generalizations here, please?

You just claiming something is so don't necessarily make it true.
Hard to have a discussion comparing two things when one is a concrete
incident, and the other a sweeping generalization and opinion.

And just for the record, I personally have infinite more trust in the US
than China (which sortof comes obviously from the trust in China being
0, and the trust in the US being non-zero).

Johnny

[Single Stage to Orbit]

On Tue, 2023-06-20 at 09:18 -0400, Dave Froble wrote:
> Yes, we would survive.  We'd learn the lesson to not be so dependent
> on others, but, we'd just have to "onshore" what we'd let go of in
> the past.

Greed. I call it pure unalternated greed on the part of Wall Street.
Squeezing us dry for profit. The UK is already hurtling along the same
path that the US has already trod upon. Western Europe isn't that
stupid, well mostly.
--
Tactical Nuclear Kittens

[Johnny Billquist]

On 2023-06-20 14:51, Simon Clubley wrote:
> On 2023-06-19, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 6/19/2023 1:43 PM, Simon Clubley wrote:
>>> That's all well and good Rob, but what happens when China grows a bit
>>> stronger and then decides to show you who the boss is by cutting off
>>> your imports ?
>>
>> Americans can no longer get cheap furniture, cheap tools and all
>> sorts of cheap junk from China.
>>
>> They will survive.
>>
>
> They also can't get all the medical supplies and critical equipment
> now produced in China, and which would need a _serious_ amount of time
> to rebuild that infrastructure within the US.

Very little of that, I'd say.

> Are you sure about the above ?

I would definitely agree with Arne here.

>>> That's where the US
>>> currently gets most of its bullying power from.
>>
>> It doesn't really give any power.
>>
>
> Yes, it does. The US is currently using its power to force its allies
> to also impose sanctions. In a more general way, the US imposes a threat
> of being frozen out of the US banking system to get its way.

??? Sanctions on Russia have not been forced on by the US. You might
better blame the UK in that case, which has been leading this more. Or a
bunch of former eastern european countries, who have various past bad
experiences with Russia, and know all too well what it's all about.

What other contries are there sanctions against? North Korea. Seriously
- you think that the US bullied other countries into those sanctions?
Syria? Iran?

What planet are you living on?

>>> In the old days, your military had to worry about protecting your
>>> industrial base from an enemy. These days, all your enemy needs to
>>> do is to threaten to stop sending you the goods they now produce
>>> for you.
>>
>> If the goods are critical yes.
>>
>> But China export is mostly consumer stuff.
>>
>
> So what happened to the supply chains during Covid was an illusion ?
> (And that was with China still trying to meet its obligations!)

There has been a major issue with semiconductor supplies since Covid
started. But as have been pointed out, these are not very China specific
in any sense. Basically, production and transports in general have been
hit, causing chain effects. Not much tied to China at all.

> BTW, where did the Covid-specific medical supplies come from ?

Are you talking about all the face masks that were substandard and not
usable? Yeah, there were a whole bunch of those delivered to Sweden from
China. I don't think not having them delivered would have made things worse.

Johnny

[Dave Froble]

It's a rather complex situation.

"Greed" can be helpful, if it causes good things to happen. But it will usually
be harmful to some. Case, the take over of North America, good for some, but
not so good for the native americans.

I consider myself a bit conservative, but, nothing like the current definition
of conservative in the US. I don't think I'm a socialist, but, I think
government should "do the right thing" without resorting to names. Perhaps it's
the names that are the problem.

For example, Bernie Sanders, who called himself a "socialist" and tried to run
for president. Now, I'm betting over 90% of voters in the US don't understand
just what socialism might be, but, I'm sure over 90% of voters in the US "know"
that socialism is BAD. Why couldn't the idiot just say what he is for, things
that I'd approve of, and ignore the name. Like shooting yourself in the foot,
and taking out the rest of yourself.

Then there is "woke", whatever that is.

Maybe the best thing to do is nuke the Harvard Business School? And declare
open season on lawyers?

[Dave Froble]

It's so much fun to pick on Simon ...

:-)

As for semiconductors and the auto industry, the auto industry caused that
problem by reducing their orders. Of course then the semiconductor industry
took other orders.

As for Covid-19, where did the vaccine research and production occur? US?
Britain? Germany?

[bill]

On 6/20/2023 11:53 AM, Dave Froble wrote:
> >
> Maybe the best thing to do is nuke the Harvard Business School?  And
> declare open season on lawyers?
>

Been there, done that.

"First we kill all the lawyers." : Shakespeare

We have a commercial running now where a lawyer says the biggest
complaint against lawyers is that they don't return phone calls.
Funny, I always thought the biggest complaint against lawyers was
that they were scum sucking bottom feeders.

bill

[Chris Townley]

I recall the sad story of an airliner full of lawyers that crashed, and
all were killed.
Everybody felt sad for the pilot
--
Chris

[Simon Clubley]

On 2023-06-20, Johnny Billquist <b...@softjar.se> wrote:
> On 2023-06-20 14:51, Simon Clubley wrote:
>>
>> Yes, it does. The US is currently using its power to force its allies
>> to also impose sanctions. In a more general way, the US imposes a threat
>> of being frozen out of the US banking system to get its way.
>
> ??? Sanctions on Russia have not been forced on by the US. You might
> better blame the UK in that case, which has been leading this more. Or a
> bunch of former eastern european countries, who have various past bad
> experiences with Russia, and know all too well what it's all about.
>
> What other contries are there sanctions against? North Korea. Seriously
> - you think that the US bullied other countries into those sanctions?
> Syria? Iran?
>

China. Please research the situation with ASML and what the US is doing
to a European company as one example.

That will cause short-term pain to China, but in the long term, as they
are forced to invent a homegrown solution, that will backfire big time
as it means there's one less Western piece of technology they rely on.

That's also going to cause long-term pain for ASML as their currently
world-leading technology ends up facing a Chinese competitor.

>> BTW, where did the Covid-specific medical supplies come from ?
>
> Are you talking about all the face masks that were substandard and not
> usable? Yeah, there were a whole bunch of those delivered to Sweden from
> China. I don't think not having them delivered would have made things worse.
>

Not just those. The Covid tests I had to take were also marked as coming
from China. Apparently, we couldn't produce something like that, in the
timescales required, ourselves.

[Simon Clubley]

On 2023-06-20, Johnny Billquist <b...@softjar.se> wrote:

> On 2023-06-20 14:06, Simon Clubley wrote:
>> On 2023-06-19, Johnny Billquist <b...@softjar.se> wrote:
>>>
>>> I really shouldn't be adding posts to this stupid topic.
>>>
>>> Competing with China is nothing like a business rivalry. At some point
>>> this needs to be addressed properly.
>>>
>>> https://youtu.be/0xlq4WSpUH8
>>>
>>
>> How does that incident compare to what the US are doing to everyone else ?
>
> Can you provide some facts instead of sweeping generalizations here, please?
>
> You just claiming something is so don't necessarily make it true.
> Hard to have a discussion comparing two things when one is a concrete
> incident, and the other a sweeping generalization and opinion.
>

Not an opinion. There's plenty of stuff that's come out about what the
US are up to. (As well as what the UK and other countries are up to).

Some random examples resulting from keyword searches:

1) The US planted backdoors in Cisco equipment:

https://www.infoworld.com/article/2608141/snowden--the-nsa-planted-backdoors-in-cisco-products.html

Exactly the kind of thing they accuse China of doing.

2) The US secretly purchased a Swiss company and sold equipment with
backdoors in it:

https://en.wikipedia.org/wiki/Crypto_AG
https://www.washingtonpost.com/graphics/2020/world/national-security/cia-crypto-encryption-machines-espionage/

Exactly the kind of thing they accuse China of doing.

3) The US violated the trust placed in it to compromise security standards:

https://en.wikipedia.org/wiki/Dual_EC_DRBG

Exactly the kind of thing China would like to do, but are not yet in
a sufficient position of trust to be able to do it.

4) The US spies on close allies for economic purposes:

https://www.dw.com/en/germany-fears-nsa-stole-industrial-secrets/a-16925289
https://www.itnews.com.au/news/snowden-accuses-nsa-of-stealing-business-secrets-370704?eid=1&edate=20140128&utm_source=20140128_AM&utm_medium=newsletter&utm_campaign=daily_newsletter&eaddr=%%Email%20Address%%

Exactly the kind of thing they accuse China of doing.

[bill]

I heard it was an even bigger disaster because one seat was empty.

bill

[Dave Froble]

Do unto others, but, do it first ...

[Dave Froble]

On 6/20/2023 1:18 PM, Chris Townley wrote:

Good one!

:-)


Sometimes sacrifices are necessary ...

:-)

[John Dallman]

In article <u6qp9o$26q1s$1...@dont-email.me>, ar...@vajhoej.dk (Arne Vajhøj)
wrote:

> On 6/19/2023 1:43 PM, Simon Clubley wrote:
> > In the old days, your military had to worry about protecting your
> > industrial base from an enemy. These days, all your enemy needs to
> > do is to threaten to stop sending you the goods they now produce
> > for you.
>
> If the goods are critical yes.
>
> But China export is mostly consumer stuff.

Last time I bought servers from IBM, they were produced in China. They
were low-to-medium range AIX boxes, about $10,000 each in about 2015.

There's also lots and lots of basic industrial supplies produced in China:
bolts, cable, switches, and so on. China has acquired vast market power
through selling stuff cheap and driving other producers out of business.

John

[Bob Gezelter]

David,

If memory serves, the tale is known as "The Frog and the Scorpion". At least one book attributed it to Vietnam.

All, WADR, let us keep the politics outside of this forum. Less stuff to wade through.

- Bob Gezelter, http://www.rlgsc.com

[Chris Townley]

There is a company that I invest in, Volex, which has carefully bought
into other manufacturing bases, to remove their dependency on China.
Sadly the market for some strange reason doesn't like their purchases

--
Chris

[Henry Crun]

Gentlemen, and any Ladies if present:

Might I please ask you to move this topic to a relevant newsgroup?
There are dozens of alt.politics.<whatever> to choose from.

Thanks,
Mike

--
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#befor

[Johnny Billquist]

On 2023-06-20 19:28, Simon Clubley wrote:
> On 2023-06-20, Johnny Billquist <b...@softjar.se> wrote:
>> On 2023-06-20 14:51, Simon Clubley wrote:
>>>
>>> Yes, it does. The US is currently using its power to force its allies
>>> to also impose sanctions. In a more general way, the US imposes a threat
>>> of being frozen out of the US banking system to get its way.
>>
>> ??? Sanctions on Russia have not been forced on by the US. You might
>> better blame the UK in that case, which has been leading this more. Or a
>> bunch of former eastern european countries, who have various past bad
>> experiences with Russia, and know all too well what it's all about.
>>
>> What other contries are there sanctions against? North Korea. Seriously
>> - you think that the US bullied other countries into those sanctions?
>> Syria? Iran?
>>
>
> China. Please research the situation with ASML and what the US is doing
> to a European company as one example.

You are of course entitled to have your opinions. It's a free world
(some parts). And you have the right to express your opinions without
fear of reprecussions.

Let's just hope countries like China don't get too much power, or that
freedom will not be there anymore.

And now this thread should die.

Johnny

[Arne Vajhøj]

This standard specifies in great detail how to get from
entropy to secure random bytes.

It does not specify how the entropy should be generated
(it uses an abstract function get_entropy_input for it).

> https://csrc.nist.gov/publications/detail/sp/800-90b/final

This is the relevant one.

Quotes:

<quote>
Noise sources can be divided into two categories: Physical noise sources
use dedicated hardware
to generate randomness; whereas Non-physical noise sources use system
data (such as output of
Application Programming Interface (API) functions, Random Access Memory
(RAM) data or
system time) or human input (e.g., mouse movements) to generate randomness.
</quote>

<quote>
The requirements for the noise source are as follows:
1. The operation of the noise source shall be documented; this
documentation shall include a
description of how the noise source works, where the unpredictability
comes from, and
rationale for why the noise source provides acceptable entropy output,
and should reference
relevant, existing research and literature.
2. The behavior of the noise source shall be stationary (i.e., the
probability distributions of the
noise source outputs do not change when shifted in time). Documentation
shall include why it
is believed that the entropy rate does not change significantly during
normal operation. This
can be in broad terms of where the unpredictability comes from and a
rough description of the
behavior of the noise source (to show that it is reasonable to assume
that the behavior is
stationary).
3. Documentation shall provide an explicit statement of the expected
entropy provided by the
noise source outputs and provide a technical argument for why the noise
source can support
that entropy rate. To support this, documentation may include a
stochastic model of the noise
source outputs, and an entropy estimation based on this stochastic model
may be included.
4. The noise source state shall be protected from adversarial knowledge
or influence to the
greatest extent possible. The methods used for this shall be documented,
including a
description of the (conceptual) security boundary’s role in protecting
the noise source from
adversarial observation or influence.
5. Although the noise source is not required to produce unbiased and
independent outputs, it shall
exhibit random behavior; i.e., the output shall not be definable by any
known algorithmic rule.
Documentation shall indicate whether the noise source produces IID data
or non-IID data. This
claim will be used in determining the test path followed during
validation. If the submitter
makes an IID claim, documentation shall include rationale for the claim.
6. The noise source shall generate fixed-length bitstrings. A
description of the output space of
the noise source shall be provided. Documentation shall specify the
fixed symbol size (in bits)
and the list (or range) of all possible outputs from each noise source.
7. If additional noise source outputs to increase security are used, a
document that describes the
additional noise sources shall be included.
</quote>

(it also contains a lot about how to test noise)

But it is all very generic and it does not require and special
HW or OS functionality. Traditional SYS$GETJPIW seems fine
(assuming all the documentation and test is done, but that is
also a requirement for HW or OS provided functionality).

> https://csrc.nist.gov/publications/detail/sp/800-90c/draft

(that is still a draft)

Just like 90A it does not cover the entropy but just refer to
an abstract GetEntropy function and 90B.

> In each case, the actual standard can be found in the top right of the
> page, under the "Publication:" section.
>
> However, since they can be hard to follow in certain parts,

The relevant parts are actually quite easy to follow.

They just don't say that current VMS methodology is unacceptable.

> here is
> a much more readable introduction-level document from Red Hat discussing
> these issues from a Linux point of view:
>
> https://www.redhat.com/en/blog/understanding-random-number-generators-and-their-limitations-linux
>
> Look at the sources Linux is using for the entropy pool. You can't duplicate
> that in user mode without access to a kernel module (and underlying OS
> support) to help you.

It explains what Linux does.

And it is not possible to do what Linux does without something in the
OS kernel.

But this was about your claim that VMS could be dropped because
it was considered not secure by todays standards.

# VMS systems
# _WILL_ be dropped in many areas if they are regarded as no longer being
# secure by today's standards.

# To put this another way, the previous solutions for generating entropy
# within user mode that I am aware of were not suitable by today's
standards.

I want to know where those standards are.

It is certainly not the NIST 800-90A/B/C quoted above.

It is certainly not that Redhat article.

Did you just make it up????

>>> Maybe I am seeing something here you are missing ?
>>
>> Possible. I miss a lot of things. So just post links
>> to the standards, best practice documents etc. specifying
>> the need for direct OS entropy.
>>
>
> The NIST and earlier standards specify a series of requirements. You can't
> meet those requirements in a software-based solution without kernel support
> to get direct access to the entropy sources.

No.

That is not what the NIST standards say.

Arne

[Arne Vajhøj]

On 6/19/2023 9:43 PM, Dave Froble wrote:
> People who count for encryption to provide protection don't really care
> all that much.  Do enough to check the appropriate box, then not their
> problem.
>
> People who really care about security of course may use SSL, but then
> what happens when the encryption is broken?  The user's data is
> available to the hackers.  But what if the app developers insured that
> the data, if encryption is defeated, doesn't really mean anything to the
> hackers.  Some custom stuff in addition to SSL and such.  Yeah, even
> then, some hacker might figure out the data.  But isn't it better to
> make it as tough for the hacker as one can?
>
> Now I'll hear from some "you got to use standards".  I'd ask "why?"  The
> problem with standards is, everybody knows them.

There are two benefits from going standard.

Interoperability. If the communication is based on standards, then
software from different vendors can communicate. SSL (TLS 1.2 or 1.3
of course!) is widely supported standard so C programs on VMS,
Java programs on Linux and VB.NET programs on Windows can communicate
without problems due to the standard.

Security. The public known standard protocols and algorithms are being
reviewed by thousands of mathematicians all over the world. A home grown
protocol and algorithm will be reviewed by a few software engineers
which may or may not have math/cryptography knowledge. The first will
simply result in a better solution.

Good cryptography does not depend on protocols or algorithms
being unknown. It is possible to constructs stuff that are secure
even with known protocols/algorithms. And protocols/algorithms
that are not secure if known are very bad. They will eventually leak.

Arne

[Dave Froble]

You sort of missed the point of my post.

[Pizza RAC]

Keynesian economics always fail ... just ask Japan.

[Pizza RAC]

On Monday, June 19, 2023 at 5:29:57 PM UTC-4, Dave Froble wrote:
> On 6/19/2023 11:57 AM, Johnny Billquist wrote:
> > On 2023-06-19 16:41, Pizza RAC wrote:
> >> On Thursday, June 15, 2023 at 6:43:08 PM UTC-4, Jan-Erik Söderholm wrote:
> >>>
> >>> Now, my last VMS work seem to have come to an end the 30th June.
> >>> So I'll probably never be able to work with this new VMS version.
> >>> I was 64 in may -23 so I will probably simple retire...
> >>>
> >>> Ah well, 30+ years with VMS is not that bad anyway... :-)
> >>>
> >>> Jan-Erik.
> >>
> >> come to the U.S. with Biden in charge no one will ever be able to retire :)
> >
> > Yeah. I guess that concept only exist in socialist countries, like Sweden.
> I think that is also possible in a possibly non-socialist country, but it sure
> isn't helped by fascist Republicans, and the US seems to growing some of them.
>
> I know this isn't the venue for politics. But I grow tired of seeing the same
> old thing over and over again. One would think that supposedly intellegent
> humans would sooner or later learn. But apparently not.
>
> In the 1930s a great evil arose. Many bad things happened. And now, 90 years
> later, it's happening again.
>
> Racism in the US and elsewhere.
>
> We see attempts to silence political opponents in other countries, but that
> would never happen in the USA, right? Too bad nobody mentioned that to the
> "dangerous" idiot in Florida.
>
> I guess some in Israel feel it's their turn, and are doing to the Palestinians
> what the Nazis did to them. Wonder when they will schedule their "crystal night".
>
> But the biggest thing I'm really pissed off about, "find me 11,800 votes".

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

someone called the antichrist is going to appear very soon. He will deceive many into following him.

End times ...

[John Dallman]

In article <u6r05u$2b1q4$1...@dont-email.me>, da...@tsoft-inc.com (Dave

Froble) wrote:

> People who really care about security of course may use SSL, but
> then what happens when the encryption is broken? The user's data
> is available to the hackers. But what if the app developers
> insured that the data, if encryption is defeated, doesn't really
> mean anything to the hackers. Some custom stuff in addition to SSL
> and such. Yeah, even then, some hacker might figure out the data.
> But isn't it better to make it as tough for the hacker as one can?
>
> Now I'll hear from some "you got to use standards". I'd ask "why?"
> The problem with standards is, everybody knows them.

The SSL standards, and the TLS standards that have succeeded them, do
something that's actually quite hard, which is to let two ends of a
communication link agree on an encryption key without ever passing that
key over the link, or having any kind of default key or other shared
secret.

They do that part via cleverness with public-key encryption, and use it
to agree on a key for symmetric encryption. Those are significantly
different kinds of encryption: you can't do the key-agreement part in a
practical way with only symmetric encryption, and public-key encryption
is too slow for sending any volume of data.

<https://en.wikipedia.org/wiki/Public-key_cryptography>
<https://en.wikipedia.org/wiki/Symmetric-key_algorithm>
<https://en.wikipedia.org/wiki/Transport_Layer_Security>

Note that you do get to tell your end of the TLS link what public- and
symmetric algorithms you are willing for it to use, and what key lengths
you demand. If the other end can't meet your demands, you can't
communicate, but that's failing to the secure case.

The main reason for using standard TLS, rather than creating your own
version, is that doing that right is /hard/, and anyone doing it
themselves is certain, at a practical level, to create something worse
than TLS.

The standards have been reviewed and attacked by large numbers of experts
over years. Versions 1.0, 2.0 and 3.0 of SSL have been cracked and
deprecated; versions 1.0 and 1.1 of TLS are also cracked and deprecated.
TLS 1.2 has vulnerabilities that are currently difficult to exploit and
will be deprecated in the next few years; TLS 1.3 is currently sound.

Cracks of those standards aren't a question of finding out how to read a
secret code or cipher that they use, or cracking public-key encryption,
but of finding flaws in the way that they /use/ public-key encryption so
as to give clues about the (entirely random) symmetric encryption key
that they are used to agree on. Those standards are treated as cracked as
soon as a way to get significant information about the negotiated key is
published. That doesn't mean that everything sent over them has become
readable: being able to discover a few bits of a 128- or 256-bit key is a
"crack." Thereby, they are deprecated long before breaking them becomes
practical.

Now, using additional encryption on the data you're sending over TLS is
certainly possible. However, it isn't all that practical. You need to
agree an encryption key between the two ends. You can do that via
communication through the TLS link, but if that's being read by an
opponent, they just got the key you're about to use for your data.

If you do TLS-through-TLS, that could work, provided the TLS you're using
is not cracked. But it's just easier to use a single layer of TLS and
require it to use longer public keys and stronger symmetric algorithms.

The secondary reason for using standard TLS is that it allows you to
communicate with anything else that uses it. Other implementations, other
operating systems, and so on.

Now, that may not be important to you. You may be building a system where
only specific computers are to communicate with each other. It is still
worth considering using standard TLS, for several reasons:

* The protocols are very likely better than anything home-built.
* If the TLS protocols are cracked, you'll hear about it early on.
* If a homebrew protocol is cracked, your opponent won't tell you.
* Distributing symmetric keys any other way is harder.

Alternative ways of distributing keys require sending some kind of
computer-readable physical medium. It needs to be hard to copy, and it
needs to arrive /very/ reliably. If your system won't be in use long,
this may be practical.

How do you tell which public-key and symmetric algorithms are good?
Knowledge of the field.

The current gold standard for symmetric is the Advanced Encryption
Standard, which is approved by the NSA for Top Secret information.
<https://en.wikipedia.org/wiki/Advanced_Encryption_Standard>

The current gold standard for public-key is RSA with a key of 4096 bits
or longer. This is currently expected to be menaced by quantum computers
within a decade, and the NSA is starting a transition to post-quantum
cryptography. For now, it's the best we have and is very unlikely to be
broken soon.

John

[Simon Clubley]

On 2023-07-04, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
> But it is all very generic and it does not require and special
> HW or OS functionality. Traditional SYS$GETJPIW seems fine
> (assuming all the documentation and test is done, but that is
> also a requirement for HW or OS provided functionality).
>

At this point Arne, I don't know if you are trolling or if you really
believe that because your use of highly-abstracted languages and
associated APIs means you have lost touch with how those highly-abstracted
languages and APIs are implemented.

Every single OS vendor I am aware of, including now VSI, implements
this stuff using a kernel module to supply the required level of quality
to user programs.

No vendor I am aware of, including even Microsoft, does entropy generation
for security purposes in purely user mode.

However, because you may be aware of something I am not, can you point
to an OS that does entropy generation in purely user mode, without access
to external entropy generators, or access to the results of internal
kernel operations, such as interrupt timings, and which meets current
security standards ?

Question: If SYS$GETJPIW was good enough, why didn't VSI just use that
instead of going straight to designing and implementing an entropy engine,
with all the work that involves ?

They have not implemented many things that have been asked for due to
resource limitations, but they have spent time implementing this because
they clearly consider it to be vital.

From https://docs.vmssoftware.com/docs/VSI_Webinar_March_2022.pdf in the
OpenSSL section:

|Working on new entropy engine that will work with OpenSSL 3.0 to help
|facilitate FIPS 140-x compliance

|SSL3 is also a key component of VSI's security roadmap to ensure that the
|OpenVMS operating system and applications running on OpenVMS are able meet
|relevant security requirements by supporting specific features such as FIPS.

>
> The relevant parts are actually quite easy to follow.
>
> They just don't say that current VMS methodology is unacceptable.
>

Standards generally don't say that using "1234" as a combination or
"password" as a password are unacceptable either. They instead focus
on explaining _what_ is acceptable.

>> here is
>> a much more readable introduction-level document from Red Hat discussing
>> these issues from a Linux point of view:
>>
>> https://www.redhat.com/en/blog/understanding-random-number-generators-and-their-limitations-linux
>>
>> Look at the sources Linux is using for the entropy pool. You can't duplicate
>> that in user mode without access to a kernel module (and underlying OS
>> support) to help you.
>
> It explains what Linux does.
>
> And it is not possible to do what Linux does without something in the
> OS kernel.
>
> But this was about your claim that VMS could be dropped because
> it was considered not secure by todays standards.
>
> # VMS systems
> # _WILL_ be dropped in many areas if they are regarded as no longer being
> # secure by today's standards.
>
> # To put this another way, the previous solutions for generating entropy
> # within user mode that I am aware of were not suitable by today's
> standards.
>
> I want to know where those standards are.
>
> It is certainly not the NIST 800-90A/B/C quoted above.
>

Are you sure about that ?

> It is certainly not that Redhat article.
>
> Did you just make it up????
>

VSI consider certifying VMS against FIPS to be important and they consider
a kernel-based entropy engine to be a vital part of that. Are you saying
VSI are wrong ?

BTW, with regards to my above Microsoft reference, from the following
whitepaper:

Whitepaper - The Windows 10 random number generation infrastructure.pdf

(Google it as I am not sure if the long hex string in the URL is some
personal identifier or not).

|The primary entropy source in Windows 10 is the interrupt timings. On each
|interrupt to a CPU the interrupt hander gets the Time Stamp Count (TSC)
|from the CPU. This is typically a counter that runs on the CPU clock
|frequency; on X86 and X64 CPUs this is done using the RDTSC instruction.

[snip]

Read the rest of the section as it is very interesting and clearly even
Microsoft considers this to be way more involved than just a few calls
to the Windows version of SYS$GETJPIW as you claim above.

[Arne Vajhøj]

> You sort of missed the point of my post.

I miss a lot.

But I read it as that you suggested not using standard
protocols/algorithms but something unique/homemade.

Was that not the case?

Arne

[Arne Vajhøj]

On 7/5/2023 10:39 AM, John Dallman wrote:
> How do you tell which public-key and symmetric algorithms are good?
> Knowledge of the field.
>
> The current gold standard for symmetric is the Advanced Encryption
> Standard, which is approved by the NSA for Top Secret information.

Yes.

> The current gold standard for public-key is RSA with a key of 4096 bits
> or longer.

I think the ECC stuff is also very widely used today.

Regrading RSA key size then I think NIST and OWASP still just
recommends >=2048. My impression is that the IT industry
often goes for 3072. 4096 is very good.

Arne

[Arne Vajhøj]

On 7/5/2023 2:23 PM, Simon Clubley wrote:
> On 2023-07-04, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> But it is all very generic and it does not require and special
>> HW or OS functionality. Traditional SYS$GETJPIW seems fine
>> (assuming all the documentation and test is done, but that is
>> also a requirement for HW or OS provided functionality).
>
> At this point Arne, I don't know if you are trolling or if you really
> believe that because your use of highly-abstracted languages and
> associated APIs means you have lost touch with how those highly-abstracted
> languages and APIs are implemented.

I don't think my preference for programming languages are particular
relevant for whether your claims of:

# VMS systems
# _WILL_ be dropped in many areas if they are regarded as no longer being
# secure by today's standards.

# To put this another way, the previous solutions for generating entropy
# within user mode that I am aware of were not suitable by today's
standards.

are correct or not.

> Every single OS vendor I am aware of, including now VSI, implements
> this stuff using a kernel module to supply the required level of quality
> to user programs.
>
> No vendor I am aware of, including even Microsoft, does entropy generation
> for security purposes in purely user mode.

Using HW/OS is definitely what is being done for new OS versions.

But there is a difference from that and the old way not being
acceptable.

> Question: If SYS$GETJPIW was good enough, why didn't VSI just use that
> instead of going straight to designing and implementing an entropy engine,
> with all the work that involves ?

The question was not whether using HW/OS is good. I think everybody
agrees it is.

The question was whether not using HW/OS would cost VMS sales now
due to being not compliant.

It is hardly surprising that VSI is implementing new functionality
looking forward instead of backwards.

> They have not implemented many things that have been asked for due to
> resource limitations, but they have spent time implementing this because
> they clearly consider it to be vital.
>
> From https://docs.vmssoftware.com/docs/VSI_Webinar_March_2022.pdf in the
> OpenSSL section:
>
> |Working on new entropy engine that will work with OpenSSL 3.0 to help
> |facilitate FIPS 140-x compliance
>
> |SSL3 is also a key component of VSI's security roadmap to ensure that the
> |OpenVMS operating system and applications running on OpenVMS are able meet
> |relevant security requirements by supporting specific features such as FIPS.

That is actually interesting.

Per:

https://www.openssl.org/docs/fips.html
https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282

then OpenSSL is FIPS 140-2 certified on:

<quote>
Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86) with PAA
Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86)
without PAA
FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64)
without PAA
macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64) with PAA
macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64)
without PAA
macOS 11.5.2 running on Apple M1 Mac Mini with M1 with PAA
macOS 11.5.2 running on Apple M1 Mac Mini with M1 without PAA
(single-user mode)
Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel
i7(x64) with PAA
Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel
i7(x64) without PAA
Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) without PAA
</quote>

Maybe VSI want VMS on that list.

But that list is not the server market.

>> The relevant parts are actually quite easy to follow.
>>
>> They just don't say that current VMS methodology is unacceptable.
>>
>
> Standards generally don't say that using "1234" as a combination or
> "password" as a password are unacceptable either. They instead focus
> on explaining _what_ is acceptable.

Yes.

But old practices seems to match the description of what is acceptable.

I actually copied the text in. You just omitted it when replying.

>> But this was about your claim that VMS could be dropped because
>> it was considered not secure by todays standards.
>>
>> # VMS systems
>> # _WILL_ be dropped in many areas if they are regarded as no longer being
>> # secure by today's standards.
>>
>> # To put this another way, the previous solutions for generating entropy
>> # within user mode that I am aware of were not suitable by today's
>> standards.
>>
>> I want to know where those standards are.
>>
>> It is certainly not the NIST 800-90A/B/C quoted above.
>
> Are you sure about that ?

I quoted the text. You tell me what lines old OpenSSL does not match.

>> It is certainly not that Redhat article.
>>
>> Did you just make it up????
>>
>
> VSI consider certifying VMS against FIPS to be important and they consider
> a kernel-based entropy engine to be a vital part of that. Are you saying
> VSI are wrong ?

If VSI believe they need FIPS certification and that they need the new
better entropy to get that, then it all makes sense.

But if you check the list above then FIPS certification does not
seem to be a requirements to sell servers today.

Among other things then Redhat Linux is not on the list.

(even though I believe they are in the process of getting certified)

Arne

[Arne Vajhøj]

But I wonder.

How will VSI get FIPS 140-2 certification for VMS x86-64 if they only
support running in VM not on physical hardware??

Arne

[Dave Froble]

No!

I use such as SSL and other standards.

But then, it's not enough to say "hey, we use standards", and assume all will be
well. Perhaps going beyond such and further trying to make your data useless to
those who should not have it.

[Arne Vajhøj]

> No!
>
> I use such as SSL and other standards.
>
> But then, it's not enough to say "hey, we use standards", and assume all
> will be well.  Perhaps going beyond such and further trying to make your
> data useless to those who should not have it.

So you are suggesting a double encryption scheme. An application
specific encryption of the payload being transported encrypted by SSL.

If that application specific encryption use the same algorithms as
SSL, then it will not provide any benefits.

But using different algorithms is protecting you against a
future fatal flaw in one of the algorithm sets.

I will consider the risk of a fatal flaw in AES or RSA/ECC
to be found very small.

But if the application is controlling launch of ICBM's then it
may be warranted to add the extra layer of security.

Arne

[Dave Froble]

Ok, an example:

Back when we were storing customer credit card information, we broke the number
into 2 parts, and stored each part on two different databases on two different
systems. Thus, any hacker would not get total CC data unless he know our
design. Also stored the exp data and pin in different locations. If someone
knew the design, then the data was still at risk. But much harder.

I do not advocate any particular design, and no, I was not thinking about double
encryption. Such stuff needs to be different, and not just more of the same
(encryption or whatever).

Assume a hacker will break in, then think of ways to make it harder to actually
cause harm.

[Arne Vajhøj]

On 7/5/2023 8:30 PM, Dave Froble wrote:
> Back when we were storing customer credit card information,  we broke
> the number into 2 parts, and stored each part on two different databases
> on two different systems.  Thus, any hacker would not get total CC data
> unless he know our design.  Also stored the exp data and pin in
> different locations.  If someone knew the design, then the data was
> still at risk.  But much harder.

If the same application has access to both databases, then
I would say that the risk that if hackers (and that include
insiders) got access one then they got access to both is
pretty high. And the problem of having to figure out where
the different pieces are stored is not a hard problem
compared to various encryption schemes.

Arne

[Dan Cross]

In article <u84l3q$kcjd$1...@dont-email.me>,

Virtual Machines, by definition, run most of their instructions
on the physical hardware, including in kernel mode. Running in
a VM does not preclude one from access to high-quality hardware
facilitated entropy sources a priori.

- Dan C.

[Dan Cross]

In article <u84k26$k8rl$1...@dont-email.me>,

I rather thought it was whether existing customers would ditch
VMS due to their old versions not being up to snuff with the
latest best-practices. If they would, and Simon seems to
believe that they will and I believe him, then it stands to
reason that if VSI wants to retain customers it must provide a
path forward to a system that uses those best-practices, which
is what they are doing.

I don't know if the "old" OpenSSL has much to do with it; it
seems like it used some kind of system facility to get entropy.
The question then is about how one gets that entropy. Earlier,
in the same message where you quoted text from the NIST standard

you wrote:

> But it is all very generic and it does not require and special
> HW or OS functionality. Traditional SYS$GETJPIW seems fine
> (assuming all the documentation and test is done, but that is
> also a requirement for HW or OS provided functionality).

(from https://groups.google.com/g/comp.os.vms/c/01BdjALzsWQ/m/VggQH86-AQAJ)

But note that part of the NIST document that you copied and
pasted said the following:

|4. The noise source state shall be protected from adversarial
| knowledge or influence to the greatest extent possible. The
| methods used for this shall be documented, including a
| description of the (conceptual) security boundary's role in
| protecting the noise source from adversarial observation or
| influence.

And

|5. Although the noise source is not required to produce
| unbiased and independent outputs, it shall exhibit random
| behavior; i.e., the output shall not be definable by any
| known algorithmic rule. Documentation shall indicate
| whether the noise source produces IID data or non-IID
| data. This claim will be used in determining the test path
| followed during validation. If the submitter makes an IID
| claim, documentation shall include rationale for the claim.

Given how the `SYS$GETJPIW` interface is defined at e.g.,
https://wiki.vmssoftware.com/$GETJPI, I don't know why anyone
would believe it meets these criteria. In particular, pretty
much everything that can be returned from GETJPI is discoverable
outside of the process, violating the "shall be protected from
adversarial knowledge to the greatest extent possible" criteria
in (4), and most of it is also "definable by known algorithmic
rules", as prohibited by (5).

Furthermore, none of the documentaton criteria specified by NIST
seem to be fulfilled.

>>> It is certainly not that Redhat article.
>>>
>>> Did you just make it up????
>>
>> VSI consider certifying VMS against FIPS to be important and they consider
>> a kernel-based entropy engine to be a vital part of that. Are you saying
>> VSI are wrong ?
>
>If VSI believe they need FIPS certification and that they need the new
>better entropy to get that, then it all makes sense.
>
>But if you check the list above then FIPS certification does not
>seem to be a requirements to sell servers today.

Sure. But if you have customers that you value that are making
noise about moving from your platform because of issues like
this, and you want to retain those customers, then, well, you
probably address issues like this.

- Dan C.

[Arne Vajhøj]

No. But that is not the problem.

FIPS 140-2 certification is a certification of hardware
and software.

VMS 9.2-1 on a VirtualBox VM setup as ... running on
RockyLinux 9 running on Dell Inspiron 7591 with Intel i7(x64)????

Arne

[Dan Cross]

In article <u859bs$q1h7$1...@dont-email.me>,

Hypervisors are software. The guest OS running on them is also
software. Certifying an OS running on a specific hypervisor on
a specific hardware platform is certainly doable.

>VMS 9.2-1 on a VirtualBox VM setup as ... running on
>RockyLinux 9 running on Dell Inspiron 7591 with Intel i7(x64)????

Sounds pretty bog standard as these things go, but I imagine it
would be more like VMS on ESXi on a Dell Xeon thing. Probably
much of that combination is already at least partially tested
for the US military (ESXi on Dell hardware was very common when
I was a communications officer in the US Marine Corps, which
wasn't _that_ long ago).

- Dan C.

[Gary Sparkes]

On Wednesday, July 5, 2023 at 10:36:48 PM UTC-4, Arne Vajhøj wrote:
> No. But that is not the problem.
>
> FIPS 140-2 certification is a certification of hardware
> and software.
>
> VMS 9.2-1 on a VirtualBox VM setup as ... running on
> RockyLinux 9 running on Dell Inspiron 7591 with Intel i7(x64)????
>
> Arne

I'll note that certification isn't necessarily required for procurement, and that
it ISN'T a combination of hardware AND software together. You can certify
specific combinations, yes, just as you can certify just hardware alone, or
just software alone.

Note, that windows, with the correct configuration, is considered compliant
on ANY hardware or virtualization solution. You can be validated as Software,
Software-Hybrid, or Hardware. Microsoft's solutions are almost all validated
as SOFTWARE or SOFTWARE-HYBRID. It is compliant when configured
correctly, regardless of hardware.

What you listed above in a previous post is the "tested configuration"
which isn't the actual validation. It's just saying what they used to
validate that specific module meets the requirements and standards in
NIST lab setup.


Take a look at the consolidated certificate, showing the hardware/software
configurations of the actual validations:

https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/certificates/August%202022_010922_0715_signed.pdf

Note that the OpenSSL FIPS Provider validation is only referring to the
software version, and has NO hardware data with it. Because the validation is
on the software only.


The important takeaways from the OpenSSL validation you linked is -
"When operated in FIPS mode. No assurance of the minimum strength of
generated keys." and "Module type: SOFTWARE". That means, yes, it's
compliant, with caveats.


Nominally, the software is only considered to be functioning in validated
and compliant mode if configured according to the security policy (usually)
linked on the validation page.

"This is what we tested it on" isn't the same as "it is only validated on".



Side note, CMVP which is no longer accepting submissions for 140-2
certifications - only 140-3. After September 21, 2026 140-2 modules are
considered "historical" and should only be procured in support of existing
deployments.

[Gary Sparkes]

> Hypervisors are software. The guest OS running on them is also
> software. Certifying an OS running on a specific hypervisor on
> a specific hardware platform is certainly doable.
> >VMS 9.2-1 on a VirtualBox VM setup as ... running on
> >RockyLinux 9 running on Dell Inspiron 7591 with Intel i7(x64)????
> Sounds pretty bog standard as these things go, but I imagine it
> would be more like VMS on ESXi on a Dell Xeon thing. Probably
> much of that combination is already at least partially tested
> for the US military (ESXi on Dell hardware was very common when
> I was a communications officer in the US Marine Corps, which
> wasn't _that_ long ago).
>
> - Dan C.

In this specific case, it's just the test/lab configurations that were used.
Note that it's each OS on two different configurations.

Linux x86 (where applicable) and x64 in both modes.
FreeBSD in x64 with both modes.
macOS on x64 and ARM in both modes.

The organization that submitted it for validation wanted it tested in all
those.

Sounds like the lab just used the first 3 machines available that
could run all the tests under the submission's request.

But as this is a software module validation, as long as the source is
unmodified for this module, and it passes its own internal unmodified
self-tests, it would be considered validated and approved on VSI VMS
without any additional need to do anything.

Since it's only the OpenSSL module itself that's validated. Nothing else.

However, for sake of ease and procurement procedures, OS vendors
do tend to time to time submit for validation their implementation.
Especially ones delivered in binary form. But it would be trivial for me
to get approval and/or defend procurement if I can demonstrate that
the correct module and version is loaded and in use in the correct
configuration.

[Brian Schenkenberger]

On 2023-06-15 22:26:00 +0000, John Dallman said:

> * AMD CPUs compatibility
> * Initial support for KVM SCSI VirtIO
> * Built-in SSL3
> * Numerous fixes and improvements to the debugger and dump analyzer
> * Many native compilers, such as C, C++, Fortran, and Macro, are now
> available for field test. A new set that includes Bliss, COBOL, and
> BASIC is expected to become available soon
> * Support for newer VMWare hypervisors versions
> * Additional entropy collection mechanism
>
> https://vmssoftware.com/about/news/2023-06-15-openvms-v9-2-1-release/
>
> "SSL3" seems to mean OpenSSL v3, not the SSL v3 protocol, which has been
> deprecated for years.
>
> John

It would be nice to get my hands on this. The registration page form
is hopelessly horked with the stupid reCAPTCHA.

Doesn't anyone read the messaged via the site's contact form or is that
too fucked up?

[Simon Clubley]

On 2023-08-16, Brian Schenkenberger <ma...@SendSpamHere.ORG> wrote:
>
> It would be nice to get my hands on this. The registration page form
> is hopelessly horked with the stupid reCAPTCHA.
>

That must be new. Don't ever recall having to do that before or is it
only x86-64 specific ?

> Doesn't anyone read the messaged via the site's contact form or is that
> too fucked up?
>

I do get replies from queries sent via the contact form (at least when
VSI decide not to ignore me. :-))