Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

VMS Hobbyist Licence - Heads Up

291 views
Skip to first unread message

Simon Clubley

unread,
Jun 23, 2017, 5:06:07 PM6/23/17
to
I've just had my hobbyist licence renewal rejected because I only
filled in fields which were marked as required.

In particular, HPE want to know what you wish to use the Hobbyist
licence for even though that field is not marked as required for me.

This was the response to my request which I received from Mandar:

|Hi,
|
|Please resubmit the request after filling in all the fields including usage
|details. This helps us understand how you plan to use Hobbyist license PAKs.
|
|Regards
|Mandar

I hope this heads up saves someone the round-trip delay of having
to submit a second hobbyist licence request. :-)

Simon.

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

Steven Schweda

unread,
Jun 23, 2017, 9:56:48 PM6/23/17
to
> I hope this heads up saves someone the round-trip delay of having
> to submit a second hobbyist licence request. :-)

Readers whose heads were up might have noticed a similar
report in May:

https://groups.google.com/forum/#!topic/comp.os.vms/SXM6WTPxX6k

johnwa...@yahoo.co.uk

unread,
Jun 24, 2017, 4:39:14 AM6/24/17
to
Might be best not to put "security research" in the usage field, or
alarm bells may ring somewhere.

Then again...

Paul Sture

unread,
Jun 24, 2017, 9:30:52 AM6/24/17
to
On 2017-06-23, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> I've just had my hobbyist licence renewal rejected because I only
> filled in fields which were marked as required.
>
> In particular, HPE want to know what you wish to use the Hobbyist
> licence for even though that field is not marked as required for me.
>
> This was the response to my request which I received from Mandar:
>
>|Hi,
>|
>|Please resubmit the request after filling in all the fields including usage
>|details. This helps us understand how you plan to use Hobbyist license PAKs.
>|
>|Regards
>|Mandar
>
> I hope this heads up saves someone the round-trip delay of having
> to submit a second hobbyist licence request. :-)

Jason Howe reported this a month ago[1], and following his implied advice,
I filled this section in during my recent Hobbyist registration request,
with success.


[1]
> From: Jason Howe
> Newsgroups: comp.os.vms
> Subject: hobbyist registration
> Date: Fri, 19 May 2017 17:58:12 -0000 (UTC)
>
> Just got a mildly annoying response back from HPE after filling out my
> Hobbyist Registration form.
>
> Apparently I missed the (non required) field for "usage details".
>
> The message back was please resubmit, filling out all the fields,
> including usage details.
>
> I have no problem with this, but I did let the gentleman know that
> they should probably make that a required field on the form since it
> seems to be a requirement.



--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.


John H. Reinhardt

unread,
Jun 24, 2017, 4:37:35 PM6/24/17
to
Whew... I knew that. I was worried they were going away...

Simon Clubley

unread,
Jun 24, 2017, 4:49:41 PM6/24/17
to
On 2017-06-24, Paul Sture <nos...@sture.ch> wrote:
> On 2017-06-23, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>> I hope this heads up saves someone the round-trip delay of having
>> to submit a second hobbyist licence request. :-)
>
> Jason Howe reported this a month ago[1], and following his implied advice,
> I filled this section in during my recent Hobbyist registration request,
> with success.
>

Thank you Steven and Paul for pointing me to Jason's message.

It would be nice if HPE fixed the form however.

Thanks,

Simon Clubley

unread,
Jun 24, 2017, 5:19:04 PM6/24/17
to
On 2017-06-24, johnwa...@yahoo.co.uk <johnwa...@yahoo.co.uk> wrote:
>
> Might be best not to put "security research" in the usage field, or
> alarm bells may ring somewhere.
>

Actually I did mention that because I wondered if they monitor comp.os.vms
and already knew about my interests in that area. I also wanted to make
it explicit that I would follow industry standard responsible disclosure
protocols by default if I ever did find something and would only do
a more immediate disclosure under special circumstances.

> Then again...

Unlike VSI, HPE actually do have a secure public security vulnerability
reporting process so they must be well used to this whole process.

I thought I was being helpful and reassuring by mentioning this and
making it explicit that I would follow the responsible disclosure
process by default.

However, you now have me thinking about this. All I can say is that
if I am denied the hobbyist licences because of this then that will
say a great detail about the mindset with HPE's VMS Engineering.

Simon Clubley

unread,
Jun 24, 2017, 5:20:17 PM6/24/17
to
On 2017-06-24, John H. Reinhardt <johnhre...@yahoo.com> wrote:
>
> Whew... I knew that. I was worried they were going away...

