Hi Sander,
I have an issue with installing open-ssl on machines.
from their home page:

This software package uses strong cryptography, so even if it is created, 
maintained and distributed from liberal countries in Europe (where it is legal 
to do this), it falls under certain export/import and/or use restrictions in 
some other parts of the world. 

PLEASE REMEMBER THAT EXPORT/IMPORT AND/OR USE OF STRONG CRYPTOGRAPHY SOFTWARE, 
PROVIDING CRYPTOGRAPHY HOOKS OR EVEN JUST COMMUNICATING TECHNICAL DETAILS ABOUT 
CRYPTOGRAPHY SOFTWARE IS ILLEGAL IN SOME PARTS OF THE WORLD. SO, WHEN YOU 
IMPORT THIS PACKAGE TO YOUR COUNTRY, RE-DISTRIBUTE IT FROM THERE OR EVEN JUST 
EMAIL TECHNICAL SUGGESTIONS OR EVEN SOURCE PATCHES TO THE AUTHOR OR OTHER 
PEOPLE YOU ARE STRONGLY ADVISED TO PAY CLOSE ATTENTION TO ANY EXPORT/IMPORT 
AND/OR USE LAWS WHICH APPLY TO YOU. THE AUTHORS OF OPENSSL ARE NOT LIABLE FOR 
ANY VIOLATIONS YOU MAKE HERE. SO BE CAREFUL, IT IS YOUR RESPONSIBILITY. 

what this means is that if I want to install a web server in china or india 
(where CNET have offices) we will need to get
a lawyer involved.


> -----Original Message-----
> From: Sander Striker [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 06, 2001 4:09 PM
> To: dev@apr.apache.org
> Subject: apr-util, crypto and openssl
> 
> 
> Hi all,
> 
> As if we weren't having enough discussion on this list
> I'll throw in something else...
> 
> Could we consider _removing_ all crypto related code
> from apr-util (and apr for that matter, since md5
> still lives there)? Reason for asking is that there
> already is an all purpose crypto library: openssl
> (like you didn't know that already...).
> 
> This will mean introducing a dependency on openssl
> for applications, (and until md5 is replaced by something
> that provides randomness, apr too).
> 
> If the apr style api is the reason for the code being
> in there I will understand, but I'd suggest a separate
> apr-crypto library (which effectively would be a thin
> wrapper of openssl).
> 
> Last reason for removing the code: it prevents requirements
> driven fools like me from sending in patches that duplicate
> other work :-) Ben assured me that openssl is extremely
> portable, so that can't be the issue.
> 
> Sander
> 
> PS. I do have a crc32 patch laying about (isn't in openssl
>     or apr(-util) and it is pretty generic. I think it has
>     some use in projects other than ours, but I'm not sure).
>     Interested?
> 
> 

Reply via email to