On 2022-08-03, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Ok Simon, a question for you.
>
> Suppose someone finds a vulnerability in VAX/VMS V5.2H4, and that someone knows
> that there is very little, or no, chance of a fix. And that someone also is
> aware that some users are still using that old software.
>
> So now the moral question. Knowing there will not be a fix, and knowing that
> exposure just might cause problems for said user running that old software, is
> it Ok to expose the vulnerability?
>

Yes, absolutely, it is ok to disclose big time, provided you have
given the vendor enough time (usually 3 months unless it's _known_
to be under active exploitation) to fix the problem in current
supported versions of the operating system.

Unless users of this version know about the vulnerability, then
they can't protect themselves from it.

Users of really old versions of an operating system should also have
existing protections in place to help mitigate against the future
possibility of new vulnerabilities with that version being discovered.

Simon.

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

On 8/3/22 21:28, Dave Froble wrote:
> On 8/3/2022 1:30 PM, Simon Clubley wrote:
>> On 2022-08-03, abrsvc <dansabrservices@yahoo.com> wrote:
>>>
>>> The lack of support means nothing. In many cases, support was
>>> continued strictly for access to newer versions that often were never
>>> used.  I new of many clients that remained at V7.3-2 for Alpha
>>> systems because it was stable and did what they needed with no
>>> problems at all.  Moving to newer versions was a cost (validation
>>> work) that couldn't be justified since there were no benefits to the
>>> upgrade.  I can cite other clients with different hardware and OS
>>> levels with similar status too. Stabile application software that
>>> does the job does not usually need newer OS versions.  Compare the
>>> VMS environment with that of Windows where updates are constantly
>>> required because of the instability of the OS or external
>>> vulnerabilities that just don't exist for VMS.
>>
>> This isn't a discussion about the DCL vulnerability. It's a discussion
>> about what is likely to happen if security researchers take a serious
>> interest in probing VMS in general and find a series of vulnerabilities
>> which they then disclose in public after giving VSI time (about 3 months
>> usually) to fix the vulnerabilities.
>>
>> Your last sentence above is a perfect example of the mindset I am
>> warning about.
>>
>> Simon.
>>
>
> Ok Simon, a question for you.
>
> Suppose someone finds a vulnerability in VAX/VMS V5.2H4, and that
> someone knows that there is very little, or no, chance of a fix.  And
> that someone also is aware that some users are still using that old
> software.
>
> So now the moral question.  Knowing there will not be a fix, and knowing
> that exposure just might cause problems for said user running that old
> software, is it Ok to expose the vulnerability?
>

Bad example. There is a fix. Move off of V5.2H4. And before
you say they can't move, of course they can. The only limiting
factor is probably cost and that's just a bad excuse for a business.

bill

In article <tcc5ih$ues$1@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
>On 2022-08-02 16:33, Dan Cross wrote:
>> In article <tc1d87$tnl$1@news.misty.com>,
>> Johnny Billquist <bqt@softjar.se> wrote:
>>> On 2022-07-26 13:32, Dan Cross wrote:
>>>> But again, why should VSI care? They have nothing to do
>>>> with VAX. If people started doing this for Alpha, Itanium
>>>> or x86, I could see it since VSI has interest in those
>>>> platforms. But VAX is explicitly out of their domain.
>>>
>>> I should point out that VSI have nothing to do with VAX out of choice.
>>> They could technically make a VAX release if they wanted to. They do
>>> have the rights, and the code.
>>
>> A fair point, but regardless, they have chosen not to care.
>>
>> It boggles my mind that people think that an organization that
>> has explicitly declined to work with the VAX (for the very valid
>> reasons mentioned elsewhere in this thread) would care if a few
>> hobbyists run an OS, 20 years out of maintenance, they can't
>> issue licenses for anyway.
>>
>> Maybe those people have the inside track with someone at at VSI
>> who has told them that this is as big a deal as they are making
>> it out to be, but I find that doubtful.
>
>I doubt it's the talking point of the day for VSI. But never the less,
>there is a point in observing how people behave in similar situations to
>deduce how they might behave elsewhere.
>
>Bill did make a good point about the non-existence of hobbyist program
>for the PDP-11 software, which allegedly is because people were
>misbehaving. And VSI might look at how people behave around the VAX and
>decide how they want to continue hobbyist stuff for the platforms they
>have made releases for.

The bottom line is that absent some definitive statement from
VSI, this is all speculation. Mentec was a different company.
Also, didn't Mentec license RSTS prior to 9.6 for hobbyist use
in 1997? And RSX-11M <= 4.3 and -11M Plus <= 3.0 in 1998?

>Not to mention the risk that if you do not protect your rights, it can
>become a point in future legal discussions elsewhere. It's not like the
>VAX version is completely different than current VMS.

Perhaps, but this seems like a completely separate issue. They
can't license current versions of VAX/VMS even if they wanted
to; what legal right would they have to protest illicit use of
software they don't own?

>I would say it's a mischaracterization to say "they have choosen not to
>care". They have different priorities and different goals. That do not
>mean they do not care.
>
>It is, as always, a question of prioritization and resource allocation.
>
>With infinite money and infinite time, I would suspect that they
>wouldn't mind doing something for the VAX as well.

That's fair. But with infinite resources, a lot of things would
be different.

My point isn't that people should go run VAX/VMS, as arguably
they shouldn't, my point is that people are making speculative
statements about tangentially related things as if they were
fact, but the actual disposition of these matters is not at all
clear.

- Dan C.

tehy