Sorry. :-) I was just trying to be helpful...

David Froble

unread,
Jun 24, 2017, 8:43:48 PM6/24/17
to
Simon Clubley wrote:
> On 2017-06-24, johnwa...@yahoo.co.uk <johnwa...@yahoo.co.uk> wrote:
>> Might be best not to put "security research" in the usage field, or
>> alarm bells may ring somewhere.
>>
>
> Actually I did mention that because I wondered if they monitor comp.os.vms
> and already knew about my interests in that area. I also wanted to make
> it explicit that I would follow industry standard responsible disclosure
> protocols by default if I ever did find something and would only do
> a more immediate disclosure under special circumstances.

Simon, we've "discussed" this before. I'm sure we won't find "common ground".
Regardless, I've a small question for you.

You're asking HPE for a free copy of VMS, and in doing so, you're telling them
that if you find a vulnerability, you're going to announce it, regardless of
HPE's desires? That you just may cause one of their paying customers to suffer
injury?

Now, you can spout "industry standard", as if there was some actual such thing,
but, it just doesn't matter. You want HPE to give you help in possibly harming
one of their customers. You've declared you'd do so.

If I was HPE, I'd tell you to pound salt up your ....

Simon Clubley

unread,
Jun 25, 2017, 2:41:23 AM6/25/17
to
On 2017-06-24, David Froble <da...@tsoft-inc.com> wrote:
> Simon Clubley wrote:
>>
>> Actually I did mention that because I wondered if they monitor comp.os.vms
>> and already knew about my interests in that area. I also wanted to make
>> it explicit that I would follow industry standard responsible disclosure
>> protocols by default if I ever did find something and would only do
>> a more immediate disclosure under special circumstances.
>
> Simon, we've "discussed" this before. I'm sure we won't find "common ground".
> Regardless, I've a small question for you.
>
> You're asking HPE for a free copy of VMS, and in doing so, you're telling them
> that if you find a vulnerability, you're going to announce it, regardless of
> HPE's desires? That you just may cause one of their paying customers to suffer
> injury?
>

It's called helping the VMS community by forcing the vendor to fix
a security problem and warning the community if the vendor doesn't
fix the problem after a reasonable period of time.

Not telling the community only creates a false sense of security because
if a "good" person can find the problem then so can a "bad" person.

The security vulnerability you don't know about is far worse than the
security vulnerability you do know about. HPE's customers could quite
easily receive a far greater "injury" if the problem isn't fixed or
warned about in a reasonable amount of time.

> Now, you can spout "industry standard", as if there was some actual such thing,
> but, it just doesn't matter. You want HPE to give you help in possibly harming
> one of their customers. You've declared you'd do so.
>

Just because you are not familiar with something doesn't mean it doesn't
actually exist.

A simple Google search for "responsible disclosure" would have revealed
that this indeed is an industry standard disclosure model.

I encourage you to do this search and read a sample of some of the
results. It might help you to understand how _why_ responsible
disclosure exists and how vastly out of touch you are with your
viewpoints.

Some reading:

https://en.wikipedia.org/wiki/Responsible_disclosure
http://www.cert.org/vulnerability-analysis/vul-disclosure.cfm?

This is real David, it is an industry standard, and it exists because
the alternatives are far, far, worse.

David Froble

unread,
Jun 25, 2017, 8:32:06 AM6/25/17
to
Simon Clubley wrote:
> On 2017-06-24, David Froble <da...@tsoft-inc.com> wrote:
>> Simon Clubley wrote:
>>> Actually I did mention that because I wondered if they monitor comp.os.vms
>>> and already knew about my interests in that area. I also wanted to make
>>> it explicit that I would follow industry standard responsible disclosure
>>> protocols by default if I ever did find something and would only do
>>> a more immediate disclosure under special circumstances.
>> Simon, we've "discussed" this before. I'm sure we won't find "common ground".
>> Regardless, I've a small question for you.
>>
>> You're asking HPE for a free copy of VMS, and in doing so, you're telling them
>> that if you find a vulnerability, you're going to announce it, regardless of
>> HPE's desires? That you just may cause one of their paying customers to suffer
>> injury?
>>
>
> It's called helping the VMS community by forcing the vendor to fix
> a security problem and warning the community if the vendor doesn't
> fix the problem after a reasonable period of time.

I don't dispute that finding and fixing vulnerabilities is a good thing.

