Post by Dave Froble
First, I agree that the latest TLS/SSL should be provided.
I also feel that the interface to the product should be somehow
compatable rather than needing re-coding to use the newer stuff. Not
sure how easy that might be.
This goes well past TLS, too. There's a whole pile of drudge work here,
and developers are increasingly being provided with frameworks for
For not the first time, yes, it is possible to do all of this in
bespoke app code—and variously either incompletely, or with errors—but
that's not where we're headed.
Post by Dave Froble
But, I'm going to ask, why remove older capabilities? Sure, it would
be best to not use them. But there will be some users that do not have
a choice, if they want to continue communicating with existing trading
partners. So, whynot some type of configuration tool that can set
flags as to which protocols should be allowed? Default it to TLS3, but
allow when necessary for older protocols to be allowed.
For various of these cases both involving OpenSSL and those beyond
OpenSSL, and in no particular order...
... all code has support costs, whether that code is used or supported
or not. Building, packaging, storage, kitting, installations, testing,
... unsupported code still has bugs. Unsupported security code has known bugs.
... folks that are not maintaining and are not updating their code are
the wrong end of the market. The folks that are not integrating with
and not networking with other systems is getting ever smaller.
... old and unsupported code can have API problems and constraints and
incompatibilities, and can constrain updates.
... more than a few OpenVMS sites have no idea what's secure and what's
not, and look to the folks maintaining "the most secure operating
system on the planet" for guidance and suggestions.
... economics. VSI can't do everything for everybody. Where there are
problems, start by creating and then migrating folks to better APIs.
Deprecate and eventually remove the worst and most problematic.
For this particular case, folks using old releases and old features can
lock in and hope it'll all keep working and as many (most?) do, or they
can fix and maintain their code if they want or need current versions
and support and they can then install a free OpenSSL kit and maintain
it themselves, or possibly use an add-on and extra-cost OpenSSL kit.
Why deprecate and eventually remove? Various reasons around the older
OpenSSL TLS bits: the older approaches are insecure. They're
fundamentally broken. More than a few users don't know this or don't
recognize this, and it's incumbent on VSI to guide OpenVMS developers
and end-users forward as part of the VSI "the most secure operating
system on the planet" marketing efforts. Preserving the older
approaches and older APIs variously also limit the range and scope of
enhancements and upgrades possible.
I really like compatibility. In theory. But that compatibility can be
far more costly and far more constraining than many realize. And it's
just not possible to fit sixteen or thirty-two bytes into an eight byte
buffer. I'd prefer the development focus on newer bits and newer
updates than on preserving APIs and designs for code that isn't being
In practice, complete upward-compatibility is increasingly incompatible
with the future sales and future usefulness of a product, and
incompatible with the level of development effort that can be expended
and where and what, and with what the folks that are keeping current
and are maintaining their products need and want. Some old APIs have
to be retired and removed, preferably with migration paths and/or with
better replacements available.
I'd hope that VSI would prefer to steer user expectations away from
some of the more problematic DEC ideas. VSI and OpenVMS users can
either have a focus on better APIs and features and retiring what's
known problematic, or a focus on existing and old apps and on
increasingly convoluted APIs and increasingly hostile designs and
absurd defaults. DEC focused on the latter—on compatibility—at the
expense of the former—on usability, clear APIs, good defaults, current
tooling, etc. Based on what I've seen if it, the latter approach is
also a long-term declining market, too.
There's no right answer here, and there are always trade-offs. If
y'all have a can't-ever-upgrade-something or
can't-ever-change-something installation, have at. Again, I've heard
just about every reason for that too, and I really don't care what
constraints or evaluations or other requirements you've gotten tangled
with. Figure out how to do that. Go do it. Whatever. But please
don't expect the rest of us using OpenVMS to want to cater to your
requirements, nor to want our maintenance and our new work and our new
apps and our development costs to be more expensive so that your
existing and old installations can make fewer or no changes. Or the
new apps and new deployments increasingly go elsewhere, and the whole
dealing-with-upgrade problems become moot.
Pure Personal Opinion | HoffmanLabs LLC