Look at the sources.
The build related mess is mainly Windows support.
#ifdef hell is mainly around external engine support, asm to get
performance, or object sizes/endianess which intrinsically varies platform
to platform. The code was written over a lot of years with a lot of
different styles and that shows, but again, it really hasn't had a single
full time person coordinating comits and enforcing style.
Some of the mess is going to be hard to fix. OpenSSL isn't "one size fits
all", some end users need small footprint, some need the backend engines,
some don't need the backend engines because they play merry hell with
exportability, some algorithms had to be disabled for some users for patent
reasons - it all adds up.
I'm not saying that it wouldn't be nice to have a lot of this cleaned up,
but 'dead platforms' isn't the biggest problem in the source tree. I'm also
sure some of the clutter could be cleaned up, but equally really glad that
it isn't yet me having to do it.
It's a serious comitted effort that's required to fix the real issues not
something easy like dropping a few platforms.
One of the uglier problems is that unless you can build/test on all the
platforms on each change you'll almost certainly break platforms
unexpectedly - that lack of hardware has been one of the long term problems
and it's likely one of the inhibtors to cleanup as well.
Peter
From: "Theodore Ts'o" <ty...@mit.edu>
To: openssl-dev@openssl.org
Date: 03/06/2014 12:55 PM
Subject: Re: AW: Which platforms will be supported in the future on
which platforms will be removed?
Sent by: owner-openssl-...@openssl.org
On Tue, Jun 03, 2014 at 12:20:17PM +1000, Peter Waltenberg wrote:
> (c) EBCDIC.
>
> z/OS is still alive. I'll concede that one is weird and hard to get hold
> of, but it has a lot of users still.
z/OS supports ASCII, and UTF-8, and has its own conversion routines
built into the system. So it's not clear OpenSSL needs to have any
EBCDIC built into its core code. If there are z/OS support functions
that needed to decrypt and encrypt EBCDIC, that's fine, but it
shouldn't be a tax on all the support for all other operating systems
out there.
> This ISN'T the Linux kernel. It's userspace code and longer lived and
wider
> spread than Linux and pretty fundamental to security.
> Even with the 'dead' platforms crossed out, it has far more variants to
> support than Linux, and typically longer support lifetimes.
I've maintained userspace code before, including krb5 and e2fsprogs,
which works on a very large number of platforms. Yes, I never had to
support VMS, but who cares about VMS? (Hint: No one, including HP, by
2020...)
> You won't get major cleanups without purging platforms like Windows,
> OS/X, AIX, HP/UX.
OS/X, AIX, and HP/UX are all POSIX platforms, with support for BSD
sockets. Supporting them with common code and without tons and tons
of in-line #ifdef's isn't hard. In fact, e2fsprogs does compile on a
wide variety of legacy Unix platforms, without looking nearly as
horrible as OpenSSL's source code....
> Windows, I'd suggest most of the cruft there could be removed by
insisting
> that it builds with gnu make/cygwin installed but using the native MS
> compiler. That's probably the biggest single cleanup possible and it's
very
> much a 'live' platform.
I said Windows 3.1. Win16 and Win32 are quite different, and I'd
suggest Win16 is pretty dead. (As is MacOS pre-OSX. Again, quite
different from OSX, and equally, just as dead.)
Cheers,
-
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
