Re: restructuring mod_ssl as an overlay
-Ursprüngliche Nachricht- Von: Colm MacCarthaigh 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. Just for my clarification: Keeping mod_ssl inside the tree would ban developer involvement (and downloads) from the T-8 countries, right? What is the actual list of T-8 countries? I found older lists that consist of Cuba, Syria, North Korea, Sudan, Iran, Libya, Iraq. I guess that Libya and Iraq have fallen of this list in the meantime. So that would mean that 5 countries would remain where we need to impose these restrictions, correct? Regards Rüdiger
Re: restructuring mod_ssl as an overlay
-Ursprüngliche Nachricht- Von: Roy T. Fielding 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 I totally agree, but I fear that this approach will not bring us to a solution any time soon :-). Regrettably we have to deal with the legal situation as it is and find the best way out. Regards Rüdiger
Re: restructuring mod_ssl as an overlay
On Thu, Jun 08, 2006 at 02:47:59PM -0700, Roy T. Fielding wrote: 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. OK, this is certainly a big deal. Would only committers count as participating in the project for this purpose, do you think? Random people submitting patches would not? Regards, joe
Re: restructuring mod_ssl as an overlay
-Ursprüngliche Nachricht- Von: Joe Orton [ Would only committers count as participating in the project for this purpose, do you think? Random people submitting patches would not? Stupid question: How can someone who is not allowed to download the sources can submit patches? :-). Regards Rüdiger
Re: restructuring mod_ssl as an overlay
On Fri, Jun 09, 2006 at 12:29:06PM +0200, Plüm, Rüdiger, VF EITO wrote: -Ursprüngliche Nachricht- Von: Joe Orton [ Would only committers count as participating in the project for this purpose, do you think? Random people submitting patches would not? Stupid question: How can someone who is not allowed to download the sources can submit patches? :-). There is *nothing* preventing them from downloading and using our sources. That's a non-issue :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Knocking items off the plate, one by one
Before Dublin, I'd like to scratch several of my own itches to start with something of a 'blank page' and moving forward with new stuff, rather than our usual rehashes @ the hackathon. Numero Uno is to permanantly remove apache 1.3.x from our live http://www.apache.org/dist/httpd/binaries/win32/ site, I have no interest in rolling 1.3.36 since it solves no apparent problems that 1.3.34 had, but moreso, httpd 2.0 is well over four years old. http://archives.apache.org/dist/httpd is always out there ;-) I simply have no reason to roll 1.3.x binaries as there is no sane reason for them to continue to be used on Windows. (As I've said before, on Unix I'm entirely neutral.) Please vote; [ ] Jettison apache/win 1.3 binaries to a footnote of history in archives [ ] Beg of Bill, One more Round! of 1.3.36 for old times sake [ ] Keep them available from www even if they are never updated again [ ] I'm insane, I'll take over rolling 1.3, fill me in on the procedure Bill? If jettisoned, I'll simply remove any 1.3 language from the page. There is already a note Looking for older binaries? Please don't which goes on to point out where they live for the sadists. That should cover it. Any other thoughts? Second verse, same as the first, we have some _old_ directories lingering in httpd/binaries/..., I will kill these today once I know for a fact they are mirrored already on archives.apache.org (I thought we had killed these before.) Third verse (sing along!) our web site reports Fixed in Apache httpd 1.3.32 moderate: mod_proxy buffer overflow CVE-2004-0492 Fixed in Apache httpd 2.0.55 moderate: HTTP Request Spoofing CVE-2005-2088 Each of these is out of the control of the operator once they enable common features, as opposed to other more recent, very specific flaws that need specific configuration, unusual use cases or local web administration access to trigger or reproduce. (Who uses IMAP lol?) So the final vote that we need to have a concensus on is; [ ] Remove all pre 2.0.55/pre 1.3.32 binaries from www.a.o (to archive.a.o) [ ] Leave the last unmaintained 2.0.x in whatever state it's in [ ] Leave the last unmaintained 1.3.x and 2.0.x in whatever state they are in Votes/comments please? Thanks, Bill
Re: Knocking items off the plate, one by one
On Fri, Jun 09, 2006 at 01:02:23PM -0500, William A. Rowe, Jr. wrote: From the peanut gallery [X] Jettison apache/win 1.3 binaries to a footnote of history in archives I'd even go as far as removing all of them or if _really_ wanting to keep one, then keep the latest around but be ready to remove that if any security problems are discovered in the future. [ ] Remove all pre 2.0.55/pre 1.3.32 binaries from www.a.o (to archive.a.o) [ ] Leave the last unmaintained 2.0.x in whatever state it's in [ ] Leave the last unmaintained 1.3.x and 2.0.x in whatever state they are in [X] As above - keep the latest as long as it is good, but be ready to remove it. I don't really see much reason for having 2.0.x bins at all, but keeping old ones around is just asking for trouble imho. Sure, if someone wants to roll bins from 2.0, then no problem - but keeping an archive of old versions is just like giving people enough rope... vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: svn commit: r413158 - /httpd/site/trunk/xdocs/download.xml
On 06/09/2006 10:47 PM, wrote: Author: wrowe Date: Fri Jun 9 13:47:02 2006 New Revision: 413158 URL: http://svn.apache.org/viewvc?rev=413158view=rev Log: Note 2.2.2 was our 10 year celebration I believe, (just to put something interesting front and center under that top announcement, and declare this is the definative recommended version.) Maybe nitpicking, but I think 2.2.0 was released exactly at the 10th anniversary. But of course 2.2.2 represents *over* 10 years of innovation, so the text is still fine :-). Regards Rüdiger
Re: Knocking items off the plate, one by one
On 06/09/2006 08:02 PM, William A. Rowe, Jr. wrote: I'm entirely neutral.) Please vote; [X] Jettison apache/win 1.3 binaries to a footnote of history in archives [ ] Beg of Bill, One more Round! of 1.3.36 for old times sake [ ] Keep them available from www even if they are never updated again [ ] I'm insane, I'll take over rolling 1.3, fill me in on the procedure Bill? So the final vote that we need to have a concensus on is; [X] Remove all pre 2.0.55/pre 1.3.32 binaries from www.a.o (to archive.a.o) [ ] Leave the last unmaintained 2.0.x in whatever state it's in [ ] Leave the last unmaintained 1.3.x and 2.0.x in whatever state they are in Votes/comments please? Please find my X'es above. Regards Rüdiger
Re: svn commit: r413158 - /httpd/site/trunk/xdocs/download.xml
Ruediger Pluem wrote: On 06/09/2006 10:47 PM, wrote: Author: wrowe Date: Fri Jun 9 13:47:02 2006 New Revision: 413158 URL: http://svn.apache.org/viewvc?rev=413158view=rev Log: Note 2.2.2 was our 10 year celebration I believe, (just to put something interesting front and center under that top announcement, and declare this is the definative recommended version.) Maybe nitpicking, but I think 2.2.0 was released exactly at the 10th anniversary. But of course 2.2.2 represents *over* 10 years of innovation, so the text is still fine :-). True - I'm glad I didn't edit to say 2.2.2 celebrates - I believe you were (even if it's not an exact science dating these things, I believe that's what we attributed 2.2.0 for ;-)
Re: Knocking items off the plate, one by one
On Jun 9, 2006, at 12:57 PM, Mads Toftum wrote: I don't really see much reason for having 2.0.x bins at all, but keeping old ones around is just asking for trouble imho. Here's a scenario: I have mod_x, compiled against Apache HTTP Server version y. The maker of mod_x are bitches and do not keep up with Apache development, so when the MMN change, the module breaks. They say mod_x is supported with Apache 2.0.y. Go get Apache 2.0.y if you want to use mod_x. Sorry, we cannot support versions of Apache later than 2.0.y. Don't even think about mentioning Apache 2.2. Now give us all your money. It would be a great thing if I could download a binary of Apache HTTP Server version y to drop mod_x into, especially on platforms that do not come with a C compiler (cough Win32 cough). This would make life considerably easier if I had to quickly integrate mod_x, or if I had to replicate my customer's deployment environment down to the xes and ys. In fact, this very scenario happened to me with Tomcat where I ran into some very finnicky version dependencies. Now we, in httpd land, don't habitually rewrite our entire project between dot versions, but it might be a good idea to make available a binary for the last released version before a major MMN bump. Disk is (fairly) cheap after all. What trouble? Do we ever make any claims about our software beyond if it breaks, you get to keep the pieces? Source or otherwise? S. -- [EMAIL PROTECTED]http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: Knocking items off the plate, one by one
Sander Temme wrote: On Jun 9, 2006, at 12:57 PM, Mads Toftum wrote: I don't really see much reason for having 2.0.x bins at all, but keeping old ones around is just asking for trouble imho. What trouble? Do we ever make any claims about our software beyond if it breaks, you get to keep the pieces? Source or otherwise? Well, although I agree with Sander's assessment as far back as 2.0, I'm not really fond of the argument to hang on to win32 1.3 specifically. Unix? If one is packaged and doesn't have a vulnerability, sure. Just make sure it's not the first choice displayed for the user to pick from, shown anywhere. And no, we don't warrentee the software. But someone has to go through and close worthless bug reports, triage #apache irc traffic, triage [EMAIL PROTECTED] traffic. Not saying this is you - or me even. In fact that's why I asked, because I figure the people who are kind enough to even both doing these tasks are the ones to decide how long a stale source or binary package aught to be hanging around. As far as -this- list is concerned, I hope we are mostly excited for 2.e.x stable and 2.o.x alpha and beta offerings that we are actually trying to improve :) Anyone dwelling heavily in improving 1.3 or 2.0 is really saying to the list, here's my pocket veto of what you did in the current trunk. Anyone dwelling on fixing 1.3 or 2.0 - just to keep it working, well I think most of them fall in Sander's camp - alot of folks must have some server that is running mod_slowvendor, and they can't yet make a move, or worse, they don't have internal engineering resources to move mod_ourfoo which some dev long gone customized at the company. So nothing against fixing bugs or keeping a 2.0 around at least as long as it takes us to make 2.4 happen, here. I'm partial to making 1.3 win32 binaries go away, and I'm partial to making any inherently insecure binary go away. Beyond that shrug/. Bill
Re: restructuring mod_ssl as an overlay
On Jun 9, 2006, at 3:56 AM, Colm MacCarthaigh wrote: On Fri, Jun 09, 2006 at 12:29:06PM +0200, Plüm, Rüdiger, VF EITO wrote: -Ursprüngliche Nachricht- Von: Joe Orton [ Would only committers count as participating in the project for this purpose, do you think? Random people submitting patches would not? Stupid question: How can someone who is not allowed to download the sources can submit patches? :-). There is *nothing* preventing them from downloading and using our sources. That's a non-issue :-) Right, the only issue is the ASF knowingly exporting to a known person in the banned category. For that reason, we may be better off publishing all the disclaimers for every project and tell the recipients to self-enforce. We have no way of knowing where people are geographically located or what their citizenship may be, unless they insist on telling us. Everything else is covered by the TSU exception because our technical discussions are limited to public lists. http://www.access.gpo.gov/bis/ear/txt/740.txt In case anyone is wondering, yes we have talked to lawyers, several times, and the result was partial -- we do qualify for the TSU exception. However, even the lawyers neglected to mention that TSU section 740.13.e.2(ii) excludes (ii) Any knowing export or reexport to a country listed in Country Group E:1 in Supplement No. 1 to part 740 of the EAR. and the best practice of publishing export guidelines on the website to cover that paragraph is a relatively recent invention. The only way to get a definitive ruling is to ask BIS for one (the western regional office is in my town) prior to the first export. The ASF has, instead, been operating according to the published regulation in the EAR note Note to paragraph (e). Posting encryption source code and corresponding object code on the Internet (e.g., FTP or World Wide Web site) where it may be downloaded by anyone neither establishes knowledge of a prohibited export or reexport for purposes of this paragraph, nor triggers any red flags necessitating the affirmative duty to inquire under the Know Your Customer guidance provided in Supplement No. 3 to part 732 of the EAR. being sufficient to represent guidance from BIS that what we have been doing is allowed. In addition, section 744.9 (Restrictions on technical assistance by U.S. persons with respect to encryption items) applies to those of us residing in, or citizen of, the U.S. and the presence of the TSU exception to our work makes that okay as well [woohoo, it also solves the issue of ASF folks speaking at conferences]. The Country Group E:1 can be found in http://www.access.gpo.gov/bis/ear/pdf/740spir.pdf Today's list says Cuba, Iran, North Korea, Libya, Sudan, and Syria, with Cuba, Iran, and Sudan being subject to a separate, comprehensive embargo as well. After reading through this again, I've decided to change my vote from undecided to keeping the product as is and adding the export notices to our site. Otherwise, I wouldn't know what to do about the comprehensive embargoes even if we split the project. Roy
