"
The other thing to consider is that perhaps OpenBSD really has the
right approach, which is that portability should be done via support
libraries, and not part of the core code. That might impact
performance on some legacy piece of cr*p, but presumably, impacted
performance is better than no support at all, or some massive security
hole that resulted from having to support legacy code hiding some
horrible security bug....
"
Disagree there.
OpenSSL sits at the bottom of the stack. It either builds on a platform and
provides the function or the function doesn't exist on that platform
anymore.
The platform support stuff doesn't typically cause security problems, just
go through the list of OpenSSL CVE's. More typical is all platform bugs or
someone who had this great extension or code change they wanted and got it
into the code base.
I won't argue that sometimes legacy support makes the code hard to read,
but in itself I don't think it's causing bugs.
I'd also point out that legacy platforms are pretty common in the embedded
space and may even make up the majority of instances of OpenSSL in the
wild.
Peter
From: "Theodore Ts'o" <ty...@mit.edu>
To: openssl-dev@openssl.org
Date: 03/06/2014 02:30 AM
Subject: Re: AW: Which platforms will be supported in the future on
which platforms will be removed?
Sent by: owner-openssl-...@openssl.org
On Mon, Jun 02, 2014 at 03:38:22PM +0200, stefan.n...@t-online.de wrote:
> * How much do you gain by removing support for the platform?
>
> Is there any relevant amount of code, that is really NT/2000/XP specific
> and unneeded for newer Windows releases? Breaking the support for
> the ancient platform by removing just a dozen lines of code seems like
> an unnecessary annoyance to (admittedly few) users.
> If on the other hand you can throw away hundreds of lines of code that
> nobody understands or even looks at, then go for it ...
What I'd suggest is as people create lists of legacy OS's that might
be removed, along with a deprecation schedule, that there also be an
explanation about why support for an ancient OS is causing pain. Even
if the decision is to support some legacy system for some period of
time, an explanation of what code could be removed when it can finally
be dropped would be good to have archived, so that people don't have
to rediscover and reargue the case for why VMS deserves live over and
over again. :-)
The other thing to consider is that perhaps OpenBSD really has the
right approach, which is that portability should be done via support
libraries, and not part of the core code. That might impact
performance on some legacy piece of cr*p, but presumably, impacted
performance is better than no support at all, or some massive security
hole that resulted from having to support legacy code hiding some
horrible security bug....
- Ted
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
