[Info-vax] New OpenSSL update from HP

[Dirk Munk]

Stephen Hoffman wrote:
> 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,

Of course we want them :-)

> 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

Very good remark, you're right there.

> — and it all increases
> the likelihood of crypto problems.

Why? I can imagine that both versions share the same crypto engine. I 
can even imagine that it is a shared library.

> 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.

Were those implementation errors or more fundamental errors?

>
> Backing up a few steps, solving the more general problems lurking here
> would be helpful, too — OpenSSL is not at all unique,

No, there are more SSL implemenations

> 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.
>
>