Re: restructuring mod_ssl as an overlay
> Roy wrote... > > The sane solution would be to convince the US government to remove> encryption from the export control list, since that regulation has> been totally ineffective. That is not likely to happen during this> administration, though, and I don't think the ASF is allowed to> lobby for it directly. Not going to happen in our lifetimes. Since World War II, when modern cryptography/encryption/decryption turned out to be the deciding factor in the conflict itself, it's all been classified as 'muntions' right along with firearms and explosives and, as such, is ( now ) under the jurisdiction of the ATF ( Bureau of Alchohol, Tobacco and Firearms. ) It isn't just a State Department policy thing. Any change in the policy would involve tons of government agencies, not just one. > Roy also wrote... > > If anyone can think of another option, I'd like to hear it before> proposing a vote. Here's another option before doing anything drastic... ...get a professional opinion. Roy... you have done fantastic research but I am seeing a lot of 'assumptions' in all the postings. ( Yours and others ). This isn't really something to get into with any 'assumptions'. You should be SURE that any changes are going to gey you ( ASF ) where you want to be. Hypotheticals are fun but they don't get the horses into the barn. Here is just one example from the postings... but an important one... > The mere presence of mod_ssl source code appears to be sufficient to> make the product as a whole covered by 5D002 export controls --keyword=appears Does it, or doesn't it? mod_ssl is just a module. It doesn't do squat unless the OTHER ( Non ASF ) product is included in the compile. It's just a bunch of hooks into someone else's product. Are you SURE mod_ssl alone puts ASF into a 'danger zone' at all? Another example would be the early posting where the (little) crypto that IS included in Apache was shrugged off as 'insignificant'. ( MD5, SHA, Hashes, whatever ). Well... maybe that's a reverse case where ASF is assuming that isn't a problem but might, in fact, cause someone who doesn't really, really understand these things ( like some Justice Department lawyer ) some consternation. Best bet is for ASF to actually get a RULING on the technology from the State Department or whoever it is that would prosecute down the road if their 'assumptions' don' t match your 'assumptions'. Get it from the horse's mouth. Get it in writing. You could pay tons of lawyers to look into this and they could all still turn out to be wrong. The only people who know what will satisfy them are the people who would prosecute a violation. ATF? They have jurisdiction for prosecution. Maybe they are the ones who can supply the rulings. You asked for additional options before going to vote. That's my 'additional option'. Wait... and find out the exact nature of the problem and then be SURE the changes provide the proper solution ( if there even is a problem in the first place ). Yours... Kevin
Re: restructuring mod_ssl as an overlay
Roy T. Fielding wrote: > > ... The big deal is that 5D002 > classification also means that it is illegal for the ASF to knowingly > allow anyone residing in, or a citizen of, the T-8 countries, or anyone > on the "denied persons list", to even participate in our project, > let alone download packages, since that participation would be a > "deemed export"... > > ... However, if the group would prefer to keep mod_ssl within the package, > then we have to take the appropriate actions in our documentation and > committer policies. ... > > So, I guess the real question is: do we follow the example of Mozilla > et al and simply publish as 5D002 with the appropriate documentation, > or do we make an attempt to separate the products in a way that one > half is unrestricted and the other is 5D002? > My pref is the 1st option, since that seems the easist for us to handle, and the most appropriate for us. Seperation is unwieldy for a variety of reasons, and it seems to me that following the already established processes of other "affected" organizations is the safest. It also allows for some sort of "collaboration" of this issue among us as well. Of course, this is also applicable for other ASF projects that use SSL, such as Tomcat with tcnative/JNI. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: restructuring mod_ssl as an overlay
On Jun 8, 2006, at 3:38 PM, Colm MacCarthaigh wrote: Another option is that we could ask the ASF to formally consider upping roots and changing jurisdiction. I have little doubt over what the answer would be, but I'd prefer that we exhaust all of the alternative options before doing anything which would intentionally prohibit developer participation. That would only shift the burden onto individuals within the US. OpenSSL essentially does that, but at the cost of being separate. The ASF can't move -- it can only allow some other group to copy the code base and fork. The sane solution would be to convince the US government to remove encryption from the export control list, since that regulation has been totally ineffective. That is not likely to happen during this administration, though, and I don't think the ASF is allowed to lobby for it directly. Roy
Re: restructuring mod_ssl as an overlay
On 6/8/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote: Another option is that we could ask the ASF to formally consider upping roots and changing jurisdiction. I have little doubt over what the answer would be, but I'd prefer that we exhaust all of the alternative options before doing anything which would intentionally prohibit developer participation. Moving to, say, the Bahamas just to evade US crypto laws is not a practical response for such a minor concern. -- justin
Re: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 02:47:59PM -0700, Roy T. Fielding wrote: > If anyone can think of another option, I'd like to hear it before > proposing a vote. Another option is that we could ask the ASF to formally consider upping roots and changing jurisdiction. I have little doubt over what the answer would be, but I'd prefer that we exhaust all of the alternative options before doing anything which would intentionally prohibit developer participation. After that, based on your excellent summary, I'm begining to see the wisdom of a subproject - despite the overhead, maximising developer involvement and the potential community size is much more important. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
On 06/08/2006 11:47 PM, Roy T. Fielding wrote: > Sorry, I did a poor job of explaining -- the binaries issue is about > openssl. The openssl issue is what required me to read the EAR No reason to say sorry. Thanks for your work on this issue. > The mere presence of mod_ssl source code appears to be sufficient to > make the product as a whole covered by 5D002 export controls, which means > we can distribute both source and binaries under the TSU exception iff > the binaries are built from a 100% open source package that we can point > to with a URL. That is no big deal. The big deal is that 5D002 > classification also means that it is illegal for the ASF to knowingly > allow anyone residing in, or a citizen of, the T-8 countries, or anyone > on the "denied persons list", to even participate in our project, > let alone download packages, since that participation would be a > "deemed export". That is why I suggested a separate (sub)project, > so that the "httpd" product could exist separately and be completely > open to participation and downloads. Just making it a release-time > build separation is not sufficient. Many thanks for this clarification. > > However, if the group would prefer to keep mod_ssl within the package, > then we have to take the appropriate actions in our documentation and > committer policies. I do not think we would be in any danger of the > FBI making an example of us provided that we publish the same export > guidelines as all the other software companies. > > So, I guess the real question is: do we follow the example of Mozilla > et al and simply publish as 5D002 with the appropriate documentation, Just to get it clear: This would be the option to leave mod_ssl where it is and update the documentation of httpd in a way that we comply with US export laws, right? And updating the documentation would (roughly speaking) lead to a situation where we state that no one from the T-8 countries is allowed to download httpd (not only binaries, but also the sources) or to take part in the project (which would be hard to do anyway without sources :-)). > or do we make an attempt to separate the products in a way that one > half is unrestricted and the other is 5D002? And that would be the option to move mod_ssl to a subproject with an appropriate documentation that complies with US export laws and having the remaining core httpd freed of all the restrictions and rules imposed by the US export laws, right? Regards Rüdiger
Re: restructuring mod_ssl as an overlay
Sorry, I did a poor job of explaining -- the binaries issue is about openssl. The openssl issue is what required me to read the EAR guidelines, but my response is based on what I learned about the EAR in general. The mere presence of mod_ssl source code appears to be sufficient to make the product as a whole covered by 5D002 export controls, which means we can distribute both source and binaries under the TSU exception iff the binaries are built from a 100% open source package that we can point to with a URL. That is no big deal. The big deal is that 5D002 classification also means that it is illegal for the ASF to knowingly allow anyone residing in, or a citizen of, the T-8 countries, or anyone on the "denied persons list", to even participate in our project, let alone download packages, since that participation would be a "deemed export". That is why I suggested a separate (sub)project, so that the "httpd" product could exist separately and be completely open to participation and downloads. Just making it a release-time build separation is not sufficient. However, if the group would prefer to keep mod_ssl within the package, then we have to take the appropriate actions in our documentation and committer policies. I do not think we would be in any danger of the FBI making an example of us provided that we publish the same export guidelines as all the other software companies. So, I guess the real question is: do we follow the example of Mozilla et al and simply publish as 5D002 with the appropriate documentation, or do we make an attempt to separate the products in a way that one half is unrestricted and the other is 5D002? Those are the two choices that *we* need to discuss (choosing to do neither is not an option now that I have a vague understanding of EAR and how larger institutions like Stanford U. have chosen to enforce it). If anyone can think of another option, I'd like to hear it before proposing a vote. Once we make a decision on the technical contents of the project, Cliff and I can work out the legal requirements and BIS notices in a way that can be applied across the ASF. Roy
Re: AW: restructuring mod_ssl as an overlay
^^^ see subject ^^^ There are quite a few reasonable alternative strategies for dealing with that kind of scenario. Does the ASF have such a policy as a matter of course, regardless of the severity of such an action? really sort of off topic; yes the mechanisms to handle this have existed since day one and they are at [EMAIL PROTECTED]
Re: AW: restructuring mod_ssl as an overlay
On 06/08/2006 07:13 PM, William A. Rowe, Jr. wrote: > > I will say this; the people who are wildly waving their arms "no more > binaries" are the same people who, surprise, haven't contributed binaries > to httpd, at least not lately (little surprise). This is true, but I do not think that people are against binaries as such, they (including me) do not like certain consequences that seem to arise from providing binaries like the discussed need to move mod_ssl to a subproject. So they favour not having to deal with the consequences over providing binaries. As you stated yourself in a different mail on this subject, binaries are a convience not an expectation. > > 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. This is also my view. > on a few voices today, that it will not ship openssl binaries in particular. > How this differs from shipping libexpat, libz or libpcre binaries is beyond > my grasp, other than some recordkeeping. But if that's concensus become libpcre: As I took from earlier discussion on the list we have special requirements in libpcre and most stock libpcre will not work. Furthermore I think it is not possible to build a version of httpd that does not need libpcre. libz: Convenience on platforms where the OS does not deliver it (mostly windows?). As far as I can see this is only needed if you want to build mod_deflate. libexpat: Also convenience. Although XML seems to be only needed for mod_dav I am not quite sure if you can build httpd without libexpat. But there is a big difference to openssl: Providing these libraries does not result in similar legal pain as providing openssl and has no further consequences for the project that at least some people not like. Regards Rüdiger
Re: AW: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 11:07:51AM -0700, Justin Erenkrantz wrote: > On 6/8/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote: > >There are quite a few reasonable alternative strategies for dealing with > >that kind of scenario. Does the ASF have such a policy as a matter of > >course, regardless of the severity of such an action? > > As that hasn't happened yet, there is no set policy - except that we > would take it very seriously. Absolutely, I'm just hoping we'd explore things like licensing for nominal fee and so on. It hardly matters, it's for another day :-) One way in which it may be related though, is that in the past we've made some changes to openssl to get it to compile, and we wondered if that meant we'd have to put the resulting OpenSSL on tarball on a.o. We need to be careful about the patent-encumbant source code those tarballs contain too. Just something to watch out for. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
On 6/8/06, Joe Orton <[EMAIL PROTECTED]> wrote: Thanks for doing the research, Roy. Ditto. 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. 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. 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. Overall, I think forbidding the distribution of the SSL-enabled binaries is probably the sanest thing technically and legally for us to do. I understand the arguments about the Win32 folks not having SSL out of the box, but I don't think that particular advantage outweighs the social and technical problems with creating two separate versions of the distributions. So, +1 to keeping the status quo (always my favorite!). -- justin
Re: AW: restructuring mod_ssl as an overlay
On 6/8/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote: There are quite a few reasonable alternative strategies for dealing with that kind of scenario. Does the ASF have such a policy as a matter of course, regardless of the severity of such an action? As that hasn't happened yet, there is no set policy - except that we would take it very seriously. We have had informal issues with potential copyright violations (all of which have been resolved amicably) - in those cases, we have tended to lock down the repositories fairly quickly while we investigate further. Unfortunately, copyrights aren't as straightforward as patents. So, *if* the ASF were to receive a formal notice regarding patent infringement, I would believe the relevant decision-making parties would be the Board, VP Legal, Counsel(s), and the relevant PMC Chair. -- justin
Re: AW: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 12:16:02PM -0500, William A. Rowe, Jr. wrote: > Colm MacCarthaigh wrote: > > > >Suffice it to say that even a cursory glance at a patents register > >would likely reveal many ludicrous patents which httpd may infringe. > > Yup; if the claimant to any such -legitimate- patent comes knocking, > it *will* be removed from svn and the project, in case you had any > doubts. There are quite a few reasonable alternative strategies for dealing with that kind of scenario. Does the ASF have such a policy as a matter of course, regardless of the severity of such an action? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [PATCH] mod_speling
This looks fine, but can you add a patch to the docs? The feature isn't useful if nobody knows it's there. Thanks, -wsv On May 30, 2006, at 4:30 PM, olivier Thereaux wrote: Hello, This is a followup to a (very) old thread about mod_speling on the httpd-dev list: http://mail-archives.apache.org/mod_mbox/httpd-dev/23.mbox/% [EMAIL PROTECTED] On Fri, Mar 03, 2000, Hugo Haas wrote: On Fri, Mar 03, 2000, Martin Kraemer wrote: On Thu, Mar 02, 2000 at 04:22:36PM -0500, Bruce R Miller wrote: [..] Our thought was to add an option, (CheckSpelling CaseOnly, instead of CheckSpelling on, or ...) that would have it automatically redirect _only_ if it were a case correction Yes, the proposal to even restrict the functionality to case correction ONLY has been suggested a while ago. I would welcome this, too, because mod_speling can be misused to "poke around" and look what other file are there I coded that some time ago. I will send you the patch as soon as I find it. :-) It appears that patch was never sent to the apache developers' community, but we have actually been using it on the W3C Web site for many years, where it has allowed us to enable mod_speling for user convenience, without creating too huge a volume of phantom URIs. I have recently dug up the patch, and adapted it for each major version of the apache httpd server (based on the sources for the 1.3.6, 2.0.58 and 2.2.2 releases). The three patch files are attached to this mail. Would it be possible to have these applied to the code tree? If so, I guess there would be documentation changes, as well, and I would be more than happy to help with those, too. Kind regards, olivier. -- olivier Thereaux - W3C - http://www.w3.org/People/olivier/ W3C Open Source Software: http://www.w3.org/Status
Re: AW: restructuring mod_ssl as an overlay
Colm MacCarthaigh wrote: Suffice it to say that even a cursory glance at a patents register would likely reveal many ludicrous patents which httpd may infringe. Yup; if the claimant to any such -legitimate- patent comes knocking, it *will* be removed from svn and the project, in case you had any doubts. Of course it's encumbant upon them to point this out to us, they know where to find us, and the infringing source code that documents the use. Bill
Re: AW: restructuring mod_ssl as an overlay
Jeff Trawick wrote: Just curious: does anybody in that boat actually think that anything we httpd-ers could do with packaging httpd (binaries, SSL,etc.) would conceivably compete with what our employers are providing? (I find that preposterous personally) rofl - no. I will say this; the people who are wildly waving their arms "no more binaries" are the same people who, surprise, haven't contributed binaries to httpd, at least not lately (little surprise). Yes this affects win32, and solaris pkg's and rpm's and a whole lot of other things in /dist/httpd/binaries/... There are some platforms (e.g. Linux) where you always have a compiler, and it seems linux biggots are the loudest "no binaries!" camp. Then there are others where installing a compiler varies between argrivating (solaris) to expensive. If it's not "encumbered", why not distribute a binary someone is willing to build, as opposed to arguing over the merits of them. Of -course- if nobody cares to contribute a binary for platform Foo, such is life. Now nearly every major open source project that supports OS/X and Win32 ships binaries for OS/X and Win32, and some folks happened to have built those, and others. Oooh... I almost forgot, platforms where compilers come along and are still aggrivating to use ;-) Encumbered; e.g. who's built a binary that is sitting in dist that has -lssl -lcrypto? I'm betting quite a few, I just don't feel like tearing that tree apart this month. I think this is getting absurd, Roy says "don't ship binaries" as one extreme reaction (not in a negative context, but an observation) and all the aolusers chime in. Either binaries float your boat or they don't. Isn't the httpd project about scratching your own itch? Anyways, I've come to the conclusion that the httpd project's decided, based on a few voices today, that it will not ship openssl binaries in particular. How this differs from shipping libexpat, libz or libpcre binaries is beyond my grasp, other than some recordkeeping. But if that's concensus become policy, then I'm happy to ditch any effort to provide win32 users mod_ssl. You folks really aren't worth this aggrivation. Bill
Re: AW: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 12:01:16PM -0500, William A. Rowe, Jr. wrote: > Colm MacCarthaigh wrote: > >What's next, do we start stripping patented methods from our tarball > >and making that available too? > > Uhm which patent *encumbered* methods? If I were to identify any or perform a patent search, that would make matters about a hundred times worse for all you US-based contributors, so I'm going to decline that particular honour ;-) Suffice it to say that even a cursory glance at a patents register would likely reveal many ludicrous patents which httpd may infringe. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: AW: restructuring mod_ssl as an overlay
Colm MacCarthaigh wrote: What's next, do we start stripping patented methods from our tarball and making that available too? Uhm which patent *encumbered* methods?
Re: AW: restructuring mod_ssl as an overlay
On 6/8/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
Plüm wrote:
>
>>Von: Joe Orton
>>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...
tread lightly... very easy to be misinterpreted here, particularly by
random users...
("other people" being
the Red Hats, IBMs, Covalents, HPs, Suns etc etc.)
Just curious: does anybody in that boat actually think that anything
we httpd-ers could do with packaging httpd (binaries, SSL,etc.) would
conceivably compete with what our employers are providing? (I find
that preposterous personally)
(OTOH, if there is a solid business case for providing simply a binary
of httpd with suitable features that is known to work on at least some
handful of machines, please let me know ;) )
Re: httpd-win.conf broken on trunk
On 6/1/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: Garrett Rooney wrote: > > One thing that seems odd, it looks like Makefile.win is still copying > docs/conf/httpd-win.conf to conf/httpd.conf.default, isn't the goal of > the previous changes to get a massaged version of httpd-std.conf.in > there? future tense, yes. These were just glaring things I tripped over and streamlining the extras copy that were already committed. I think the one issue with using httpd-std.conf.in is the list of modules to load; netware has an awk script which accomplishes this - perhaps we piggyback on the same script? Seems reasonable to me. -garrett
Re: AW: restructuring mod_ssl as an overlay
> -Ursprüngliche Nachricht- > Von: Colm MacCarthaigh > > > On Thu, Jun 08, 2006 at 08:16:48AM -0500, William A. Rowe, Jr. wrote: > > The group of people who concern me are not those in T-8, > they are those who > > live in jurisdictions where *they* would be breaking local > law by possessing > > crypto. Leave them a) in the backwaters / b) in fear / c) > in violation, or > > give them a silly httpd-2.2.x-no-ssl.tar.gz? The later > seems sane to me. > > The personal liabilites of users are not our concern. That's > strictly a > matter for users and their legal counsel. What's next, do we start And they would be a target hard to hit. US export controls are one fixed (complex) issue, but trying to deliver packages (whether source or binary) that do not violate laws in (almost) all contries over the world seems undoable to me. Apart from this I do not think that this should be our task. Regards Rüdiger
Re: AW: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 08:16:48AM -0500, William A. Rowe, Jr. wrote: > The group of people who concern me are not those in T-8, they are those who > live in jurisdictions where *they* would be breaking local law by possessing > crypto. Leave them a) in the backwaters / b) in fear / c) in violation, or > give them a silly httpd-2.2.x-no-ssl.tar.gz? The later seems sane to me. The personal liabilites of users are not our concern. That's strictly a matter for users and their legal counsel. What's next, do we start stripping patented methods from our tarball and making that available too? If the no-ssl tarballs are to be of any use it is in aiding the ASF in presenting a reasonable best-effort defence in relation to US export controls. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: AW: restructuring mod_ssl as an overlay
Joe Orton wrote: If you think there is some group of users who want to be able to download the "crypto"-enabled httpd tarballs in $BANNEDCOUNTRY but refuse to do so because they don't want to violate US export regulations, then maybe that should be addressed separately. The group of people who concern me are not those in T-8, they are those who live in jurisdictions where *they* would be breaking local law by possessing crypto. Leave them a) in the backwaters / b) in fear / c) in violation, or give them a silly httpd-2.2.x-no-ssl.tar.gz? The later seems sane to me. This list of countries is rapidly shrinking, but remember even parts of western europe were subject to such laws not 10 years ago. would the SSL support have to be patched out of ab? Good point, I don't know that we ever notified BIX of that purpose. What about the SSL use in the LDAP code? Good point, I'm certain we didn't notify BIX of that purpose. And while we are at it, mod_ftp in incubation has the same issue with both explicit and implict FTP SSL. And we appreciate your raising these issues, as Roy's working hard to bring us into compliance with -our- relevant regulations, in this case, export controls. Bill
Re: AW: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 07:00:29AM -0500, William Rowe wrote: > 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 can't see how changing the documentation to comply with US export regulations will have any such effect. If you think there is some group of users who want to be able to download the "crypto"-enabled httpd tarballs in $BANNEDCOUNTRY but refuse to do so because they don't want to violate US export regulations, then maybe that should be addressed separately. I can't see that this would be anything other than a nightmare to attempt: would the SSL support have to be patched out of ab? What about the SSL use in the LDAP code? Regards, joe
Re: restructuring mod_ssl as an overlay
On Jun 7, 2006, at 4:03 PM, Roy T. Fielding wrote: Given those constraints, I would prefer to separate the httpd releases into a non-crypto package and a crypto overlay, similar to what most of the packaging redistributors do (fink, apt, etc.). Is the concern that we bundle mod_ssl with httpd via source or that we also provide binary packages which have mod_ssl? I think, personally, we should just release the source and drop the whole binary packages as well. If that doesn't address the issue, then I think we should have 2 releases: one with mod_ssl and one without.
Re: AW: restructuring mod_ssl as an overlay
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 httpd.apache.org 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,
instead.
So I don't think that factoring it out-of-the-tree is the right solution.
Providing an alternate tarball from our curr
Re: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 11:01:12AM +0100, Joe Orton wrote: > 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. 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. > +1. I'd really like to see the current source stay as it is with mod_ssl included. If anything, it shouldn't be too hard to produce a patch that strips out mod_ssl at release time if we want to roll an extra non crypto version for that handfull of countries. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
AW: restructuring mod_ssl as an overlay
> -Ursprüngliche Nachricht- > Von: Joe Orton [ > > Thanks for doing the research, Roy. Yep, thanks from me too. > > 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. 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. > > 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. 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. Regards Rüdiger
Re: restructuring mod_ssl as an overlay
Thanks for doing the research, Roy. 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. 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. 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. Regards, joe
