You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@apache.org> on 2002/10/19 11:56:40 UTC
distributing encryption software
Ryan asked for a clarification about whether or not we have the ability
to redistribute SSL binaries for win32.
Last year, the board hired a lawyer to give us an opinion on whether
we can distribute encryption software, or hooks to such software.
The exact opinion we got back is, unfortunately, not online, but it
is essentially the same (with less detail) as the one given to Debian
and visible at <http://debian.org/legal/cryptoinmain>. Basically,
we have the right to distribute encryption software in source or
executable form if we also distribute that same software as open
source for free to the public, provided we first notify the U.S.
authorities once per new encryption-enabled product.
This is sufficient for Debian because they distribute the source code
to everything in Debian within a single repository. Note, however,
that we do not do the same for OpenSSL. Not only is OpenSSL not in
our CVS, but it isn't normally distributed by us at all, and the
authors of OpenSSL aren't likely to want us to distribute it because
doing so pollutes the recipients rights with U.S. crypto controls
whereas they could simply grab the same distribution from the origin
and not be polluted.
I think that Bill Rowe at one point requested that we seek out a
lawyer's opinion on this specific matter, but that was not followed
through by the board because we already know the legal aspects.
The issue isn't legal -- it is social. We can download a released
version of OpenSSL, compile it, and make both available from our
website provided we first notify the BXA as described in the Debian
opinion above. However, it is still preferable for our users to
get the DLL themselves, from a distribution outside the U.S., and
avoid having to maintain our distribution of OpenSSL up-to-date.
I think a reasonable and defensible compromise would be to make
it part of the win32 installation script -- to select no SSL or,
if SSL is selected, to guide/automate the user in downloading an
appropriate DLL from some other site. Besides, that would allow
the user to pick some other SSL library, such as one of the
optimized ones available commercially that may already be
installed on their system. There is such a thing as being too
concerned about "ease of installation."
Finally, it should also be noted that the exception for Apache ONLY
applies to non-commercial distributions. Any commercial distribution,
even if it is simply Apache slapped onto a CD and sold for a buck,
remains subject to the old US export controls that everyone hates,
and must be approved via a separate process.
....Roy
Re: distributing encryption software
Posted by "johannes m. richter" <jo...@gmx.net>.
>Well, I don't think that you need $$$, the only thing you really need is
>hardware (for the builds), bandwidth (for downloads) and time (to build)...
I don't know about hardware and time (unfortunately I am too dumb to
compile those things) - but I guess there're some people with bandwidth out
there. One server which always comes to my mind is http://gd.tuwien.ac.at/
, a server of the TU Wien (technical university of Vienna) which already
mirrors many projects (mainly free software). I bet Antonin Sprinzl (the
server's admin) would add those things to the server (he's always keen on
new suggestions..)
Just an idea :)
johannes
--
EASY TO INSTALL = Difficult to install,
but instruction manual has pictures.
- http://jgcl.at/ko/ - new photos from summer camp 2002 in Moosen/Tirol
Re: distributing encryption software
Posted by "johannes m. richter" <jo...@gmx.net>.
Sorry for splitting my answer up :o
>Well, I don't think that you need $$$, the only thing you really need is
>hardware (for the builds), bandwidth (for downloads) and time (to build)...
SourceForge has a compile farm too. So I guess one would have to create a
project "apachessl_binaries" or something like this and ask for compile
farm access (which does not have to be granted, specially since Apache
itself is not hosted on sf - see
http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1)
Or you could ask IBM/Sun/HP directly - "There are people using your
products which would like this (so do it!)" ;-)
johannes
--
EASY TO INSTALL = Difficult to install,
but instruction manual has pictures.
- http://jgcl.at/ko/ - new photos from summer camp 2002 in Moosen/Tirol
Re: distributing encryption software
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@apache.org> writes:
> --On Saturday, October 19, 2002 9:35 AM -0400 Jeff Trawick
> <tr...@attglobal.net> wrote:
>
> > the general Solaris 8 user community (you can't even download
> > sendfile+prerequisites without a maintenance contract last time I
> > tried).
>
> They are publicly available patches, but it's probably unreasonable to
> expect Solaris 8 binbuild users to have sendfilev.
>
> http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F111297&zon
> e_32=sendfilev
>
> At the bottom of that page is the list of required patches.
been there, done that... follow the link to required patch 108991-13
and you get an error message...
search for 108991-13 in patchfinder and you see this:
"The document or patch you are attempting to access is available to
contract customers only. You can obtain the patch from your local
Solution Center. North American customers can call 1-800-USA-4SUN."
> If you get the latest Solaris 8 MU set or go to Solaris 9, you should
> have sendfilev(). -- justin
either path is not something that j random user is necessarily able to
deal with in order to get a critical update
(not that we are under any oblication to make it easy... it just seems
something that would be of value to our users...)
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: distributing encryption software
Posted by Justin Erenkrantz <je...@apache.org>.
--On Saturday, October 19, 2002 9:35 AM -0400 Jeff Trawick
<tr...@attglobal.net> wrote:
> the general Solaris 8 user community (you can't even download
> sendfile+prerequisites without a maintenance contract last time I
> tried).
They are publicly available patches, but it's probably unreasonable
to expect Solaris 8 binbuild users to have sendfilev.
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F111297&zon
e_32=sendfilev
At the bottom of that page is the list of required patches.
If you get the latest Solaris 8 MU set or go to Solaris 9, you should
have sendfilev(). -- justin
Re: distributing encryption software
Posted by Jeff Trawick <tr...@attglobal.net>.
Pier Fumagalli <pi...@betaversion.org> writes:
> On 19/10/02 14:35, "Jeff Trawick" <tr...@attglobal.net> wrote:
> >
> > I can't install Solaris 8 from a recent enough CD-ROM set that has
> > sendfile if I want to do Apache 2.0 binbuilds which are usable by the
> > general Solaris 8 user community (you can't even download
> > sendfile+prerequisites without a maintenance contract last time I
> > tried).
>
> Hmm... You can download the latest version of Solaris, boot from the CD, and
> for PACKAGE in `pkginfo -r /a` ; do pkginst -r /a /Products/$PACKAGE ; done
> (expand the obvious bits where the stuff wouldn't work)...
>
> Basically you're going to replace the whole OS with a new one, or you can
> just replace a couple of packages (SUNWcor and SUNWcorx)... Ok, it's a hack,
> but what the heck! :-)
but that isn't something that somebody wants to do to a production
server just so they can pick up a security fix; and if it is one of
the many people for which doing their own build of Apache is
non-trivial, they should be hesitant to do that anyway
> > Heck, even with Win32 there aren't many people who can do binbuilds,
> > and that is particularly bad when a security fix is announced and
> > everybody looks for the same one person.
>
> And given that MSVC costs $$$$$, the problem gets bigger...
yep; and just look at the price of Sun's or HP's or IBM's compiler
> > If there were money ("thanks for downloading the latest Apache binary
> > distribution for your platform; would you care to contribute a few
> > euros towards the generation and availability of what you just
> > downloaded?"), it would be possible to maintain a set of machines
> > running the appropriate set of system software to enable binbuilds to
> > be reliably built for the largest possible audience.
> >
> > If a loosely affiliated group ("unencumbered friends of Apache") could
> > accept contributions and maintain a rich set of binbuilds of Apache
> > with/without SSL support, a lot of users would be happier and a lot of
> > PRs could be closed with less hair turning gray but without breaking
> > the user ("I'm sorry you are encountering this particular build SNAFU.
> > It works fine for a number of people on that platform. There is a
> > trusted binary build for your platform available from
> > www.xxxxxx.org.").
> >
> > More than what you were interested I'm sure, but there are other
> > frustrating aspects of binbuilds than just the encryption issue.
>
> Well, I don't think that you need $$$, the only thing you really need is
> hardware (for the builds), bandwidth (for downloads) and time (to build)...
and software... vendor compilers can cost much more than a used, older
generation hardware box but depending on the platform they get along
with libtool better and/or generate significantly better code than the
free compilers
point well taken, but money can ease the life of the volunteers...
sure, you can put "help, the drive on our HP-UX build machine
died... can anybody send us one?" but it is much more efficient for
volunteers to have a slush fund that will buy exactly the right new
drive in a heartbeat rather than wait for some unknown individual to
send in something... sure, volunteers can go nag all their contacts
for a free copy of a Microsoft compiler or an AIX box or whatever, but
with so many people (particularly Win32-ers), making use of binary
builds, it seems that with small contributions from some of them a
better "product" could be provided
--/--
My view is that we could provide a much better binbuild service than
we do today, and that it is reasonable to ask for contributions to
cover the real costs so that the volunteers only have to worry about
preparing the consistent set of binbuilds when there is a new release
instead of wasting their time haranguing their friends and other
contacts trying to scrounge up this vendor compiler or that piece of
hardware.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: distributing encryption software
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 19/10/02 14:35, "Jeff Trawick" <tr...@attglobal.net> wrote:
>
> I can't install Solaris 8 from a recent enough CD-ROM set that has
> sendfile if I want to do Apache 2.0 binbuilds which are usable by the
> general Solaris 8 user community (you can't even download
> sendfile+prerequisites without a maintenance contract last time I
> tried).
Hmm... You can download the latest version of Solaris, boot from the CD, and
for PACKAGE in `pkginfo -r /a` ; do pkginst -r /a /Products/$PACKAGE ; done
(expand the obvious bits where the stuff wouldn't work)...
Basically you're going to replace the whole OS with a new one, or you can
just replace a couple of packages (SUNWcor and SUNWcorx)... Ok, it's a hack,
but what the heck! :-)
> Heck, even with Win32 there aren't many people who can do binbuilds,
> and that is particularly bad when a security fix is announced and
> everybody looks for the same one person.
And given that MSVC costs $$$$$, the problem gets bigger...
> If there were money ("thanks for downloading the latest Apache binary
> distribution for your platform; would you care to contribute a few
> euros towards the generation and availability of what you just
> downloaded?"), it would be possible to maintain a set of machines
> running the appropriate set of system software to enable binbuilds to
> be reliably built for the largest possible audience.
>
> If a loosely affiliated group ("unencumbered friends of Apache") could
> accept contributions and maintain a rich set of binbuilds of Apache
> with/without SSL support, a lot of users would be happier and a lot of
> PRs could be closed with less hair turning gray but without breaking
> the user ("I'm sorry you are encountering this particular build SNAFU.
> It works fine for a number of people on that platform. There is a
> trusted binary build for your platform available from
> www.xxxxxx.org.").
>
> More than what you were interested I'm sure, but there are other
> frustrating aspects of binbuilds than just the encryption issue.
Well, I don't think that you need $$$, the only thing you really need is
hardware (for the builds), bandwidth (for downloads) and time (to build)...
The "unencumbered friends of Apache" could put time, hardware can be donated
(a nice web page saying "if you want a binary build for AIX, give me a nice
IBM box"), and bandwidth can be sponsored by someone (I mean, as long as you
put down a nice "Thank you to <LINK> for donating the bandwidth")... I'm
sure that (at least in the UK) someone like Clara.NET, Level3, or even Demon
would like the idea...
Pier
Re: distributing encryption software
Posted by Jeff Trawick <tr...@attglobal.net>.
Pier Fumagalli <pi...@betaversion.org> writes:
> As I said before... I believe that something can be done from here in old
> Europe to fix the problem.... Like distributing SSL binaries and stuff from
> here... Ok, they won't be on "www.apache.org", but....
I like that idea... I also am frustrated with the current binbuild
situation... Some users are not able to build themselves for various
reasons but our binbuilds, at least for Unix, present some problems.
Because there is no stable set of machines to do them on, the system
software levels vary and the dependencies of Apache change
accordingly, even within the same OS version.
I can't install OS updates on my AIX 4.3.3 box to run with the most
recent java levels if I want to do Apache 1.3 or 2.0 binbuilds which
will run on a lot of AIX machines. (but the dirty deed is already
done :( )
I can't install Solaris 8 from a recent enough CD-ROM set that has
sendfile if I want to do Apache 2.0 binbuilds which are usable by the
general Solaris 8 user community (you can't even download
sendfile+prerequisites without a maintenance contract last time I
tried).
Heck, even with Win32 there aren't many people who can do binbuilds,
and that is particularly bad when a security fix is announced and
everybody looks for the same one person.
If there were money ("thanks for downloading the latest Apache binary
distribution for your platform; would you care to contribute a few
euros towards the generation and availability of what you just
downloaded?"), it would be possible to maintain a set of machines
running the appropriate set of system software to enable binbuilds to
be reliably built for the largest possible audience.
If a loosely affiliated group ("unencumbered friends of Apache") could
accept contributions and maintain a rich set of binbuilds of Apache
with/without SSL support, a lot of users would be happier and a lot of
PRs could be closed with less hair turning gray but without breaking
the user ("I'm sorry you are encountering this particular build SNAFU.
It works fine for a number of people on that platform. There is a
trusted binary build for your platform available from
www.xxxxxx.org.").
More than what you were interested I'm sure, but there are other
frustrating aspects of binbuilds than just the encryption issue.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: distributing encryption software
Posted by Pier Fumagalli <pi...@betaversion.org>.
As I said before... I believe that something can be done from here in old
Europe to fix the problem.... Like distributing SSL binaries and stuff from
here... Ok, they won't be on "www.apache.org", but....
Pier
On 19/10/02 10:56, "Roy T. Fielding" <fi...@apache.org> wrote:
> Ryan asked for a clarification about whether or not we have the ability
> to redistribute SSL binaries for win32.
>
> Last year, the board hired a lawyer to give us an opinion on whether
> we can distribute encryption software, or hooks to such software.
> The exact opinion we got back is, unfortunately, not online, but it
> is essentially the same (with less detail) as the one given to Debian
> and visible at <http://debian.org/legal/cryptoinmain>. Basically,
> we have the right to distribute encryption software in source or
> executable form if we also distribute that same software as open
> source for free to the public, provided we first notify the U.S.
> authorities once per new encryption-enabled product.
>
> This is sufficient for Debian because they distribute the source code
> to everything in Debian within a single repository. Note, however,
> that we do not do the same for OpenSSL. Not only is OpenSSL not in
> our CVS, but it isn't normally distributed by us at all, and the
> authors of OpenSSL aren't likely to want us to distribute it because
> doing so pollutes the recipients rights with U.S. crypto controls
> whereas they could simply grab the same distribution from the origin
> and not be polluted.
>
> I think that Bill Rowe at one point requested that we seek out a
> lawyer's opinion on this specific matter, but that was not followed
> through by the board because we already know the legal aspects.
> The issue isn't legal -- it is social. We can download a released
> version of OpenSSL, compile it, and make both available from our
> website provided we first notify the BXA as described in the Debian
> opinion above. However, it is still preferable for our users to
> get the DLL themselves, from a distribution outside the U.S., and
> avoid having to maintain our distribution of OpenSSL up-to-date.
>
> I think a reasonable and defensible compromise would be to make
> it part of the win32 installation script -- to select no SSL or,
> if SSL is selected, to guide/automate the user in downloading an
> appropriate DLL from some other site. Besides, that would allow
> the user to pick some other SSL library, such as one of the
> optimized ones available commercially that may already be
> installed on their system. There is such a thing as being too
> concerned about "ease of installation."
>
> Finally, it should also be noted that the exception for Apache ONLY
> applies to non-commercial distributions. Any commercial distribution,
> even if it is simply Apache slapped onto a CD and sold for a buck,
> remains subject to the old US export controls that everyone hates,
> and must be approved via a separate process.
>
> ....Roy
>
>
>