> Not telling the community only creates a false sense of security because
> if a "good" person can find the problem then so can a "bad" person.
>
> The security vulnerability you don't know about is far worse than the
> security vulnerability you do know about. HPE's customers could quite
> easily receive a far greater "injury" if the problem isn't fixed or
> warned about in a reasonable amount of time.
>
>> Now, you can spout "industry standard", as if there was some actual such thing,
>> but, it just doesn't matter. You want HPE to give you help in possibly harming
>> one of their customers. You've declared you'd do so.
>>
>
> Just because you are not familiar with something doesn't mean it doesn't
> actually exist.
>
> A simple Google search for "responsible disclosure" would have revealed
> that this indeed is an industry standard disclosure model.

There are lots of things to be found on the internet. Doesn't mean they all
amount to anything.

> I encourage you to do this search and read a sample of some of the
> results. It might help you to understand how _why_ responsible
> disclosure exists and how vastly out of touch you are with your
> viewpoints.

Perhaps, and perhaps not.

But, none of this discussion really matters. The issue is using the hobbyist
program to possibly harm a paying VMS customer. Just because you claim you're
not doing harm doesn't mean that you are not. It's not your decision to make.
It's HPE's decision to make.

If I was running the hobbyist program, I'd require that if a hobbyist found a
vulnerability, it would be reported to HPE, and that it would not be revealed
until and unless HPE had already revealed it. This would be a legal agreement.
If you didn't agree with the policy, then you don't need to be given a free
copy of VMS to "hobby" with.

Simon Clubley

unread,
Jun 25, 2017, 9:07:42 AM6/25/17
to
On 2017-06-25, David Froble <da...@tsoft-inc.com> wrote:
>
> But, none of this discussion really matters. The issue is using the hobbyist
> program to possibly harm a paying VMS customer. Just because you claim you're
> not doing harm doesn't mean that you are not. It's not your decision to make.
> It's HPE's decision to make.
>

We tried the "let the vendor control the release schedule" thing.

There's a very good reason why it was replaced with the "security
researcher controls the release schedule" thing.

IOW, the vendor's goals here are not the same as the customer's goals.

> If I was running the hobbyist program, I'd require that if a hobbyist found a
> vulnerability, it would be reported to HPE, and that it would not be revealed
> until and unless HPE had already revealed it. This would be a legal agreement.
> If you didn't agree with the policy, then you don't need to be given a free
> copy of VMS to "hobby" with.

I wouldn't recommend HPE (or VSI) tries that in 2017...

IanD

unread,
Jun 26, 2017, 4:08:19 PM6/26/17
to
Look at how fast Linux patches issues, all in the face of public scrutiny. They have embraced open public feedback as the quickest way to escalate important security issues

Microsoft are now not far behind and have gone down the open disclosure path

Public disclosure of security issues has multiple effects

1. It creates customer awareness of the severity of the issue and from that they can quickly assess if they are exposed

2. It keeps vendors on their toes and ensures they cannot simply brush it under the table waiting for a critical mass of customers to report it before acting (i.e it tempers bean counters involvement)

3. It acts as an external audit

Rather than people whinging and bitching over security vonrabilities being made public, which is nothing more than hoping no one sees your dirty laundry being aired, how about spending the time and effort into fast frictionless reporting processes of the same so that the community can provide the quickest feedback possible and have that information broadcast in increasing circles of notification as quickly as possible?

Maybe, just maybe, OpenVMS may take back the security crown doing these sorts of things

A security problem left open because some vendor tried to quell a known issue through trying to restrict the information flow is a vendor who's storing up a whole lot of hurt for their product and their customers

The public are moving on from looking down their nose at systems with security issues to accepting that staying secure is a vision and something in constant flux as long as those system vendors are seen to act quickly when an issue is raised. People expect live protection, ongoing protection, they realise it's a moving target now. They are looking to their vendors to act as quickly as possible to a raised issue, they don't care who reported it, they care that it gets fixed ASAP

It's not about waiting for some vendor to announce they have found something, it's about using a 360 degree model to be notified of issues ASAP. Who gives a toss where the vulnerability is announced from, what's important is being notified as quickly as possible and then have your vendor patch it as quick as possible to reduce your exposure

