[Info-vax] DCL vulnerability write up on The Register

[Bill Gunshannon]

On 02/10/2018 08:25 AM, Kerry Main wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of Bill
>> Gunshannon via Info-vax
>> Sent: February 10, 2018 7:31 AM
>> To: info-vax at rbnsn.com
>> Cc: Bill Gunshannon <bill.gunshannon at gmail.com>
>> Subject: Re: [Info-vax] DCL vulnerability write up on The Register
>>
>> On 02/09/2018 10:31 PM, Kerry Main wrote:
>>>> -----Original Message-----
>>>> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
>>>> DaveFroble via Info-vax
>>>> Sent: February 9, 2018 1:50 AM
>>>> To: info-vax at rbnsn.com
>>>> Cc: DaveFroble <davef at tsoft-inc.com>
>>>> Subject: Re: [Info-vax] DCL vulnerability write up on The Register
>>>>
>>>> terry-groups at glaver.org wrote:
>>>>> On Thursday, February 8, 2018 at 12:29:52 PM UTC-5, Stephen
>> Hoffman
>>>> wrote:
>>>>>> HPE transitioned OpenVMS Alpha into mature support — that's
>> HPE-
>>>> speak
>>>>>> for "no patches" — over a year ago.
>>>>>
>>>>> If I were paying HPE for support, I'd really have to question what
>> type
>>>> of "support" they were providing if they declined to produce a patch
>> for
>>>> a known CVE, particularly when they seem to know what the fix
>> entails.
>>>> Perhaps HPE "support" just means access to the library of out-of-
>> date,
>>>> no-longer updated patches, plus occasional "reading service" to tell
>> the
>>>> user that something is in the manual? Perhaps they should reduce
>> their
>>>> support pricing to reflect the reality of the "support" they are
>> providing...
>>>>
>>>> If you were paying HPE for VMS support on Alpha, you'd be an idiot,
>> or
>>>> worse.  I
>>>> certainly hope nobody fits into this catagory.
>>>>
>>>
>>> Lets not forget that some larger companies have policies that state ALL
>> servers (esp. prod) MUST have support contracts in place. It is a risk
>> mitigation strategy i.e. a single throat to choke.
>>>
>>> In the big scheme of Operations support contracts, I highly doubt that
>> even over priced Alpha support contracts is barely even a rounding error
>> compared to what most companies pay annually in support contracts to
>> Red Hat, Microsoft and/or Oracle.
>>>
>>
>> Yes, but they actually get something for their money from them.
>> Any CIO who pays for support for a system the vendor says they will
>> not support should be fired for incompetence.
>>
>> bill
> 
> You obviously have much higher view of support from companies like Oracle than I do.

As compared to HPE who sells support contracts for systems they openly
advertise that they do not support.

> 
> At a prior site I was at, the DBA's logging a call with Oracle was a last resort to get a log number and keep their senior mgrs. off their back. However, the local DBA's rarely received what they were looking for.

Would need a lot more information on the case to decide if there really
was a problem that was Oracles or something else.

Reminds me of a problem from my Primos days.  Complaint was that
Fortran programs comparing two real numbers were never found to
be equal.

    R1 = 1.2345 + 5.4321
    R2 = 4.4444 + 2.2222

    IF (R1 .EQ. R2) THEN
       was never true....

The reason is you can't compare real numbers for equality.  You
would have thought mathematicians would have known that, but no.
The fix was to put a message int he compiler stating "Real numbers
can not be compared for equality."

So, what wold yo consider this?  The customer did not receive what
they wanted. But the problem was solved.

> 
> I am sure the same could be stated for many Customers view of MS support. Have not really dealt with RH, so cant say about them.

Never had a problem with MS support.  But then I never went to them with
a stupid request.  I, too, have never used RH support as I am more than
qualified myself to handle any Unix problems.

> 
> Certainly not trying to defend HPE's patch policies, but the hidden nugget is that if HPE patches get further and further behind, it will be more incentive for those Customers to jump to VSI.
> 

But using the logic presented in this group, regardless of how bad the
support is you should never consider changing anything.

bill