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