HP imo went totally the wrong way with removing VMS patches. They removed the ability of the community to report back issues found which ultimately turned the hobbyist program into pretty much a useless source for real world testing (i.e. I've seen plenty of posts from hobbyists saying they found a bug only to have someone tell them that was fixed in patch xyz). The community is the greatest testing ground ever. Learn from Google!!!

VMS and the mindset of some of its community really needs to move on from the notion that "Security by Obseurity" is a good model. It's not, the world is a hell of a lot more sophisticated than that now and anyone pushing that model clearly is out of touch with the security landscape out there

VMS needs to rebuild it's security model from the ground up, including reporting tracks and fast and open rapid security information dissemination.

Look how long unencrypted SCS traffic has existed for!
This sort of crap should have been fixed donkeys years ago but has persisted longer than it should have because of complancy of vendors and customers and because the vendor drove the pace of security and not the customer nor the market place

Time to move on and create a culture of security where securitu issues are given top priority and where the VMS community and open feedback are seen as the driving force behind securing VMS systems

You won't do this if information is squirreled away in some secret dossier that only gets revealed to secret squirrel members who promise only to whisper to others who can perform the secret squirrel handshake

VMS and it's community should be the source of security dissemination and onlookers could be looking in saying "shit, that VMS OS and it's community certainly know security, wish our OS could do that...". This could be a differentiator

Or we can continue to live in the VMS "security library", you know, "shhhh, don't say that out loud, sometime might hear VMS has a security issue". *sigh*

Maybe one day we can say things like...

VMS, Security Secured through Community

Chris

unread,
Jun 26, 2017, 6:20:06 PM6/26/17
to
On 06/23/17 21:02, Simon Clubley wrote:
> I've just had my hobbyist licence renewal rejected because I only
> filled in fields which were marked as required.
>
> In particular, HPE want to know what you wish to use the Hobbyist
> licence for even though that field is not marked as required for me.
>
> This was the response to my request which I received from Mandar:
>
> |Hi,
> |
> |Please resubmit the request after filling in all the fields including usage
> |details. This helps us understand how you plan to use Hobbyist license PAKs.
> |
> |Regards
> |Mandar
>
> I hope this heads up saves someone the round-trip delay of having
> to submit a second hobbyist licence request. :-)
>
> Simon.
>

Simon,

Sorry, but you seem to be getting a bit paranoid about this. Just
fill in all the fields, then see what happens. Hobbyist licenses
are a privilege, not a right...

Chris

Simon Clubley

unread,
Jun 26, 2017, 8:00:26 PM6/26/17
to
On 2017-06-26, Chris <xxx.sys...@gfsys.co.uk> wrote:
>
> Simon,
>
> Sorry, but you seem to be getting a bit paranoid about this. Just
> fill in all the fields, then see what happens. Hobbyist licenses
> are a privilege, not a right...
>
> Chris

Hello Chris,

If you read the rest of the thread you will see that's exactly what
I did once I was told the optional field wasn't optional after all. :-)

Chris

unread,
Jun 26, 2017, 8:03:08 PM6/26/17
to
On 06/26/17 23:56, Simon Clubley wrote:
> On 2017-06-26, Chris<xxx.sys...@gfsys.co.uk> wrote:
>>
>> Simon,
>>
>> Sorry, but you seem to be getting a bit paranoid about this. Just
>> fill in all the fields, then see what happens. Hobbyist licenses
>> are a privilege, not a right...
>>
>> Chris
>
> Hello Chris,
>
> If you read the rest of the thread you will see that's exactly what
> I did once I was told the optional field wasn't optional after all. :-)
>
> Simon.
>

Fine, just seemed like you were thinking they were out to get you for
criticising the coffee :-)...

Chris

Simon Clubley

unread,
Jun 27, 2017, 5:16:59 PM6/27/17
to
On 2017-06-26, IanD <iloveo...@gmail.com> wrote:
>
> Rather than people whinging and bitching over security vonrabilities
> being made public, which is nothing more than hoping no one sees your dirty
> laundry being aired, how about spending the time and effort into fast
> frictionless reporting processes of the same so that the community can
> provide the quickest feedback possible and have that information broadcast
> in increasing circles of notification as quickly as possible?
>

It also forces people to adopt real security processes instead of just
sticking their head in the sand and pretending there are no security
issues with their systems.

That in itself makes the overall ecosystem more secure because people
are either forced to update their existing systems or to replace them
with systems that can be patched to remove the vulnerability.

As I have said before, if a "good" person can find a problem then so
can a "bad" person, especially when VMS becomes available on commonly
available hardware.

>
> A security problem left open because some vendor tried to quell a known
> issue through trying to restrict the information flow is a vendor who's
> storing up a whole lot of hurt for their product and their customers
>

I agree very strongly with this.

BTW, I now have my licences so thanks to everyone for their comments.

David Froble

unread,
Jun 27, 2017, 6:15:10 PM6/27/17
to
What? You're thanking me for my comments? Interesting ....

