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]
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
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
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: 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: 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: 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
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 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 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
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
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
On Wed, Jun 07, 2006 at 01:03:48PM -0700, Roy T. Fielding wrote: c) each redistributor (re-exporter) of our packages must do the same [I am unsure if that means every mirror is supposed to file as well, but for now I am guessing that they don't]; They don't :) e) people who are in the banned set of countries and people in countries that forbid encryption cannot legally download the current httpd-2 packages because they include mod_ssl even when it won't be used. I don't see how this can possibly be the case. If crypto code is illegal locally, then it is illegal locally and people need to figure that out from themselves. If a person happens to live in a country which is on the USA's banned list, there's nothing illegal (purely from their perspective) about their act of download, US law does not apply to them. Surely the illegality is that the ASF exports the code to those countries, and if anyone is answerable to those particular laws it is any US-based exporter of the code. I just want to be clear about this distinction, if it's correct. Or is there a suggestion that the situation invalidates the user's license? (contracts can be invalidated when a law is broken, but it's complex stuff). I think the best way to accomplish that is to separate mod_ssl into a subproject that is capable of producing overlay releases for each release of httpd. yuck! -1 Thoughts? Anyone have any better ideas? Is the mere legal registration of the ASF within US borders a solid stumbling block here? As in, could the situation be remedied by forbiding US-based distributors? (Similar to what Debian used to do with it's non-US repositories). -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
Roy T. Fielding wrote: Thoughts? Anyone have any better ideas? +1 to an overlay; I know you have - but for the rest of the participants, also consider that it 'illegal' to have crypto in some jurisdictions (and actually if you are traveling to some jurisdictions it's best to leave your ssl enabled laptop with all of the cool crypto features as home.) This would help people who are complying with jurisdictional restraints to avoid the whole issue and to continue to use httpd. I won't add any political comments in this thread about this wisdom of said laws. On the T-8 prohibited countries list, note it is a crime to export technologies to them (it's hard for the US to define a crime to obtain said technologies in a foreign jurisdiction - let's not get into that debate). However, as a 'public download' I believe we are now exempted from trying to discern where these parties are. Providing both the base server and an ssl feature demonstrates good faith that we are providing unrestricted access to our httpd sources, and permitting our users to avoid mod_ssl/crypto. On very important points; we have to file export notices prior to each release in which the crypto capabilities are changed; This means the strength of the crypto or feature set. This doesn't mean that if we fix a null-deref bug we provide notification. Does apr's sha1 and m5 hashing still fall into this category? we have to file export notices prior to publishing each binary package that includes mod_ssl and the notice must include a URL to the 100% open source version of that package; and we can only distribute binary versions of openssl if we can point to the 100% open source package from which it was built *and* file an export notice for that package prior to our publication; seem in once sense to be the same issue. Package mod_ssl + OpenSSL 0.9.7i and does this become one notification or two seperate notifications? When/If OpenSSL 0.9.8 is distributed 'by us', it's crypto capabilites are changed (notably ECC) so renotification is absolutely required. Less clear when we go from 0.9.7i to 0.9.7j (it happened to be a buildfix release) what is required. But if I understood Cliff's research and even our earliest legal advise, it's not the 'binaries' we notify BIX of, it's actually the source, so it wouldn't seem that once we have notified them of the source code to our packages, that any renotification would be needed for individual binaries. Are we 100% certain the 'hooks' for plugging in mod_ssl themselves are now totally and completely clear of all this garbage? That was once a concern back in the 90's, and I'm almost certain it's technically irrelevant now. c) each redistributor (re-exporter) of our packages must do the same Yes, that's always been true. If they sell it, notification may not be enough, they become a 'commercial exporter'. But that's their problem to follow the laws, not ours, and that's the answer we provide to all folks asking for our internal lists for clarification. Our terms with the BIX don't map 1:1 to their terms and they need to handle their export independently of the ASF. Another marvelous justification for moving mod_ssl from /repos/asf/httpd/httpd/ over to /repos/asf/httpd/mod_ssl/ with a big fat NOTICE.txt sitting there that it contains crypto. If someone wants to redistribute without hassle, there's a tarball with no encumberances to set up http:. Bill
Re: restructuring mod_ssl as an overlay
Colm MacCarthaigh wrote: I think the best way to accomplish that is to separate mod_ssl into a subproject that is capable of producing overlay releases for each release of httpd. yuck! -1 Before we take -any- action, we need to have one policy across the ASF. Our research hopefully contributes substantially to that policy. But we can't enable per-project balkanization when it comes to complying with US law. As I've said, I'm ok with two seperate (full) tarballs, e.g. two (full) corresponding binary distributions; I'm ok with a core tarball and an add-on crypto component. I'm not really ok with the status quo as there is no way to not download crypto in a restricted jurisdiction if one wants httpd, unless some party has retarred the release for us sans mod_ssl. There's another gray point, without OpenSSL, mod_ssl is a noop, that is, it does no crypto. There is more crypto in mod_auth_digest, util_md5 or in apr-util than there is in mod_ssl. Is the mere legal registration of the ASF within US borders a solid stumbling block here? As in, could the situation be remedied by forbiding US-based distributors? (Similar to what Debian used to do with it's non-US repositories). Dude, we are a Deleware, US foundation.
Re: restructuring mod_ssl as an overlay
On Jun 7, 2006, at 1:30 PM, Colm MacCarthaigh wrote: e) people who are in the banned set of countries and people in countries that forbid encryption cannot legally download the current httpd-2 packages because they include mod_ssl even when it won't be used. I don't see how this can possibly be the case. If crypto code is illegal locally, then it is illegal locally and people need to figure that out from themselves. The point is that they may want to download a web server which doesn't have that problem, and right now they are limited to 1.3.x. I consider Web servers to be something we would want people in those countries to be able to download without concern. Freedom of the press. If a person happens to live in a country which is on the USA's banned list, there's nothing illegal (purely from their perspective) about their act of download, US law does not apply to them. Right, but it does apply to us (and to Ireland as well, AFAIK) if we encourage people in those countries to download the web server but do not also provide a non-crypto alternative. Surely the illegality is that the ASF exports the code to those countries, and if anyone is answerable to those particular laws it is any US-based exporter of the code. I just want to be clear about this distinction, if it's correct. Mostly. The banned countries are also banned by the EU (the anti-terrorism laws), so it isn't as simple as you might think. And pointing out the fact that this is all just a stupid waste of time doesn't work either, apparently, as the current government is technologically illiterate. Or is there a suggestion that the situation invalidates the user's license? (contracts can be invalidated when a law is broken, but it's complex stuff). No, it is strictly an advertising problem placed on the ASF. I think the best way to accomplish that is to separate mod_ssl into a subproject that is capable of producing overlay releases for each release of httpd. yuck! -1 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. 2) split the distribution into plain and crypto parts and only have to deal with the export controls within the crypto distribution. 3) delete mod_ssl from httpd Pick one. Thoughts? Anyone have any better ideas? Is the mere legal registration of the ASF within US borders a solid stumbling block here? As in, could the situation be remedied by forbiding US-based distributors? (Similar to what Debian used to do with it's non-US repositories). The ASF is within US borders and is a US corp. And, no, whatever it was that Debian was trying to do is not even remotely sufficient for the US because it just makes each developer the exporter. Roy
Re: restructuring mod_ssl as an overlay
On Wed, Jun 07, 2006 at 03:53:51PM -0500, William A. Rowe, Jr. wrote: Before we take -any- action, we need to have one policy across the ASF. *shrug*, this is [EMAIL PROTECTED], so I'm going to stick to httpd specifically for now, and that can feed in or not to any policy the ASF desires to later impose :-) Our research hopefully contributes substantially to that policy. But we can't enable per-project balkanization when it comes to complying with US law. Sure, but I don't have the legal advice, and I'm trying to ask some targetted questions to see what other options there are. I've been studying law, for my sins ;-) Anyway, I'm not taking responsibility for monitoring any paralell discussions elsewhere within the ASF and trying to ensure coherency. As I've said, I'm ok with two seperate (full) tarballs, e.g. two (full) corresponding binary distributions; I'm ok with a core tarball and an add-on crypto component. I'm not really ok with the status quo as there is no way to not download crypto in a restricted jurisdiction if one wants httpd, unless some party has retarred the release for us sans mod_ssl. I'm fine with that too, it's a sensible pragmatic thing which makes life easier for a lot of people. Re-organising our subversion tree and development practices seems a bit extreme though, I mean do we also split out mod_auth_digest? Where do we stop? I don't want to have to RM, test or vote on two or three tarballs every time we make what is really one release because of some dumb laws. Is the mere legal registration of the ASF within US borders a solid stumbling block here? As in, could the situation be remedied by forbiding US-based distributors? (Similar to what Debian used to do with it's non-US repositories). Dude, we are a Deleware, US foundation. Sure, I realise that, and SPI is a New York, US foundation, but Debian managed to distribute non-US for years. But I'm not privy to their legal advice either. So, I'm wondering how effective a liability shield it is for a US-based corporation to export such content via non-US-based distributors. It seems odd that this would work legally, but that SPI/Debian did it for so long sparks my interest; maybe there is a path through. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
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. Acutally - I'm still looking for citations (?) of how binaries are treated in this day and age if they compile the same code as source. That said, redistributing ssl binaries fits if we deny everyone in banned countries or those with jurisdictional issues the right to obtain httpd. Bleh - of course the status quo is a nonstarter. From a maintenance perspective, perhaps modifying the roll-release script to strip modules/ssl/ from a 'no-ssl' flavored tarball would be enough? Bill
Re: restructuring mod_ssl as an overlay
On Wed, Jun 07, 2006 at 02:03:33PM -0700, Roy T. Fielding wrote: The point is that they may want to download a web server which doesn't have that problem, and right now they are limited to 1.3.x. I consider Web servers to be something we would want people in those countries to be able to download without concern. Freedom of the press. I'm in favour of everyone being able to download httpd :-) If a person happens to live in a country which is on the USA's banned list, there's nothing illegal (purely from their perspective) about their act of download, US law does not apply to them. Right, but it does apply to us (and to Ireland as well, AFAIK) if we encourage people in those countries to download the web server but do not also provide a non-crypto alternative. Surely the illegality is that the ASF exports the code to those countries, and if anyone is answerable to those particular laws it is any US-based exporter of the code. I just want to be clear about this distinction, if it's correct. Mostly. The banned countries are also banned by the EU (the anti-terrorism laws), so it isn't as simple as you might think. It's not nearly so simple as that either. There's a complicated intersection of national laws, the Wassenaar Arrangement and local interprettation. Here in Ireland, we are extremely liberal on crypto export due to lobbying by the local software and crypto industry. Indeed, it's even a selling point at attracting some multinationals here. Afaik, very few - if any - countries share the US list of designated countries, Cuba being a near-universal counter-example. But that hardly matters anyway :-) 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. 2) split the distribution into plain and crypto parts and only have to deal with the export controls within the crypto distribution. 3) delete mod_ssl from httpd Pick one. I'm fine with number 2. But I'd prefer if we achieved it via modifying release.sh/roll.sh rather than creating a subproject or two and all of the overhead that entails. The ASF is within US borders and is a US corp. And, no, whatever it was that Debian was trying to do is not even remotely sufficient for the US because it just makes each developer the exporter. Hmm, are they really that crazy? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
On 06/07/2006 10:53 PM, William A. Rowe, Jr. wrote: There's another gray point, without OpenSSL, mod_ssl is a noop, that is, it does no crypto. There is more crypto in mod_auth_digest, util_md5 or in apr-util than there is in mod_ssl. I think this is an excellent point regarding the source. Without an SSL toolkit like openssl mod_ssl does nothing. It is no crypto software. Otherwise you could argue that httpd without mod_ssl is also crypto software, because you can use mod_ssl with httpd. So separating it into a subproject would not help either. So provided mod_auth_digest, util_md5 or apr-util do not impose further problems, we would only have problems of offering binary packages (which I understand we want to offer). Apart from any inconvience for the user, but only from the legal point of view: Is a binary httpd with mod_ssl compiled in crypto software if it is delivered without openssl? A complete different question: Does anybody know how mozilla.org handles these kind of problems with firefox? Regards Rüdiger
Re: restructuring mod_ssl as an overlay
Ruediger Pluem wrote: A complete different question: Does anybody know how mozilla.org handles these kind of problems with firefox? They appear to have a brief overview of their trials and tribulations on the subject here: http://www.mozilla.org/crypto-faq.html
Re: restructuring mod_ssl as an overlay
On Wed, Jun 07, 2006 at 02:51:12PM -0700, Cliff Schmidt wrote: Here's the page that I've put together right now: http://apache.org/dev/crypto.html. Unfortunately, it needs a little more detail. Thank you very much, that's already answered a few of my questions and given me some good pointers. The US export laws do not require us to offer a non-crypto version of products we place on the web that do include export-controlled crypto. The only thing we cannot do is knowingly export to a handful of particular countries; however, placing an item on the web does not qualify as knowingly exporting to any particular country. That would be excellent. However, if there are httpd users in countries that have *import* restrictions that would like to use the non-ssl version of httpd, that might be a reason to do what is being suggested here. But there is no U.S. regulation that I am aware of that requires us to distribute a non-SSL versionbut maybe I'm not understanding the concern. From the sound of things, we could put up ssl-capable downloads right now with no liability for the ASF or anyone other than users in countries with such restrictions, which is useful to know. So, I'm wondering how effective a liability shield it is for a US-based corporation to export such content via non-US-based distributors. It seems odd that this would work legally, but that SPI/Debian did it for so long sparks my interest; maybe there is a path through. I have no idea what the Debian story is, but that is not an option for a number of reasons. Here's the biggest reason, the same U.S. government entity that controls our exports also controls reexport from any other country of goods that were previously exported from the U.S. I've been reading http://www.debian.org/legal/cryptoinmain and it looks like they shifted the liability to their developers personally, who exported-by-proxy. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
So, I'm wondering how effective a liability shield it is for a US-based corporation to export such content via non-US-based distributors. It seems odd that this would work legally, but that SPI/Debian did it for so long sparks my interest; maybe there is a path through. I have no idea what the Debian story is, but that is not an option for a number of reasons. Here's the biggest reason, the same U.S. government entity that controls our exports also controls reexport from any other country of goods that were previously exported from the U.S. I've been reading http://www.debian.org/legal/cryptoinmain and it looks like they shifted the liability to their developers personally, who exported-by-proxy. And this is why an unexported httpd win32 binary has sat in my home on our US server, undistributed, for about four years ;-) At the ASF this is not an acceptable conclusion; the ASF exists to help developers innovate, and that includes making some legal assessments, issuing policy and then standing behind that policy. Bill
Re: restructuring mod_ssl as an overlay
On Jun 7, 2006, at 1:39 PM, William A. Rowe, Jr. wrote: On the T-8 prohibited countries list, note it is a crime to export technologies to them (it's hard for the US to define a crime to obtain said technologies in a foreign jurisdiction - let's not get into that debate). However, as a 'public download' I believe we are now exempted from trying to discern where these parties are. Providing both the base server and an ssl feature demonstrates good faith that we are providing unrestricted access to our httpd sources, and permitting our users to avoid mod_ssl/crypto. Exactly. It avoids us getting into trouble for asking people to download httpd without specific reference to the export controls. Note that Cliff only looked at what was needed for crypto -- he didn't look at the general issue of producing controlled versus uncontrolled (for export purposes) software. On very important points; we have to file export notices prior to each release in which the crypto capabilities are changed; This means the strength of the crypto or feature set. Right. Does apr's sha1 and m5 hashing still fall into this category? No, one-way hashing and crypto technologies used for the sole purpose of authentication (not data privacy) are specifically excluded. we have to file export notices prior to publishing each binary package that includes mod_ssl and the notice must include a URL to the 100% open source version of that package; and we can only distribute binary versions of openssl if we can point to the 100% open source package from which it was built *and* file an export notice for that package prior to our publication; seem in once sense to be the same issue. Package mod_ssl + OpenSSL 0.9.7i and does this become one notification or two seperate notifications? When/If OpenSSL 0.9.8 is distributed 'by us', it's crypto capabilites are changed (notably ECC) so renotification is absolutely required. Less clear when we go from 0.9.7i to 0.9.7j (it happened to be a buildfix release) what is required. It is impossible for us to distribute OpenSSL without also providing a URL to the exact 100% open source distribution from which it was built. As you note, we can't do that by pointing to openssl.org, so we would have to provide our own copy of the distribution or include the source code directly in our product, just to comply with EAR. My preference is to not distribute OpenSSL. But if I understood Cliff's research and even our earliest legal advise, it's not the 'binaries' we notify BIX of, it's actually the source, so it wouldn't seem that once we have notified them of the source code to our packages, that any renotification would be needed for individual binaries. Notification is for products. We must have one notification per product that includes export-controlled code and 100% of the source code for that product must be available from a single URL. The notification is made each time the URL changes or the crypto capability changes. Note that the single URL may contain a list of package versions and docs on how to build each such version from a list of source packages. If we have five different products that use mod_ssl or openssl (e.g., httpd, tomcat, ftpd, flood, fubar) then we need five different notifications and each must be distributed as 100% open source to qualify for the TSU exception. This also explains why we don't have to provide a notice for everything in our subversion repository. Are we 100% certain the 'hooks' for plugging in mod_ssl themselves are now totally and completely clear of all this garbage? That was once a concern back in the 90's, and I'm almost certain it's technically irrelevant now. The module hooks are not a concern. The calls within mod_ssl itself are sufficient to be controlled, as Cliff said: The 5D002 ECCN includes software specially designed to use other technology controlled by 5D002. That would imply that mod_ssl is also subject to export regulation and is allowed the TSU exception. Here are some other links worth looking at http://www.apache.org/dev/crypto.html http://www.access.gpo.gov/bis/ear/ear_data.html http://www.hecker.org/mozilla/eccn http://www.adobe.com/support/exportcompliance.html http://www.adobe.com/support/eccnmatrix.html Note that most of Adobe's products are classified as 5D992, which is either because they requested a specific review and the result was NLR (no license required) or possibly because of the regulation of c. Software designed or modified to protect against malicious computer damage, e.g., viruses. and I don't need to speculate as to why such software is not allowed to be exported to the T-8 countries. One weird thing about the ECCNs is that there is no classification number for not controlled. *shrug* Roy
Re: restructuring mod_ssl as an overlay
On Wed, Jun 07, 2006 at 04:02:01PM -0700, Roy T. Fielding wrote: we would have to provide our own copy of the distribution or include the source code directly in our product, just to comply with EAR. My preference is to not distribute OpenSSL. +1 -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
On Jun 7, 2006, at 3:02 PM, Colm MacCarthaigh wrote: On Wed, Jun 07, 2006 at 02:51:12PM -0700, Cliff Schmidt wrote: Here's the page that I've put together right now: http://apache.org/dev/crypto.html. Unfortunately, it needs a little more detail. Thank you very much, that's already answered a few of my questions and given me some good pointers. The US export laws do not require us to offer a non-crypto version of products we place on the web that do include export-controlled crypto. The only thing we cannot do is knowingly export to a handful of particular countries; however, placing an item on the web does not qualify as knowingly exporting to any particular country. That would be excellent. We also cannot go to one of those countries and agitate for people to download a copy of httpd and run their own web server, though I imagine Brian, Dirk, and Sally are the only ones likely to travel that far. More to the point, I'd prefer not to have all the warnings scrawled across the top of our downloads page. However, if there are httpd users in countries that have *import* restrictions that would like to use the non-ssl version of httpd, that might be a reason to do what is being suggested here. But there is no U.S. regulation that I am aware of that requires us to distribute a non-SSL versionbut maybe I'm not understanding the concern. From the sound of things, we could put up ssl-capable downloads right now with no liability for the ASF or anyone other than users in countries with such restrictions, which is useful to know. If and only if we FIRST notify BIS and SECOND place text similar to what Adobe has on the download page, and that assumes we either do not include openssl or we distribute the source code for that as well. So, I'm wondering how effective a liability shield it is for a US- based corporation to export such content via non-US-based distributors. It seems odd that this would work legally, but that SPI/Debian did it for so long sparks my interest; maybe there is a path through. I have no idea what the Debian story is, but that is not an option for a number of reasons. Here's the biggest reason, the same U.S. government entity that controls our exports also controls reexport from any other country of goods that were previously exported from the U.S. I've been reading http://www.debian.org/legal/cryptoinmain and it looks like they shifted the liability to their developers personally, who exported-by-proxy. Yep. However, Debian has no real problem because they do have a URL to associate with the source code of whatever they distribute. The problem for us is because we don't distribute OpenSSL as it would be built for mod_ssl *and* we wouldn't be controlled at all if it were not for that single module. That is why our dilemma is actually worse than Mozilla (which requires SSL and binds it statically). Roy
Re: restructuring mod_ssl as an overlay
On Wed, Jun 07, 2006 at 04:32:40PM -0700, Roy T. Fielding wrote: We also cannot go to one of those countries and agitate for people to download a copy of httpd and run their own web server Who's we? Members of the ASF? Members of the PMC? committers? developers? I'd like to know. My Apache Mirrored Worldwide t-shirt is quite nice for Cuban weather :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: restructuring mod_ssl as an overlay
On Jun 7, 2006, at 4:53 PM, Colm MacCarthaigh wrote: On Wed, Jun 07, 2006 at 04:32:40PM -0700, Roy T. Fielding wrote: We also cannot go to one of those countries and agitate for people to download a copy of httpd and run their own web server Who's we? Members of the ASF? Members of the PMC? committers? developers? We is anyone representing the ASF. How (or who) would determine that is anyone's guess. More links http://www.exportcontrolblog.com/ http://www.stanford.edu/dept/DoR/exp_controls/index.html http://www.bis.doc.gov/deemedexports/deemedexportsfaqs.html#17 The EAR guidelines are insanely complicated because they are basically a summary of various laws and executive directives. It is FUBAR, but violating them can be subject to civil and criminal penalties in the US. I think that's why most of the companies stay conservative and simply ban all export to anyone on the lists. Roy
Re: restructuring mod_ssl as an overlay
On Wed, Jun 07, 2006 at 06:58:27PM -0700, Roy T. Fielding wrote: We is anyone representing the ASF. How (or who) would determine that is anyone's guess. eek. Who is burdened with that liability? I'm guessing it's the ASF as a body corporate and possibly its directors personally. If that's the case, then the Foundation needs to decide if it's comfortable with a legal release policy that depends on the continued voluntary non-promotion of our software by ASF members and (probably) PMCs within those countries intersected with the goodwill of whoever makes the determination we're talking about. As the ASF lacks, afaik, a method of keeping anyone in-line, so to speak, that would seem dubious at best and completely untennable at worst. The vagueness of the regulation, and I'm guessing an absense of case-law, means that ultimately it's a complex judgement call as to what level of risk people are willing to accept, and to me it looks like it's up to the foundation to come back to us and tell us whether or not they are comfortable with that. From the httpd point of view, it does seem a potentially very unstable policy requirement, but probably workable in the real world. Still, it gets murky around the edges, like should we stop letting linuxiran.org know when we make releases? There are all sorts of ways in which this policy could never be anything close to watertight. One thing which is important though is that I'd hope that if we ever had developers based in any of those countries, that we'd encourage their involvement regardless - which could be extremely awkward within such a policy. This isn't so unlikely as it may seem, iirc it came very close to at least one PMC member's nation being on the list a while back. Thanks for the links, good reading! -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
