[Info-vax] OpenSSL CSWS-2.2-1

[Stephen Hoffman]

On 2019-06-05 05:37:05 +0000, Dave Froble said:

> You're missing the point.  If a significant part of some companies 
> business is with a trading partner who will not upgrade their SSL 
> capabilities, and you have no way to get them to change, then, you do 
> what you have to do to stay in business.
> 
> Most of your arguments are good, but, when the alternatives are "stay 
> in business" or "go out of business", the choice is easy, at least for 
> me.


These companies that are both buying support and that are rolling out 
OpenVMS and layered product upgrades, but that are also not 
particularly maintaining their own code?  That's not going to be a 
growing market.  Or one with much funding.

Given: OpenSSL isn't going to stop tweaking APIs with future releases.  
Other products and other APIs will have similar issues, such as with 
requiring particular and longer certificates.

Let those companies stay on older OpenVMS releases for the duration of 
some hypothetical long-term-support LTS-style support offering.  And 
specifically with an old OpenSSL, these companies can't fix a flunked 
audit without some app-level work, which means they're already well on 
their way to maintenance or to outsourcing or to gone, or well on their 
way to eventually flunking some audit or some review, and then funding 
an upgrade or a port.  Let these companies then figure out how to link 
their own OpenSSL port.   Or let these companies pay more for the older 
OpenSSL.  Either of these on the off chance these companies decide to 
fund an upgrade or a port.

Preferably, give the folks a networking API that allows us to expunge 
our pages and pages of existing IPv4 and IPv6 and DNS and TLS and 
certificate-related code, as a path for folks needing SSL upgrades, and 
as a foundation for new apps and for porting.  And for better 
capabilities and security.  This also makes future software upgrades 
somewhat easier, but there's a cost here to both VSI and to end-users.

Catering to the past at the expense of the present and of the future is 
what got OpenVMS where it is now.  I really don't think continuing 
these practices can get OpenVMS where VSI and most of us want it to be, 
either.

The economics have changed markedly over the years, the tech has 
changed, the treadmill of upgrades is only going to accelerate, and VSI 
and VSI customers are operating with fewer folks and smaller budgets.  
VSI can't be everything for all.  Not without a bigger and more vibrant 
installed base.  And how does VSI get to that?   It won't be with 
perpetual support of OpenSSL 0.9.8.7.6.5.4xyzzy.

Total upward-compatibility is an impossible dream.  It trains folks to 
dig in, and to want what is impossible.  Some customer app code is 
inevitably going to have to be tweaked.  That's the world we're in.  We 
can't fit thirty-two bytes in an eight-byte buffer.  Not without code 
changes.  Or you're not upgrading.  Or the rest of us are losing out on 
fixes and updates for the apps we are maintaining.






-- 
Pure Personal Opinion | HoffmanLabs LLC