Let me throw another scenario at you, one that I'm sure exists at more than one
user site.

Say some site is still running an old version of VMS. V6.2, V7.2, whatever, but
a version that is no longer supported. Also say that for whatever reason, and
it doesn't matter what reason, the site just cannot upgrade the OS version.

Then you find a vulnerability. One that affects all versions of VMS. You
report it, and a fix is promptly developed and distributed to everyone running
the latest version, and whatever earlier versions still under support, or even
versions where the fix can be used. However, the fix will not work with say
V6.2, and VSI / HPE says to you, "These customers cannot upgrade, and there is
no fix for the vulnerability for them. They have been notified. Please for
their sake do not disclose the vulnerability."

What would you do?

Simon Clubley

unread,
Jun 27, 2017, 6:57:40 PM6/27/17
to
On 2017-06-27, David Froble <da...@tsoft-inc.com> wrote:
> Simon Clubley wrote:
>>
>> BTW, I now have my licences so thanks to everyone for their comments.
>>
>
> What? You're thanking me for my comments? Interesting ....
>

I obviously mentally filtered you out David. :-)

> Let me throw another scenario at you, one that I'm sure exists at more than one
> user site.
>
> Say some site is still running an old version of VMS. V6.2, V7.2, whatever, but
> a version that is no longer supported. Also say that for whatever reason, and
> it doesn't matter what reason, the site just cannot upgrade the OS version.
>
> Then you find a vulnerability. One that affects all versions of VMS. You
> report it, and a fix is promptly developed and distributed to everyone running
> the latest version, and whatever earlier versions still under support, or even
> versions where the fix can be used. However, the fix will not work with say
> V6.2, and VSI / HPE says to you, "These customers cannot upgrade, and there is
> no fix for the vulnerability for them. They have been notified. Please for
> their sake do not disclose the vulnerability."
>
> What would you do?

After the patch has been released and hence the disclosure waiting
period has expired then the vulnerability gets released, end of story,
unless an additional _short_ extension period, in addition to the one
detailed below, is requested while the sites in question implement
additional security measures. If the latter request was made of me,
I would probably go along with it.

You should also be aware that I have decided that if I ever did find
something, then there would be a short period anyway after the patch
was released (up to about a month) before the details were released.

This additional time is to allow people a short period of time to
install the patch in a controlled manner instead of them having to
race to install patches on the same day as the details become available.

The one thing I can't seem to make you understand David is that this
is not some exclusive-or situation. Both the "good" people and the "bad"
people can know about the same vulnerability at the same time.

People also know that there's a vulnerability to be found because
it's now in a MUP patch for the currently supported customers.

If releasing the vulnerability information after the patch becomes
available causes them security problems which they cannot resolve,
then they were wide open from a security viewpoint anyway.

This is exactly the same problem as those who are continuing to run
Windows XP systems in production in 2017. If you have not isolated
your XP machines from the wider Internet or your own internal networks,
then you are being grossly irresponsible by running a known insecure
version of an operating system on your network.

Stephen Hoffman

unread,
Jun 27, 2017, 7:08:08 PM6/27/17
to
On 2017-06-27 22:15:06 +0000, David Froble said:

> Let me throw another scenario at you, one that I'm sure exists at more
> than one user site.
>
> Say some site is still running an old version of VMS. V6.2, V7.2,
> whatever, but a version that is no longer supported. Also say that for
> whatever reason, and it doesn't matter what reason, the site just
> cannot upgrade the OS version.
>
> Then you find a vulnerability. One that affects all versions of VMS.
> You report it, and a fix is promptly developed and distributed to
> everyone running the latest version, and whatever earlier versions
> still under support, or even versions where the fix can be used.
> However, the fix will not work with say V6.2, and VSI / HPE says to
> you, "These customers cannot upgrade, and there is no fix for the
> vulnerability for them. They have been notified. Please for their
> sake do not disclose the vulnerability."
>
> What would you do?


Disclose. These folks are already scrod, as the patches will
routinely get reversed, and it's getting easier to do that reversing.

Yes, more than a few of us do remember when this stuff was secret, when
reversing was rare and difficult, and when servers were isolated and
internal networks were secure and we didn't have need to rapidly
install security patches. I'd prefer to be back when we didn't have
to lock down the firewalls and the internal networks until the vendors
got the malware reversed and the patch available and distributed, too.

Among others...
http://www.capstone-engine.org
https://hex-rays.com
Etc.


--
Pure Personal Opinion | HoffmanLabs LLC

0 new messages