In article <62e9b4ec$0$699$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 8/2/2022 10:33 AM, Dan Cross wrote:
>> In article <tc1d87$tnl$1@news.misty.com>,
>> Johnny Billquist <bqt@softjar.se> wrote:
>>> On 2022-07-26 13:32, Dan Cross wrote:
>>>> But again, why should VSI care? They have nothing to do
>>>> with VAX. If people started doing this for Alpha, Itanium
>>>> or x86, I could see it since VSI has interest in those
>>>> platforms. But VAX is explicitly out of their domain.
>>>
>>> I should point out that VSI have nothing to do with VAX out of choice.
>>> They could technically make a VAX release if they wanted to. They do
>>> have the rights, and the code.
>>
>> A fair point, but regardless, they have chosen not to care.
>>
>> It boggles my mind that people think that an organization that
>> has explicitly declined to work with the VAX (for the very valid
>> reasons mentioned elsewhere in this thread) would care if a few
>> hobbyists run an OS, 20 years out of maintenance, they can't
>> issue licenses for anyway.
>>
>> Maybe those people have the inside track with someone at at VSI
>> who has told them that this is as big a deal as they are making
>> it out to be, but I find that doubtful.
>
>It is quite common to suspect that people known to be willing to
>break one law is more willing to break another law.
>
>Most people would not let their daughter go on a date with
>a convicted bank robber - even though the daughter is obviously
>not a bank.

This is very much a strawman. A better analogy might be, if
someone picks something out of the trash and gets it working
again, is that technically theft?

- Dan C.

In article <62eb1562$0$694$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>[snip]
>Hackers tend to focus on common ISA and common OS.That
>makes sense. So Linux, Windows and x86-64.
>
>But I would be hard pressed to name any specific problems
>due to x86-64. Even the cache issues existed on other
>ISA. And as we all know then ILO are not x86-64 specific
>either.
>
>The reality is that there are close to nothing ISA
>related, some OS related, some standard application related
>and the vast majority custom application related.

