[Info-vax] New OpenSSL update from HP

[Stephen Hoffman]

On 2015-06-14 18:15:17 +0000, Dirk Munk said:

> 
>> Stephen Hoffman skrev den 2015-06-14 14:45:
>>> 
>>> Most of the providers are able to turn around the new OpenSSL releases
>>> pretty quickly, for those providers that are still using OpenSSL and not
>>> LibreSSL <http://www.libressl.org> or some other variant or fork or
>>> implementation.
>>> 
>>> n.b. The OpenSSL folks define what the OpenVMS interface looks like, too;
>>> the order of the shareable image symbols.  They're one of the few (if not
>>> the only) multi-platform portable open source projects that do that, too.
>>> 
>>> n.b. The LibreSSL folks maintain a portable variant, in addition to the
>>> core version that uses the security features of OpenBSD.
>>> 
>>> n.b. The 0.9.8 series and the 1.0.0 series both go unsupported at the end
>>> of this year; at the end of 2015.
> 
> I suppose this shows the problem with open source software.

That "this" problem would be?

...That security software gets updated, and older versions become 
outdated?   VSI is not going to have much success in preventing that 
from happening.

...That existing environments migrate forward only slowly?  That's 
certainly the case, and HP has decided to stick with an older OpenSSL 
version likely in the interest of compatibility.  Things got mildly 
ugly the last time SSL got updated, and that migration wasn't handled 
at all well.   Oracle Rdb deals with this need to upgrade and to change 
APIs rather better, as an example.

...That folks can and should get used to interfaces getting deprecated? 
 Again, VSI is going to have some trouble preventing that from 
happening.  OpenSSL and other projects can and will deprecate older 
versions, and then the choice becomes taking over that support, or 
deprecation.  As for OpenVMS itself, there's more than a little code 
that's — if not dead — rarely used now, and there are cases where 
historic preservation and compatibility has taken priority over added 
security.

If software deprecation does become the norm — there's not really any 
good way to avoid that, whether with OpenSSL and probably also LibreSSL 
and other forks, or otherwise — then It'd definitely be nice to see a 
schedule for the deprecation and the retirement of code that can't 
reasonably be updated to more current norms.  This deprecation schedule 
combined with a matching long-term support schedule for those folks 
that can't upgrade expeditiously.  But then folks here have objected to 
this approach before.

In more mercenary terms, if your source code is not moving forward and 
not adopting new features and not getting updated, then you're probably 
also not upgrading and you're not buying.  So you get to pay for the 
the long-term release if you need support, but that support for those 
releases can and will end.

As laudable as it might be, this everything- compatible- forever 
approach just isn't sustainable.  Even with infinite resources and 
infinite cash, it'd be a problem project.  Or you just stop upgrading 
and stop fixing some stuff, in the interest of compatibility.

> In my view there should be one single stable production version of OpenSSL,

There is a roadmap available for OpenSSL.

OpenSSL currently has four production releases, with the oldest two 
falling off support this year; at the end of 2015.

> and that version should be ported to VMS.

Having just one version available would be disruptive, as not everybody 
can move forward at once.  As the all-or-nothing V1.4 SSL upgrade 
showed, stuff broke, and folks complained.   We're headed for another 
of these upgrade cases, too — it'd be nice to have the HP SSL 1.0.2 
available soon, to allow folks to start to migrate, too.  (The SSL code 
I've done most recently is compatible across 0.9.8 and 1.0.1, and with 
very minimal changes.  Whether that will be the case with other 
applications and tools, I do not know.)

> There shouldn't be a HP version and a WASD version for instance.

HP didn't integrate SSL with other parts of OpenVMS; it's been an 
isolated add-on for a while.  Given it's open source, it's easier to 
incorporate your own versions with your own kit, and that gets you 
access to the specific version you've tested with.

There's also the matter of how the installations and products should be 
structured, and whether the classic approach and kitting is still even 
appropriate, or whether the applications should be executable from 
within their packages and their own directories with their own 
application-specific framework.  Writing stuff into the system 
directories and sharing startup files just gets messy, in terms of 
security, file collisions, and uninstalling.

> Perhaps in future VSI will do a better job in supplying us with the 
> most recent version.

I'd prefer to have access to at least two of the versions in parallel.  
Given there'll likely be requests in this thread for an OpenVMS version 
with OpenVMS interfaces, that ranges from wrappers akin to those 
already written <http://labs.hoffmanlabs.com/node/1853> to a full-blown 
native-style implementation which would (simplistically) double the 
effort involved — there's still going to be open source code around 
that needs the OpenSSL APIs and not the OpenVMS APIs — and it all 
increases the likelihood of crypto problems.  Crypto implementation 
source code is complex and can be very subtle — e.g. timing 
vulnerabilities — and most or all implementations — whether open source 
and ubiquitous, or private and platform-specific implementations — of 
crypto will almost invariably contain implementation errors and/or 
cases where the code can or will need to be updated.  The effective 
deprecation of SSLv3 and various cipher vulnerabilities, for instance.

Backing up a few steps, solving the more general problems lurking here 
would be helpful, too — OpenSSL is not at all unique, nor is the need 
to incorporate specific versions into specific applications, nor will 
the current mess in the startups resolve itself, nor will we stay in 
the world of singleton or one-off deployments, nor will the need to 
more easily and more quickly and more cleanly install and remove 
software lessen, nor will the speed and the urgency and the necessity 
of the upgrade cycles do anything other than increase.   Etc.   Outside 
of the installed base, this is just the very tip of the expectations 
and the effort involved, too.


-- 
Pure Personal Opinion | HoffmanLabs LLC