In article <20000531224530.A10394@frodo.rrze.uni-erlangen.de> you wrote:
> There is no point compromising the security of the majority of Linux
> users just because some countries have stupid laws. People in such
> countries will have do do one extra step if they care to stay legal.
> Thus the main kernel should contain cryptography.
I support this option because currently cryptographic code suffers from
being distributed as separate patches.
The main problem is keeping the kerneli patch up to date, when there's
no maintainer (or there is any?). Kernel versions change, the kernel
internals change and nobody updates the keineli patch respectively.
Patch is OK, when you really want to do a ,,patch'' - a fix or some
*small* feature update. Distributing a whole API or code deeply involved
with the IP stack (Free S/WAN) as a patch causes a lots of problems with
mutual incompatibility, fuzzy patching etc. This becomes a real problem
when you want to use loop encryption, IPSEC, ReiserFS and other features
in one single kernel.
As for the export or import restrictions it was mentioned several
times that the main problem -- US export restrictions -- were already
Take a look at what BSD people have done and when -- FreeBSD 4.0-RELEASE
and NetBSD-current both have crypto included (OpenBSD never cared
;). Both have added the crypto code, which was distributed separately
from Europe till now, just after the restrictions were relaxed and the
rules of export confirmed and explained in details.
People who really suffer from govermental import restrictions can still
download a source without crypto, because this code has separate tag
in CVS. Actually, it would be much easier if Linux kernel used CVS for
distribution, but it still can be done.
-- Paweł Krawczyk <http://ceti.pl/~kravietz/>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:13 EST