Re: AW: Which platforms will be supported in the future on which platforms will be removed?
On Tue, Jun 03, 2014 at 02:22:07PM +1000, Peter Waltenberg wrote: 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. There's a very simple solution to that problem, especially since we now have the support and attention of many hardware companies. The rule should be very simple. If a company doesn't contribute either (a) exclusive, dedicated hardware, or (b) reliable, continuous access to hardware, it doesn't get supported by the OpenSSL developers. Period. If it's not important for a company to provide access to hardware, then they can take on the support burdens of providing OpenSSL support to their platform, or clearly *they* don't care about the security of their users. And if they don't care, again, it's not fair to impose a security tax on the rest of the Internet. (And especially in the case of embedded products, it's not enough that OpenSSL provide a new release with a security fix; the company needs to be willing to create a firmware load and get it to all of its 10 year old customers. And if they aren't willing to provide hardware to critical infrastructure provider such as OpenSSL, it seems unlikely they will be creating a new firmware load anyway, so what's the point?) The Linux kernel doesn't tie itself in knots wringing its hands about how it can't make forward progress because it might break, say, the break the m68k or alpha port. They continue to exist only because a number of m68k and alpha maintainers are sufficiently motivated to keep them alive, *and* the impact on the core code is largely nil. If a largely dead architecture or CPU started getting in the way of everyone else, it would either have to get fixed so it wasn't getting in the way, or it would be removed. (Which, for example, was the decision of the x86 maintainers over the fate of 80386 support.) Cheers, - Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
On Tue, Jun 3, 2014 at 7:10 AM, Theodore Ts'o ty...@mit.edu wrote: There's a very simple solution to that problem, especially since we now have the support and attention of many hardware companies. The rule should be very simple. If a company doesn't contribute either (a) exclusive, dedicated hardware, or (b) reliable, continuous access to hardware, it doesn't get supported by the OpenSSL developers. Period. [ details schnipped ] Hi, Ted. This is lucid, cogent advice. I hope everyone reads this twice. The most constrained resource is developer time, and it should prioritized based on some calculus that includes an awareness of which versions on which platforms have what level of deployment, an internal roadmap that serves as a strategic guide, and resources made available by companies that need custom or embedded versions. The roadmap is key - it needs to include, as Rich Salz took the trouble to point out, a clear declaration of EOL for the entire matrix of versions x platforms. Without that, assigning priority to features in new versions is a promise without real commitment. In addition to a public roadmap, a disciplined approach to managing feature backlog is key for the developers and committers. While we're full of good ideas for innovation and improvement, let's not forget the committed efforts of those who continue to shepherd the project, especially Stephen Henson, who has kept it together in much the same way as Keith Richards did the Stones. - M __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: AW: Which platforms will be supported in the future on which platforms will be removed?
especially Stephen Henson, who has kept it together in much the same way as Keith Richards did the Stones. With no disrespect intended to either man, I have to say that this is an analogy that never would have occurred to me in a million years. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
I don't disagree (or I certainly don't disagree completely) with anything that has been said so far. But I think it's easy to assign disproportionate angst to this or that problem. For example, and that's all this is, but one of the most serious issues I think we have in the openssl code is that macros are (ab)used heavily because the we have a legacy rule against the use of inlines. One of the other guys can probably remember why this is (I don't), but I would suspect that it *is* related to support for some obscure platform or toolchain. My point is that if we collapse the issue down to trimming the list of supported platforms, we could overlook the actual benefits in many cases. In this example, we may miss the fact that the no-inlines rule is in fact no longer justified. I've been in the bowels of the linux kernel over the last few years (though nothing compared to Ted), and it's vivid to me how inlines, however evil they might appear to some people, are still much less evil than macros. (In nearly all cases.) A similar example is for symbols like NO_SYS_UN_H. You'll find #ifdefs for that whenever there are headers and code that deal with domain sockets. I agree with Ted about the fact that it's much better to get rid of the #ifdefs where that stuff is used, and instead #ifdef it (or arch/-split it) in the one place where domain socket stuff is *declared*. #ifdef the called, not the caller. Any sensible and pragmatic approach to reviewing the list of supported platforms should include an effort to qualify these kinds of downstream effects. (Ie. does removing or keeping a particular platform change anything? Or allow anything to be changed for the better?) Implicit in the discussion about platforms is the question of the build system. I have a number of thoughts on this too, but have refrained from doing anything about them so far because I could easily bite off more than I can chew, time-wise. In fact, I've heard that the use of ordinals might be avoidable even on windows, and it's clearly useless everywhere else (except VMS?), but it's a maintenance hassle all the time for everyone who is making updates (especially across more than one branch). A discussion about platforms ought to address this too. While I'm on a roll, another example. Things like crypto/dso/ really only exist to cover the fact that there is no notion of arch/ in the code-base. I dare say there are a number of other places and abstractions where, if we used a more OS/kernel style of coding, things might simplify down. Loading and using a shared-library would have a single *internal* API, and that API itself would be implemented within the appropriate sub-directory of arch to suit the target platform. As things stand, we have an *exported* DSO API, which is pluggable by built-in and/or caller-provided modules, despite the fact that on a sensible system only one such module exists and there would be no reason for a caller to plug in a replacement. I wrote that DSO stuff, so I'm not hating on anyone but myself, but it was done that way because that's in keeping with how everything else is done, it seemed (and seems) to be the consistent thing to do. In other words, it's symptomatic of a more general issue. A discussion about platforms ought to address this sort of thing too. Which leads me I guess to a bigger issue, or meta-issue: compatibility. In addition to everything that has already been said, a major issue that I haven't seen mentioned is the fact that openssl has always been painstakingly backwards compatible at an API level. Many years ago, the use of OPENSSL_NO_DEPRECATED started cropping up (I don't recall if I started that or joined in), but all of those symbols are still there. In other words, we introduced the mechanism that *would* allow us to phase things out from one major release to the next but never actually pulled the trigger. (If you build with OPENSSL_NO_DEPRECATED, some legacy things disappear, and the idea is that in a major release all the DEPRECATED stuff could be amputated from the source. Rinse and repeat.) Again, if blame is to be had then I'll take a double. It may be that rounding up a list of platforms seems to be the easiest problem to attack and perhaps it inspires more motivation. It can't be bad exercise in and of itself. But I suspect that all it will do is clear away some modestly-bounded level of cruft, it is unlikely to repair structurally-important problems without harder discussions being had. (Coding assumptions like inlines, portability philosophy such as modules-vs-arch, build system, backward compatibility, ...) On Tue, Jun 3, 2014 at 12:10 PM, Salz, Rich rs...@akamai.com wrote: especially Stephen Henson, who has kept it together in much the same way as Keith Richards did the Stones. With no disrespect intended to either man, I have to say that this is an analogy that never would have occurred to me in a million years. /r$ -- Principal Security Engineer Akamai
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
It's a simple solution, and obvious and I don't think it'll work. This is NOT the Linux kernel, the Linux kernel is directly funded by several of the larger companies, they have employees contributing directly on the kernel, with access to internal hardware resources. OpenSSL doesn't. Yes, it has people funded by the larger companies USING OpenSSL with access to hardware resources , but they don't usually contribute directly to OpenSSL - consumers, not producers. They may contrinute the occasional patch, butthat's about it. There's a problem of scale here between the kernel and OpenSSL. Donating server scale hardware would be a punishment, not a benefit. You have to power it, you have to find space for it and it's noisy, and on the other side of the equation, there's no way those companies are going to let outsiders into their corporate networks. I think the best you'd manage is insisting that larger companies wanting support run some sort of continuous build system internally and feed results back to the OpenSSL team. Alternately, the OpenSSL team could give people from those companies checkin access - but that has more fishhooks than the obvious, export compliance is the obvious problem, but there are other issues, trust for example. Peter From: Theodore Ts'o ty...@mit.edu To: openssl-dev@openssl.org Date: 04/06/2014 12:18 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 Tue, Jun 03, 2014 at 02:22:07PM +1000, Peter Waltenberg wrote: 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. There's a very simple solution to that problem, especially since we now have the support and attention of many hardware companies. The rule should be very simple. If a company doesn't contribute either (a) exclusive, dedicated hardware, or (b) reliable, continuous access to hardware, it doesn't get supported by the OpenSSL developers. Period. If it's not important for a company to provide access to hardware, then they can take on the support burdens of providing OpenSSL support to their platform, or clearly *they* don't care about the security of their users. And if they don't care, again, it's not fair to impose a security tax on the rest of the Internet. (And especially in the case of embedded products, it's not enough that OpenSSL provide a new release with a security fix; the company needs to be willing to create a firmware load and get it to all of its 10 year old customers. And if they aren't willing to provide hardware to critical infrastructure provider such as OpenSSL, it seems unlikely they will be creating a new firmware load anyway, so what's the point?) The Linux kernel doesn't tie itself in knots wringing its hands about how it can't make forward progress because it might break, say, the break the m68k or alpha port. They continue to exist only because a number of m68k and alpha maintainers are sufficiently motivated to keep them alive, *and* the impact on the core code is largely nil. If a largely dead architecture or CPU started getting in the way of everyone else, it would either have to get fixed so it wasn't getting in the way, or it would be removed. (Which, for example, was the decision of the x86 maintainers over the fate of 80386 support.) 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
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
On Wed, Jun 04, 2014 at 09:14:18AM +1000, Peter Waltenberg wrote: This is NOT the Linux kernel, the Linux kernel is directly funded by several of the larger companies, they have employees contributing directly on the kernel, with access to internal hardware resources. Yes, and I'm saying people aren't thinking big enough. OpenSSL is critical infrastructure. There's a reason why the Linux Foundation's Critical Infrastructure Initiative is funding two people to work full time on making OpenSSL better. (ObDisclosure: I'm on the CII technical advisory board.) If there are resources you need, people should *ask*. There may be solutions you haven't thought of. For example, one mechanism that has been used before is to have the hardware donated to the Oregon State University's Open Source Lab. IBM has used this to make Power systems available to open source developers, for example. So there are ways to get access to machines without requiring that you pay for the power and hosting fees. Don't assume that the answer is that can't be done, so we need to keep horrible macros and #ifdef's and be really hesitant making changes lest we break some dead architecture that might not being maintained, or for some router company that might not take an updated OpenSSL to support some hardware which is ten years old. There may very well be solutions you haven't thought of yet. I think the best you'd manage is insisting that larger companies wanting support run some sort of continuous build system internally and feed results back to the OpenSSL team. And this is also not hard. Now that OpenSSL is using git, it's really trivially easy have companies do this and feed results back. Intel has a team in China doing this for pretty much every single major kernel developer's git tree. I can push an ext4 to a test git branch, and if I've forgotten to run sparse (a static code analyzer) and fix any problems, within *minutes* I'll get back an e-mail indicating that my pushed test code has introduced new code warnings. And this is done *before* my code hits linux-next, or Linus's mainline tree. You don't think OpenSSL isn't similarly important? And that companies won't provide similar continuous testing if you ask? Especially after all of notice that was raised after the Heartbeat scare (which admittedly wasn't even the worse SSL bug in the last couple of months), this is really a good time to ask companies for this kind of support. Cheers, - Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
AW: Which platforms will be supported in the future on which platforms will be removed?
Hi, Which platforms are deprecaded an could/should be removed in the sourcecode? MS-DOS? Windows 16 Bit? OS/2? Windows 95/98/ME? Windows NT/2000/XP? Necessary criteria for a platform to be included in the first list would be: * Currency, i.e. a platform is widely deployed and in current use * Vendor support, i.e. if a platform is no longer supported by its vendor - why should we continue to support it? * Available to the dev team, i.e. the dev team have access to a suitable environment in which to be able to test builds and deal with tickets and issues I'd also add a fourth point: * 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 ... Applying these tests to your list of platforms I think they all fail the first test (with the exception of XP). They all fail the second test. Just for the sake of correctness, OS/2 in it's re-incarnation as eComStation _does_ have vendor support. According to http://en.wikipedia.org/wiki/EComStation, Serenity Systems states that eComStation will be developed and sold as long as it remains profitable. According to rumours, existing contracts ensure this for _at_least_ five more years, as incredible as this sounds in the era of 64 bit systems. Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
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
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
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
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
On Tue, Jun 03, 2014 at 11:22:58AM +1000, Peter Waltenberg wrote: 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. The OpenBSD people are right here. If it's hard to read, then we don't have many eyeballs on the code. And while that isn't the only way to curtail an active development community (Sun Microsytems came up with many more), it's certainly one of the more effective ones. It's not like someone wakes up and says, I know! I'll screw over the entire internet by introducing a security bug! It happens by accident, and the messier your code is, the more likely it is to happen. Code needs to be easy to read; or else you get bugs. There's a reason why the Linux kernel coding style strongly discourages in-line #ifdef's in code. 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. I don't think there are a lot of embedded systems using (a) VMS, (b) Windows 3.1, or (c) EBCDIC. Cheers, - Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
(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. 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. So, some device like a router has been out in the field ten years but still works just fine, are you going to block security updates for it ? You won't get major cleanups without purging platforms like Windows, OS/X, AIX, HP/UX. 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. Peter From: Theodore Ts'o ty...@mit.edu To: openssl-dev@openssl.org Date: 03/06/2014 12:01 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 11:22:58AM +1000, Peter Waltenberg wrote: 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. The OpenBSD people are right here. If it's hard to read, then we don't have many eyeballs on the code. And while that isn't the only way to curtail an active development community (Sun Microsytems came up with many more), it's certainly one of the more effective ones. It's not like someone wakes up and says, I know! I'll screw over the entire internet by introducing a security bug! It happens by accident, and the messier your code is, the more likely it is to happen. Code needs to be easy to read; or else you get bugs. There's a reason why the Linux kernel coding style strongly discourages in-line #ifdef's in code. 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. I don't think there are a lot of embedded systems using (a) VMS, (b) Windows 3.1, or (c) EBCDIC. 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
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
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
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
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
