On Thu, Feb 28, 2002 at 05:23:12AM -0800, IT3 Stuart Blake Tener, USNR-R wrote:
> issues, the first being it is terribly difficult (at least it was for
> me), to try to use it on any kernel I choose. Loop-aes seems not to
> stick you with this issue, and that (to me) is a big gain.
You've got a big problem anyway. With the updated binutils you can't
even compile the old kernels; you have to downgrade it to build them.
btw Herbert, have you confirmed your patches against new kernels and
with the latest binutils? I've noticed some problems with new binutils
and patched new kernels, but I don't know which patch did it or whether
it was some feature I turned on particular to those kernels.
> The i-patch,
> will one day have a big advantage when it is inclusive to all kernels by
> default (if accepted by Linus one day), but prior to that, it is very
> hard to justify all the effort (for an individual) to keep it working
> with different kernels, too much trouble (if you ask me).
Any kernel patch will have to be modified to keep up with the changes
in the kernel because they are part of the kernel. Modules can "often"
get away with changing only on major releases when the API changes.
However modules do not provide a general service, only a particular
one. You are stuck with that problem unless you move the API into
the kernel proper, and once you do so you are back to chasing the
latest releases.
> Secondly, I must tell you I do not agree with this idea of
> "known bugs", if someone (or a corporation, like SuSE) knows there is a
> "known bug", or an imperfect implementation (i.e. with blowfish), they
> have a responsibility to fix it, and offer a transition path to correct
> it.
This is all volunteer time; people give their time for free and have to
fit this in with making a living and family and friends. And besides
that, every software system (from honest vendors at least) has indeed
kept lists of known bugs. They are usually fixed in future releases.
This was the case way back when I worked with mainframe OS's.
> Having a crypto API within Linux is not only a necessity in the
> future, but also downright in demand. Once this is done, and a standard
> for crypto is built into Linux, we will be on a different page.
It is due to American regulations that it did not happen. Things have
changed and the legal opinions seem to be drifting in the direction
of saying it is safe to include encryption code.
For example, Debian has just decided to fold many important crypto
apps into the main servers instead of isolating them in the nonUS ones.
> I to this day do not understand why Linux has not (at minimum)
> been designed to have standard crypto API calls in it, which in the
> kernel could be dummy calls, which only would work if someone
> independently compiled and loaded modules not otherwise part of the
> kernel, in order to keep the kernel in its current world-exportable
> mode, but allow for standardization of crypto calls.
Because the government was actively going after people who did this.
I could dig and give you at least three examples of programs with
hooks that got directly threatened. One of those was the original
university predecessor to Netscape. It had built in crypto hooks
in the code. They were forced to remove them.
--
------------------------------------------------------
Nuke bin Laden: Dale Amon, CEO/MD
improve the global Islandone Society
gene pool. www.islandone.org
------------------------------------------------------
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