There have been, and will almost certainly continue to be,
ISA-related vulnerabilities. Two that I can think of off the
top of my head are POP SS (https://everdox.net/popss.pdf) and
the iret flaw handling NMIs (https://lwn.net/Articles/484932/),
though the latter may be more properly classified as simply "an
error".

Not to mention model/vendor-specific issues like L1TF.

- Dan C.

In article <bac17ef7-9cf0-4d0a-9abf-026662ce0246n@googlegroups.com>,
abrsvc <dansabrservices@yahoo.com> wrote:
>[snip]
>Compare the VMS environment with that of Windows where updates are
>constantly required because of the instability of the OS or external
>vulnerabilities that just don't exist for VMS.

The issue is that those vulnerabilities may well exist, you just
don't know about them because either no one is looking for them,
or they are and are not telling anyone what they find.

- Dan C.

On 8/3/22 11:30 AM, Simon Clubley wrote:
> On 2022-08-03, abrsvc <dansabrservices@yahoo.com> wrote:
>>
>> The lack of support means nothing. In many cases, support was continued strictly for access to newer versions that often were never used. I new of many clients that remained at V7.3-2 for Alpha systems because it was stable and did what they needed with no problems at all. Moving to newer versions was a cost (validation work) that couldn't be justified since there were no benefits to the upgrade. I can cite other clients with different hardware and OS levels with similar status too. Stabile application software that does the job does not usually need newer OS versions. Compare the VMS environment with that of Windows where updates are constantly required because of the instability of the OS or external vulnerabilities that just don't exist for VMS.
>
> This isn't a discussion about the DCL vulnerability. It's a discussion
> about what is likely to happen if security researchers take a serious
> interest in probing VMS in general and find a series of vulnerabilities
> which they then disclose in public after giving VSI time (about 3 months
> usually) to fix the vulnerabilities.
>
> Your last sentence above is a perfect example of the mindset I am
> warning about.

Simon's assumption is that, because he found a vulnerability, there must
be a multitude of other as yet undiscovered vulnerabilities lying in
wait because VMS just hasn't seen the kind of security probing that
other OSes have. He makes this assumption clear in many of his posts.

His assumption is unfounded.

Simon has no idea what sort of security testing various organizations
have done to VMS, especially by those that needed to have confidence in
the platform's security before deploying it in a security-demanding
environment. He also has no idea of what security-related SPRs were
sent to Digital, or of the issues that were found and fixed strictly
internally.

Having been a part of such testing, I think I have a better
understanding of the situation than Simon does. I will state here that
such testing is why I have such definite opinions on running Multinet
vs. TCPIP Services if one is concerned about security. I really hope
the version VSI is releasing addresses these issues. I will also state
that I have run VMS systems wide-open to the Internet, something I would
not do with any other platform. They invited attacks and definitely
received them. They were heavily probed but never penetrated even
though they ran services that are typically vulnerable on other
platforms such as web services (WASD, not Apache) and anonymous FTP.
They even ran *gasp* DECnet (phase V).

The truth is, there have been security issues found within VMS. Some of
them were never known by the public. Once found, they tended to be
fixed very quickly (which is all you can ask of any platform), which has
not always been the case in other now more popular platforms. However,
the idea that VMS is a rickety platform just waiting to be exploited
once security researchers "finally" start seriously probing it is just
plain ridiculous.

Mark Berryman

On 8/4/2022 9:30 AM, Bill Gunshannon wrote:
> On 8/3/22 21:28, Dave Froble wrote:
>> On 8/3/2022 1:30 PM, Simon Clubley wrote:
>>> On 2022-08-03, abrsvc <dansabrservices@yahoo.com> wrote:
>>>>
>>>> The lack of support means nothing. In many cases, support was continued
>>>> strictly for access to newer versions that often were never used. I new of
>>>> many clients that remained at V7.3-2 for Alpha systems because it was stable
>>>> and did what they needed with no problems at all. Moving to newer versions
>>>> was a cost (validation work) that couldn't be justified since there were no
>>>> benefits to the upgrade. I can cite other clients with different hardware
>>>> and OS levels with similar status too. Stabile application software that
>>>> does the job does not usually need newer OS versions. Compare the VMS
>>>> environment with that of Windows where updates are constantly required
>>>> because of the instability of the OS or external vulnerabilities that just
>>>> don't exist for VMS.
>>>
>>> This isn't a discussion about the DCL vulnerability. It's a discussion
>>> about what is likely to happen if security researchers take a serious
>>> interest in probing VMS in general and find a series of vulnerabilities
>>> which they then disclose in public after giving VSI time (about 3 months
>>> usually) to fix the vulnerabilities.
>>>
>>> Your last sentence above is a perfect example of the mindset I am
>>> warning about.
>>>
>>> Simon.
>>>
>>
>> Ok Simon, a question for you.
>>
>> Suppose someone finds a vulnerability in VAX/VMS V5.2H4, and that someone
>> knows that there is very little, or no, chance of a fix. And that someone
>> also is aware that some users are still using that old software.
>>
>> So now the moral question. Knowing there will not be a fix, and knowing that
>> exposure just might cause problems for said user running that old software, is
>> it Ok to expose the vulnerability?
>>
>
>
> Bad example. There is a fix. Move off of V5.2H4. And before
> you say they can't move, of course they can. The only limiting
> factor is probably cost and that's just a bad excuse for a business.
>
> bill
>

I do believe that I got the answers that I expected ...

David and Simon insist on making other people's decisions for them. Sort of
"devil take the hindmost" if their solutions are not followed. Even if there
are some who might be aware, publishing the problem will insure many will then
know about it. And it might be totally unknown, until David/Simon publish it to
the entire world.

As for Bill, he seems real good at "spending other people's money". Must be a
lawyer, those who "live off other people's money".

I asked from a moral perspective. So far I detect no sympathy for people who
might be in a bad place. I for one find that sad.

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

On 8/4/2022 10:53 AM, Mark Berryman wrote:
> On 8/3/22 11:30 AM, Simon Clubley wrote:
>> On 2022-08-03, abrsvc <dansabrservices@yahoo.com> wrote:
>>>
>>> The lack of support means nothing. In many cases, support was continued
>>> strictly for access to newer versions that often were never used. I new of
>>> many clients that remained at V7.3-2 for Alpha systems because it was stable
>>> and did what they needed with no problems at all. Moving to newer versions
>>> was a cost (validation work) that couldn't be justified since there were no
>>> benefits to the upgrade. I can cite other clients with different hardware
>>> and OS levels with similar status too. Stabile application software that does
>>> the job does not usually need newer OS versions. Compare the VMS environment
>>> with that of Windows where updates are constantly required because of the
>>> instability of the OS or external vulnerabilities that just don't exist for VMS.
>>
>> This isn't a discussion about the DCL vulnerability. It's a discussion
>> about what is likely to happen if security researchers take a serious
>> interest in probing VMS in general and find a series of vulnerabilities
>> which they then disclose in public after giving VSI time (about 3 months
>> usually) to fix the vulnerabilities.
>>
>> Your last sentence above is a perfect example of the mindset I am
>> warning about.
>
> Simon's assumption is that, because he found a vulnerability, there must be a
> multitude of other as yet undiscovered vulnerabilities lying in wait because VMS
> just hasn't seen the kind of security probing that other OSes have. He makes
> this assumption clear in many of his posts.
>
> His assumption is unfounded.

WHAT !!!

You think that anything Simon writes must have sound foundations?

I could probably sell you a few bridges ...

:-)

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

On 8/4/2022 10:12 AM, Dan Cross wrote:
> In article <62e9b4ec$0$699$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 8/2/2022 10:33 AM, Dan Cross wrote:
>>> In article <tc1d87$tnl$1@news.misty.com>,
>>> Johnny Billquist <bqt@softjar.se> wrote:
>>>> On 2022-07-26 13:32, Dan Cross wrote:
>>>>> But again, why should VSI care? They have nothing to do
>>>>> with VAX. If people started doing this for Alpha, Itanium
>>>>> or x86, I could see it since VSI has interest in those
>>>>> platforms. But VAX is explicitly out of their domain.
>>>>
>>>> I should point out that VSI have nothing to do with VAX out of choice.
>>>> They could technically make a VAX release if they wanted to. They do
>>>> have the rights, and the code.
>>>
>>> A fair point, but regardless, they have chosen not to care.
>>>
>>> It boggles my mind that people think that an organization that
>>> has explicitly declined to work with the VAX (for the very valid
>>> reasons mentioned elsewhere in this thread) would care if a few
>>> hobbyists run an OS, 20 years out of maintenance, they can't
>>> issue licenses for anyway.
>>>
>>> Maybe those people have the inside track with someone at at VSI
>>> who has told them that this is as big a deal as they are making
>>> it out to be, but I find that doubtful.
>>
>> It is quite common to suspect that people known to be willing to
>> break one law is more willing to break another law.
>>
>> Most people would not let their daughter go on a date with
>> a convicted bank robber - even though the daughter is obviously
>> not a bank.
>
> This is very much a strawman. A better analogy might be, if
> someone picks something out of the trash and gets it working
> again, is that technically theft?
>
> - Dan C.
>

Yes !!!

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

On 2022-08-04, Dave Froble <davef@tsoft-inc.com> wrote:
>
> David and Simon insist on making other people's decisions for them. Sort of
> "devil take the hindmost" if their solutions are not followed. Even if there
> are some who might be aware, publishing the problem will insure many will then
> know about it. And it might be totally unknown, until David/Simon publish it to
> the entire world.
>

No, Simon believes in following industry-standard protocols, which are
give the vendor 3 months to fix it and then reveal the details.

In the same way as it has become socially unacceptable to smoke in an
office environment, it has now become socially unacceptable for a vendor
not to fix a confirmed vulnerability within a reasonable amount of time.

This is a good thing.

Oh, and vulnerabilities very rarely exist only on one specific out of
support point release. They generally exist across of range of supported
and unsupported OS versions.

Would you deny the users of the supported OS versions a fix merely to
protect those who have chosen to remain on an old unsupported OS version ?

> As for Bill, he seems real good at "spending other people's money". Must be a
> lawyer, those who "live off other people's money".
>
> I asked from a moral perspective. So far I detect no sympathy for people who
> might be in a bad place. I for one find that sad.
>

These days, it is the responsibility of the organisation which has
chosen to remain on an old out of support OS version (for whatever
reason) to make sure there is enough protection around that system
to protect it from future vulnerabilities.

Simon.

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

On 8/4/2022 1:26 PM, Simon Clubley wrote:
> On 2022-08-04, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> David and Simon insist on making other people's decisions for them. Sort of
>> "devil take the hindmost" if their solutions are not followed. Even if there
>> are some who might be aware, publishing the problem will insure many will then
>> know about it. And it might be totally unknown, until David/Simon publish it to
>> the entire world.
>>
>
> No, Simon believes in following industry-standard protocols, which are
> give the vendor 3 months to fix it and then reveal the details.
>
> In the same way as it has become socially unacceptable to smoke in an
> office environment, it has now become socially unacceptable for a vendor
> not to fix a confirmed vulnerability within a reasonable amount of time.

Simon, what part of VAX/VMS V5.2.??? didn't you understand. Perhaps you need
some reading lessons?

Simon, WHAT VENDOR?

VSI doesn't do VAX, nor V5.???
HPe doesn't do VMS

You just keep on with your standard rhetoric, whether it makes any sense or not.

> This is a good thing.
>
> Oh, and vulnerabilities very rarely exist only on one specific out of
> support point release. They generally exist across of range of supported
> and unsupported OS versions.

You choose to ignore the specific question.

> Would you deny the users of the supported OS versions a fix merely to
> protect those who have chosen to remain on an old unsupported OS version ?

Not at all, if reported against the current release of VMS.

>> As for Bill, he seems real good at "spending other people's money". Must be a
>> lawyer, those who "live off other people's money".
>>
>> I asked from a moral perspective. So far I detect no sympathy for people who
>> might be in a bad place. I for one find that sad.
>>
>
> These days, it is the responsibility of the organisation which has
> chosen to remain on an old out of support OS version (for whatever
> reason) to make sure there is enough protection around that system
> to protect it from future vulnerabilities.

And from the likes of you, I guess ...

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

On 8/4/2022 11:56 AM, Dave Froble wrote:
> On 8/4/2022 10:12 AM, Dan Cross wrote:
>> In article <62e9b4ec$0$699$14726298@news.sunsite.dk>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 8/2/2022 10:33 AM, Dan Cross wrote:
>>>> In article <tc1d87$tnl$1@news.misty.com>,
>>>> Johnny Billquist <bqt@softjar.se> wrote:
>>>>> On 2022-07-26 13:32, Dan Cross wrote:
>>>>>> But again, why should VSI care? They have nothing to do
>>>>>> with VAX. If people started doing this for Alpha, Itanium
>>>>>> or x86, I could see it since VSI has interest in those
>>>>>> platforms. But VAX is explicitly out of their domain.
>>>>>
>>>>> I should point out that VSI have nothing to do with VAX out of choice.
>>>>> They could technically make a VAX release if they wanted to. They do
>>>>> have the rights, and the code.
>>>>
>>>> A fair point, but regardless, they have chosen not to care.
>>>>
>>>> It boggles my mind that people think that an organization that
>>>> has explicitly declined to work with the VAX (for the very valid
>>>> reasons mentioned elsewhere in this thread) would care if a few
>>>> hobbyists run an OS, 20 years out of maintenance, they can't
>>>> issue licenses for anyway.
>>>>
>>>> Maybe those people have the inside track with someone at at VSI
>>>> who has told them that this is as big a deal as they are making
>>>> it out to be, but I find that doubtful.
>>>
>>> It is quite common to suspect that people known to be willing to
>>> break one law is more willing to break another law.
>>>
>>> Most people would not let their daughter go on a date with
>>> a convicted bank robber - even though the daughter is obviously
>>> not a bank.
>>
>> This is very much a strawman. A better analogy might be, if
>> someone picks something out of the trash and gets it working
>> again, is that technically theft?
>>
>> - Dan C.
>>
>
> Yes !!!
>

Uh, not yes as in it is theft. Yes as in a great example. I should re-read
what I type several times before hitting the SEND button.

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

On 8/4/22 10:12, Dan Cross wrote:
> In article <62e9b4ec$0$699$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 8/2/2022 10:33 AM, Dan Cross wrote:
>>> In article <tc1d87$tnl$1@news.misty.com>,
>>> Johnny Billquist <bqt@softjar.se> wrote:
>>>> On 2022-07-26 13:32, Dan Cross wrote:
>>>>> But again, why should VSI care? They have nothing to do
>>>>> with VAX. If people started doing this for Alpha, Itanium
>>>>> or x86, I could see it since VSI has interest in those
>>>>> platforms. But VAX is explicitly out of their domain.
>>>>
>>>> I should point out that VSI have nothing to do with VAX out of choice.
>>>> They could technically make a VAX release if they wanted to. They do
>>>> have the rights, and the code.
>>>
>>> A fair point, but regardless, they have chosen not to care.
>>>
>>> It boggles my mind that people think that an organization that
>>> has explicitly declined to work with the VAX (for the very valid
>>> reasons mentioned elsewhere in this thread) would care if a few
>>> hobbyists run an OS, 20 years out of maintenance, they can't
>>> issue licenses for anyway.
>>>
>>> Maybe those people have the inside track with someone at at VSI
>>> who has told them that this is as big a deal as they are making
>>> it out to be, but I find that doubtful.
>>
>> It is quite common to suspect that people known to be willing to
>> break one law is more willing to break another law.
>>
>> Most people would not let their daughter go on a date with
>> a convicted bank robber - even though the daughter is obviously
>> not a bank.
>
> This is very much a strawman. A better analogy might be, if
> someone picks something out of the trash and gets it working
> again, is that technically theft?

Believe it or not, in this country, yes. It is either still the
property of the person who threw it out or it is the property of
the trash company why may make money recycling stuff they find
in the trash. But in either case it is not free to anyone who wants
to go dumpster diving. Much legal precedent supporting this.

bill

On 8/4/22 10:10, Dan Cross wrote:
>
> The bottom line is that absent some definitive statement from
> VSI, this is all speculation. Mentec was a different company.
> Also, didn't Mentec license RSTS prior to 9.6 for hobbyist use
> in 1997? And RSX-11M <= 4.3 and -11M Plus <= 3.0 in 1998?
>

Got a copy of that license anywhere? I didn't think so.
The only License ever put out by Mentec never allowed use
on real hardware and only applied to an emulator that
ceased to exist shortly thereafter. This did not stop
people from continuing to use it claiming the License
was still valid even though it didn't take a lawyer
to interpret as it was written in very plain English.

bill

On 8/4/22 15:01, Dave Froble wrote:
> On 8/4/2022 11:56 AM, Dave Froble wrote:
>> On 8/4/2022 10:12 AM, Dan Cross wrote:
>>> In article <62e9b4ec$0$699$14726298@news.sunsite.dk>,
>>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>>> On 8/2/2022 10:33 AM, Dan Cross wrote:
>>>>> In article <tc1d87$tnl$1@news.misty.com>,
>>>>> Johnny Billquist  <bqt@softjar.se> wrote:
>>>>>> On 2022-07-26 13:32, Dan Cross wrote:
>>>>>>> But again, why should VSI care?  They have nothing to do
>>>>>>> with VAX.  If people started doing this for Alpha, Itanium
>>>>>>> or x86, I could see it since VSI has interest in those
>>>>>>> platforms.  But VAX is explicitly out of their domain.
>>>>>>
>>>>>> I should point out that VSI have nothing to do with VAX out of
>>>>>> choice.
>>>>>> They could technically make a VAX release if they wanted to. They do
>>>>>> have the rights, and the code.
>>>>>
>>>>> A fair point, but regardless, they have chosen not to care.
>>>>>
>>>>> It boggles my mind that people think that an organization that
>>>>> has explicitly declined to work with the VAX (for the very valid
>>>>> reasons mentioned elsewhere in this thread) would care if a few
>>>>> hobbyists run an OS, 20 years out of maintenance, they can't
>>>>> issue licenses for anyway.
>>>>>
>>>>> Maybe those people have the inside track with someone at at VSI
>>>>> who has told them that this is as big a deal as they are making
>>>>> it out to be, but I find that doubtful.
>>>>
>>>> It is quite common to suspect that people known to be willing to
>>>> break one law is more willing to break another law.
>>>>
>>>> Most people would not let their daughter go on a date with
>>>> a convicted bank robber - even though the daughter is obviously
>>>> not a bank.
>>>
>>> This is very much a strawman.  A better analogy might be, if
>>> someone picks something out of the trash and gets it working
>>> again, is that technically theft?
>>>
>>>     - Dan C.
>>>
>>
>> Yes !!!
>>
>
> Uh, not yes as in it is theft.  Yes as in a great example.  I should
> re-read what I type several times before hitting the SEND button.
>

Sorry Dave, you were right the first time. It is theft and
has been upheld by the courts in most states.

bill

On 2022-08-04, Dave Froble <davef@tsoft-inc.com> wrote:
> On 8/4/2022 1:26 PM, Simon Clubley wrote:
>> On 2022-08-04, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> David and Simon insist on making other people's decisions for them. Sort of
>>> "devil take the hindmost" if their solutions are not followed. Even if there
>>> are some who might be aware, publishing the problem will insure many will then
>>> know about it. And it might be totally unknown, until David/Simon publish it to
>>> the entire world.
>>>
>>
>> No, Simon believes in following industry-standard protocols, which are
>> give the vendor 3 months to fix it and then reveal the details.
>>
>> In the same way as it has become socially unacceptable to smoke in an
>> office environment, it has now become socially unacceptable for a vendor
>> not to fix a confirmed vulnerability within a reasonable amount of time.
>
> Simon, what part of VAX/VMS V5.2.??? didn't you understand. Perhaps you need
> some reading lessons?
>
> Simon, WHAT VENDOR?
>
> VSI doesn't do VAX, nor V5.???
> HPe doesn't do VMS
>
> You just keep on with your standard rhetoric, whether it makes any sense or not.
>
>> This is a good thing.
>>
>> Oh, and vulnerabilities very rarely exist only on one specific out of
>> support point release. They generally exist across of range of supported
>> and unsupported OS versions.
>
> You choose to ignore the specific question.
>

Because the specific question doesn't make any sense and shows a lack
of understanding about how security research is done.

No security researcher looking for vulnerabilities in general would
start with a decades old version of VMS. They would start with the
current version and look for vulnerabilities in that version.

If they find something, they may choose to look at older versions to see
if it's in those versions as well, but it's the vendor's responsibility
to determine how far back a vulnerability goes.

The only time I can think of a security researcher looking at a specific
decades old version is if they have been commissioned to do so by
a client and then it's the client that sets the ground rules about
disclosure.

>>
>> These days, it is the responsibility of the organisation which has
>> chosen to remain on an old out of support OS version (for whatever
>> reason) to make sure there is enough protection around that system
>> to protect it from future vulnerabilities.
>
> And from the likes of you, I guess ...
>

That's extremely uncalled for David and I would like an apology for that.

Simon.

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

On 2022-08-04 12:32, Bill Gunshannon wrote:
> On 8/4/22 10:12, Dan Cross wrote:
>> In article <62e9b4ec$0$699$14726298@news.sunsite.dk>,
>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>> On 8/2/2022 10:33 AM, Dan Cross wrote:
>>>> In article <tc1d87$tnl$1@news.misty.com>,
>>>> Johnny Billquist  <bqt@softjar.se> wrote:
>>>>> On 2022-07-26 13:32, Dan Cross wrote:
>>>>>> But again, why should VSI care?  They have nothing to do
>>>>>> with VAX.  If people started doing this for Alpha, Itanium
>>>>>> or x86, I could see it since VSI has interest in those
>>>>>> platforms.  But VAX is explicitly out of their domain.
>>>>>
>>>>> I should point out that VSI have nothing to do with VAX out of choice.
>>>>> They could technically make a VAX release if they wanted to. They do
>>>>> have the rights, and the code.
>>>>
>>>> A fair point, but regardless, they have chosen not to care.
>>>>
>>>> It boggles my mind that people think that an organization that
>>>> has explicitly declined to work with the VAX (for the very valid
>>>> reasons mentioned elsewhere in this thread) would care if a few
>>>> hobbyists run an OS, 20 years out of maintenance, they can't
>>>> issue licenses for anyway.
>>>>
>>>> Maybe those people have the inside track with someone at at VSI
>>>> who has told them that this is as big a deal as they are making
>>>> it out to be, but I find that doubtful.
>>>
>>> It is quite common to suspect that people known to be willing to
>>> break one law is more willing to break another law.
>>>
>>> Most people would not let their daughter go on a date with
>>> a convicted bank robber - even though the daughter is obviously
>>> not a bank.
>>
>> This is very much a strawman.  A better analogy might be, if
>> someone picks something out of the trash and gets it working
>> again, is that technically theft?
>
> Believe it or not, in this country, yes.  It is either still the
> property of the person who threw it out or it is the property of
> the trash company why may make money recycling stuff they find
> in the trash. But in either case it is not free to anyone who wants
> to go dumpster diving.  Much legal precedent supporting this.
>
> bill
>

Not quite:

Dumpster diving is technically legal in all 50 states as long as it does not
conflict with any city, county, or state ordinances. When a trash bag is sitting
on the curb waiting to be picked up by a waste removal company, it becomes
public domain. Most garbage can be searched or taken by the police, a neighbor,
waste removal employees, or a stranger.

Research your state laws online to find helpful links to state and county
websites. From there, you can search for waste or garbage ordinances. The more
you know about these laws, the safer you will be. Think of dumpster diving laws
this way:

Federal law: Legal
State law: Legal
County law: It depends – do your research
City law: it depends – do your research
Restaurant or business-specific laws: it depends – do your research
Private property: Illegal
Warning signs or locks on the dumpster: Illegal

So if you put your VAX out at the curb in a public space I can take it and
it is not theft.

On 2022-08-04 13:19, Don North wrote:
> On 2022-08-04 12:32, Bill Gunshannon wrote:
>> On 8/4/22 10:12, Dan Cross wrote:
>>> This is very much a strawman.  A better analogy might be, if
>>> someone picks something out of the trash and gets it working
>>> again, is that technically theft?
>>
>> Believe it or not, in this country, yes.  It is either still the
>> property of the person who threw it out or it is the property of
>> the trash company why may make money recycling stuff they find
>> in the trash. But in either case it is not free to anyone who wants
>> to go dumpster diving.  Much legal precedent supporting this.
>>
>> bill
>>
>
> Not quite:
>
> Dumpster diving is technically legal in all 50 states as long as it does not
> conflict with any city, county, or state ordinances. When a trash bag is sitting
> on the curb waiting to be picked up by a waste removal company, it becomes
> public domain. Most garbage can be searched or taken by the police, a neighbor,
> waste removal employees, or a stranger.
>
> Research your state laws online to find helpful links to state and county
> websites. From there, you can search for waste or garbage ordinances. The more
> you know about these laws, the safer you will be. Think of dumpster diving laws
> this way:
>
>     Federal law: Legal
>     State law: Legal
>     County law: It depends – do your research
>     City law: it depends – do your research
>     Restaurant or business-specific laws: it depends – do your research
>     Private property: Illegal
>     Warning signs or locks on the dumpster: Illegal
>
> So if you put your VAX out at the curb in a public space I can take it and
> it is not theft.

In California, dumpster diving is technically not illegal according to a law
stemming from a 1988 Supreme Court ruling in California v. Greenwood which held
that when trash is discarded in a public place, there is no expectation of
privacy or ownership.

On 8/4/22 16:24, Don North wrote:
> On 2022-08-04 13:19, Don North wrote:
>> On 2022-08-04 12:32, Bill Gunshannon wrote:
>>> On 8/4/22 10:12, Dan Cross wrote:
>>>> This is very much a strawman.  A better analogy might be, if
>>>> someone picks something out of the trash and gets it working
>>>> again, is that technically theft?
>>>
>>> Believe it or not, in this country, yes.  It is either still the
>>> property of the person who threw it out or it is the property of
>>> the trash company why may make money recycling stuff they find
>>> in the trash. But in either case it is not free to anyone who wants
>>> to go dumpster diving.  Much legal precedent supporting this.
>>>
>>> bill
>>>
>>
>> Not quite:
>>
>> Dumpster diving is technically legal in all 50 states as long as it
>> does not conflict with any city, county, or state ordinances. When a
>> trash bag is sitting on the curb waiting to be picked up by a waste
>> removal company, it becomes public domain. Most garbage can be
>> searched or taken by the police, a neighbor, waste removal employees,
>> or a stranger.
>>
>> Research your state laws online to find helpful links to state and
>> county websites. From there, you can search for waste or garbage
>> ordinances. The more you know about these laws, the safer you will be.
>> Think of dumpster diving laws this way:
>>
>>      Federal law: Legal
>>      State law: Legal
>>      County law: It depends – do your research
>>      City law: it depends – do your research
>>      Restaurant or business-specific laws: it depends – do your research
>>      Private property: Illegal
>>      Warning signs or locks on the dumpster: Illegal
>>
>> So if you put your VAX out at the curb in a public space I can take it
>> and
>> it is not theft.
>
> In California, dumpster diving is technically not illegal according to a
> law stemming from a 1988 Supreme Court ruling in California v. Greenwood
> which held that when trash is discarded in a public place, there is no
> expectation of privacy or ownership.

OK, there is the conflict. I was dealing with things
like corporate trash that goes in the dumpster, not
house trash left on the curbside. But then, where I
live, trash is never left in the public domain. If it
were it would not get collected. I have to put my
trash and my recycling into cans that belong to the
garbage collection company so they are legally always
in someone's possession.

bill

On 8/4/22 14:58, Dave Froble wrote:
> On 8/4/2022 1:26 PM, Simon Clubley wrote:
>> On 2022-08-04, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> David and Simon insist on making other people's decisions for them.
>>> Sort of
>>> "devil take the hindmost" if their solutions are not followed.  Even
>>> if there
>>> are some who might be aware, publishing the problem will insure many
>>> will then
>>> know about it.  And it might be totally unknown, until David/Simon
>>> publish it to
>>> the entire world.
>>>
>>
>> No, Simon believes in following industry-standard protocols, which are
>> give the vendor 3 months to fix it and then reveal the details.
>>
>> In the same way as it has become socially unacceptable to smoke in an
>> office environment, it has now become socially unacceptable for a vendor
>> not to fix a confirmed vulnerability within a reasonable amount of time.
>
> Simon, what part of VAX/VMS V5.2.??? didn't you understand.  Perhaps you
> need some reading lessons?
>
> Simon, WHAT VENDOR?
>
> VSI doesn't do VAX, nor V5.???
> HPe doesn't do VMS
>
> You just keep on with your standard rhetoric, whether it makes any sense
> or not.

Due diligence says that in the more than 20 years since that
was supported they should have done something about it.

>
>> This is a good thing.
>>
>> Oh, and vulnerabilities very rarely exist only on one specific out of
>> support point release. They generally exist across of range of supported
>> and unsupported OS versions.
>
> You choose to ignore the specific question.
>
>> Would you deny the users of the supported OS versions a fix merely to
>> protect those who have chosen to remain on an old unsupported OS
>> version ?
>
> Not at all, if reported against the current release of VMS.
>
>>> As for Bill, he seems real good at "spending other people's money".
>>> Must be a
>>> lawyer, those who "live off other people's money".

I don't spend other people's money. But I have no sympathy for a
business that chooses to not spend their money making sure their
systems are OK. When did V5.2 go off support? No matter what it
does, a replacement could have been written in that time either on
VMS or on something else but there is no excuse for still running
something like that. It's just bad business practice.

>>>
>>> I asked from a moral perspective.  So far I detect no sympathy for
>>> people who
>>> might be in a bad place.  I for one find that sad.
>>>
>>
>> These days, it is the responsibility of the organisation which has
>> chosen to remain on an old out of support OS version (for whatever
>> reason) to make sure there is enough protection around that system
>> to protect it from future vulnerabilities.
>
> And from the likes of you, I guess ...

Ad hominem? He is right. This business has had plenty of time to
anticipate and correct the problem. The real question is why they
have chosen not to.

bill

On Thursday, August 4, 2022 at 4:48:23 PM UTC-4, Bill Gunshannon wrote:
> On 8/4/22 14:58, Dave Froble wrote:
> > On 8/4/2022 1:26 PM, Simon Clubley wrote:
> >> On 2022-08-04, Dave Froble <da...@tsoft-inc.com> wrote:
> >>>
> >>> David and Simon insist on making other people's decisions for them.
> >>> Sort of
> >>> "devil take the hindmost" if their solutions are not followed. Even
> >>> if there
> >>> are some who might be aware, publishing the problem will insure many
> >>> will then
> >>> know about it. And it might be totally unknown, until David/Simon
> >>> publish it to
> >>> the entire world.
> >>>
> >>
> >> No, Simon believes in following industry-standard protocols, which are
> >> give the vendor 3 months to fix it and then reveal the details.
> >>
> >> In the same way as it has become socially unacceptable to smoke in an
> >> office environment, it has now become socially unacceptable for a vendor
> >> not to fix a confirmed vulnerability within a reasonable amount of time.
> >
> > Simon, what part of VAX/VMS V5.2.??? didn't you understand. Perhaps you
> > need some reading lessons?
> >
> > Simon, WHAT VENDOR?
> >
> > VSI doesn't do VAX, nor V5.???
> > HPe doesn't do VMS
> >
> > You just keep on with your standard rhetoric, whether it makes any sense
> > or not.
> Due diligence says that in the more than 20 years since that
> was supported they should have done something about it.
> >
> >> This is a good thing.
> >>
> >> Oh, and vulnerabilities very rarely exist only on one specific out of
> >> support point release. They generally exist across of range of supported
> >> and unsupported OS versions.
> >
> > You choose to ignore the specific question.
> >
> >> Would you deny the users of the supported OS versions a fix merely to
> >> protect those who have chosen to remain on an old unsupported OS
> >> version ?
> >
> > Not at all, if reported against the current release of VMS.
> >
> >>> As for Bill, he seems real good at "spending other people's money".
> >>> Must be a
> >>> lawyer, those who "live off other people's money".
> I don't spend other people's money. But I have no sympathy for a
> business that chooses to not spend their money making sure their
> systems are OK. When did V5.2 go off support? No matter what it
> does, a replacement could have been written in that time either on
> VMS or on something else but there is no excuse for still running
> something like that. It's just bad business practice.
> >>>
> >>> I asked from a moral perspective. So far I detect no sympathy for
> >>> people who
> >>> might be in a bad place. I for one find that sad.
> >>>
> >>
> >> These days, it is the responsibility of the organisation which has
> >> chosen to remain on an old out of support OS version (for whatever
> >> reason) to make sure there is enough protection around that system
> >> to protect it from future vulnerabilities.
> >
> > And from the likes of you, I guess ...
> Ad hominem? He is right. This business has had plenty of time to
> anticipate and correct the problem. The real question is why they
> have chosen not to.
>
> bill
I would take a different approach. If the system is working and working well in what seems to be a secure environment, why would I "upgrade" to a system that is more likely than not, less secure than what I have?

A backend system processing information sent over a single secure line from a front facing system where the environment is less secure works just fine.. If there is no way to get to the backend system other than the pipe from the front end, where is the security hole? Could a malformed packet cause a problem, sure but compromise the data on the backend, not likely. In this case, it wouldn't make a difference how old the system is.

In the emulated environment, it is the host that has the security problems and not the OpenVMS system. Odd, no?

On Thursday, August 4, 2022 at 2:22:37 PM UTC-7, abrsvc wrote:

(snip)

> In the emulated environment, it is the host that has the security problems and not the OpenVMS system. Odd, no?

One of the more interesting, or maybe just more surprising, attacks is SQL injection.

Many attacks convince a machine to run some executable code, but SQL injection is done at a higher level.

I have had web sites return SQL error messages before, which is sort of funny.

In article <tcgp5e$2rgld$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>[snip]
>I asked from a moral perspective. So far I detect no sympathy for people who
>might be in a bad place. I for one find that sad.

The thing is, those folks are in a bad place whether they know
it or not. Ancient versions of VMS probably have exploitable
flaws that are known to state-level actors and others beyond the
script-kiddies. Just because the operator of some application
hosted on some ancient version of VMS doesn't know that doesn't
make them safe. They may exist in a state of blissful ignorance
and still be vulnerable.

Now the calculus changes: is it better for the flaws to be known
publicly or not, given that they may exist and may be actively
exploitable? Would you rather know you had terminal cancer? Is
it moral for a doctor to tell you?

- Dan C.

On 2022-08-04 13:39, Bill Gunshannon wrote:
> On 8/4/22 16:24, Don North wrote:
>> On 2022-08-04 13:19, Don North wrote:
>>> On 2022-08-04 12:32, Bill Gunshannon wrote:
>>>> On 8/4/22 10:12, Dan Cross wrote:
>>>>> This is very much a strawman.  A better analogy might be, if
>>>>> someone picks something out of the trash and gets it working
>>>>> again, is that technically theft?
>>>>
>>>> Believe it or not, in this country, yes.  It is either still the
>>>> property of the person who threw it out or it is the property of
>>>> the trash company why may make money recycling stuff they find
>>>> in the trash. But in either case it is not free to anyone who wants
>>>> to go dumpster diving.  Much legal precedent supporting this.
>>>>
>>>> bill
>>>>
>>>
>>> Not quite:
>>>
>>> Dumpster diving is technically legal in all 50 states as long as it does not
>>> conflict with any city, county, or state ordinances. When a trash bag is
>>> sitting on the curb waiting to be picked up by a waste removal company, it
>>> becomes public domain. Most garbage can be searched or taken by the police, a
>>> neighbor, waste removal employees, or a stranger.
>>>
>>> Research your state laws online to find helpful links to state and county
>>> websites. From there, you can search for waste or garbage ordinances. The
>>> more you know about these laws, the safer you will be. Think of dumpster
>>> diving laws this way:
>>>
>>>      Federal law: Legal
>>>      State law: Legal
>>>      County law: It depends – do your research
>>>      City law: it depends – do your research
>>>      Restaurant or business-specific laws: it depends – do your research
>>>      Private property: Illegal
>>>      Warning signs or locks on the dumpster: Illegal
>>>
>>> So if you put your VAX out at the curb in a public space I can take it and
>>> it is not theft.
>>
>> In California, dumpster diving is technically not illegal according to a law
>> stemming from a 1988 Supreme Court ruling in California v. Greenwood which
>> held that when trash is discarded in a public place, there is no expectation
>> of privacy or ownership.
>
>
> OK, there is the conflict.  I was dealing with things
> like corporate trash that goes in the dumpster, not
> house trash left on the curbside.  But then, where I
> live, trash is never left in the public domain.  If it
> were it would not get collected.  I have to put my
> trash and my recycling into cans that belong to the
> garbage collection company so they are legally always
> in someone's possession.
>
> bill

If you put those cans out by the street they become public domain.
Unless you have locks on the cans. Not likely.

If the trash company must enter your property to collect, then not.

Redirect complaints to SCOTUS.