httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: AW: restructuring mod_ssl as an overlay
Date Thu, 08 Jun 2006 12:00:29 GMT
Plüm wrote:
>>Von: Joe Orton
>>On Wed, Jun 07, 2006 at 02:03:33PM -0700, Roy T. Fielding wrote:
>>>Okay, let me put it in a different way.  The alternatives are
>>> 1) retain the status quo, forbid distributing ssl binaries, and 
>>>    include in our documentation that people in banned 
>>>    countries are not allowed to download httpd 2.x.
>>This gets my vote.

To prevent x number of people in the world from having a public discourse
via the web?  We are discussing people, software users, not governments.

I'm glad to hear your vote though.  Now I'll keep watching the list for
the recent RMs' and binary packagers' opinions on the matter.

Provided every member of this project agrees in general that information
and software distribution is good, and all politics aside, there's no reason
not to ensure broadest possible adoption of our tarballs sans crypto.

>>I don't see why it's necessary for the ASF to be in 
>>the business of distributing binaries; letting other people assume the 
>>technical and legal responsibilites for doing that seems reasonable.

Ahhh, the preface of what Roy pointed out.  Yes of course, since that's
what pays your salary I'm not terribly surprised... ("other people" being
the Red Hats, IBMs, Covalents, HPs, Suns etc etc.)  Let's face it, we
(collectively, as people paid to work within httpd's sphere of influence)
are supporting more and more customers who are -not- running some official
vendor package from our employeers, but rather supporting more who have
deployed an ASF package.

I actually think that a) says good things about us, and b) With continuing
vendor / packaging / configuration flaws, who blames them?

Of course, hrm... rather pays my paycheck, too.  Wonder why on earth I've
been putting up binaries at or advocating for resolution ;-?
Certainly it isn't to sell more copies of our companies' bundle.  Perhaps, it's
about overall project adoption, and giving back the favor of something that
I spent several hundred hours of voulenteer time 'hacking at', because I needed
to get up to speed on the technology for colocated unix, and had a few Win32
boxes sitting in front of me.  It happened to mostly work when I started using
it, learned it, deployed my customer's sites on unix after validating them in
Win32.  Oh - and fixed some things that didn't make sense.

Perhaps also, because there will always be room for vendor packages with all
of the associated QA and production release control, that doesn't altogether
exist in naked open source.  We should be about moving forward, and there
is your 'vendors and others' nitch ... let them (well, yes some of -us- wearing
our other hats) worry about the technical nits like production quality.

At home here in the states, just consider the impact of wireless, shared
cable segements and other public access points.  HTTP is a wonderful thing,
easy to debug, quite transparent.  In those environments, too transparent.
If more secured and user-identifing websites are encrypted, this is a net
win to the end users, and our webserver administrators.

Ahh but of course, you are talking about -windows- binaries that we should
not produce.  Of course, that would appear consistent with company policy.
And I see a few other binaries released recently, but oddly enough, no files
owned by jorton.  Perhaps ... while you scratch your itch, those who keep
filling that /dist/httpd/binaries/ tree will scratch theirs?

Let me offer that we've done a bad job mopping up insecure versions out of
the /dist/httpd/binaries/ tree and should decide on a method of reaping
stale packages.  And that I agree we need to make clear -everywhere- that
binaries are a convience, provided as a gift of one of the voulenteer project
members, not an expectation.  Some users have had misassumptions on this front
in the not-to-distant past.  Suggestions welcome.

>>The documentation work necessary would be greater if mod_ssl is split 
>>into a separate package, and having mod_ssl in the tree is one of the 
>>compelling features of 2.x anyway.

Yes, of course.  Minor nits - but import to close.  After all, we clearly
documented how to migrated from 2.0 to 2.2.

> Provided that we do not find a solution that allows us to keep mod_ssl inside
> the httpd tree (having an additional non ssl source tar ball that has the
> modules/ssl directory removed during rolling the package seems to be 
> acceptable to me (not knowing if this would solve our legal pains))
> I agree with Joe.

Roy's pointed out, IIUC, that notification was provided for cvs (erm, the svn
wasn't yet, was it?  Big todo and good reason to collect such datum in a central
repository of crypto-locations at the ASF, since this sort of thing will be
inevitably missed in refactoring, e.g. the cvs->svn transition) and that won't
be so critical.  Someone can check out svn in pieces.  They can grab a tarball,

So I don't think that factoring it out-of-the-tree is the right solution.
Providing an alternate tarball from our current working tree seems saner.

Roll-Release seems the right place to address this, e.g. we already create both
dos and unix lineending formats and then pack it up three ways.  It's not all
that much trouble to type in your pgp passphrase another few times, as the RM?


View raw message