Thread: [CryptoAPI-devel] testing...

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

one two three.

  - k

-- 
copyleft (c) 2002, Kyle McMartin

On Sun, 2002-02-24 at 19:22, Kyle McMartin wrote:
> one two three.
works!

well, I'll take the opportunity write about the current status;

...we are quite alone here, just 3 of us in the mailing list so far...
hope we become more over time :)

ok, so we have=20

1. a 'cryptoapi-2.4.7' tarball which is a bit out of date at
sourceforge.net
2. a CVS repository containing the latest cryptoapi code at sourceforge
3. the old kernel patches up to 2.4.3 at kernel.org (by alex)
4. the 'testing' patches up to 2.4.17 at kernel.org (by me), containing
code from the cryptoapi-branch...

some unresolved problem which kept me from releasing this beast finally
are:

1. how to automate the task of creating a kernel patch from the
cryptoapi-CVS? or maybe just do it like the frees/wan people do?
2. how to handle jari's and my loop-IV fix approach in a compatible way.
3. documentation update
4. some stuff I forgot... :-/

..if something is unclear (and I'm sure there is :-), please don't
hesitate to ask! :-)

regards,
--=20
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: hv...@hv...       /    Finger hv...@gn... for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F
4142

(sorry forgot to send this to the mailing list)

On Mon, Feb 25, 2002 at 01:02:11AM +0100, Herbert Valerio Riedel wrote:
> 1. how to automate the task of creating a kernel patch from the
> cryptoapi-CVS? or maybe just do it like the frees/wan people do?
> 2. how to handle jari's and my loop-IV fix approach in a compatible way.
> 3. documentation update
> 4. some stuff I forgot... :-/
> 

This one should be easy, do all development in a HEAD branch, and when a
new kernel is released, create a branch for it, and stabilize the
branch, while all main work continues on HEAD.

Only problem with this approach is releases for old kernels stagnates,
so sticking to the stable tree, where people are nearly guaranteed to
upgrade, is okay.

I'll suck down the cvs tree in a few minutes. Seeing how long it is
taking for 2.4.18, I think shooting for a stable version for it would be
a good idea, since at this rate it will be current for ages.

I suppose coordination with the FreeS/WAN people would be a good idea,
especially if they began using the CryptoAPI ciphers.

I'll being by looking into the documentation, that should be a good way
of getting my feet wet.

regards,
	kyle
-- 
copyleft (c) 2002, Kyle McMartin

On Mon, 2002-02-25 at 02:53, Kyle McMartin wrote:
> (sorry forgot to send this to the mailing list)
np :-)
=20
> > 1. how to automate the task of creating a kernel patch from the
> > cryptoapi-CVS? or maybe just do it like the frees/wan people do?

> This one should be easy, do all development in a HEAD branch, and when a
> new kernel is released, create a branch for it, and stabilize the
> branch, while all main work continues on HEAD.
well... the cryptoapi in it's current form should be version
independent! :-)

actually there's no sense for the tarball distro to carry a kernel
version number... only for the kernel patch distro...

the only annoying stuff that changes a bit is the top-level Makefile,
and some other minor bits in the build framework...
=20
> Only problem with this approach is releases for old kernels stagnates,
> so sticking to the stable tree, where people are nearly guaranteed to
> upgrade, is okay.
as said above, these scheme would apply, if the cryptoapi would mess
around with kernel internals which may change every version... but it's
quite self-contained.. it just adds source files; it doesn't modify
existing kernel source...
=20
> I'll suck down the cvs tree in a few minutes. Seeing how long it is
> taking for 2.4.18, I think shooting for a stable version for it would be
> a good idea, since at this rate it will be current for ages.
>=20
> I suppose coordination with the FreeS/WAN people would be a good idea,
> especially if they began using the CryptoAPI ciphers.
btw, so far the USAGI and a NFSv4 project is already using the
cryptoapi;
the frees/wan people are thinking about using it, but are a bit
disappointed about the current status...
=20
regards,
--=20
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: hv...@hv...       /    Finger hv...@gn... for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F
4142

So kyle and I breifly spoke about the IDEA algorithm being in the API.=20
Since it is still patented(until 2007 IIRC) we felt it shouldn't be in
there and should be available seperately as a patch.  Thoughts on this ?
I haven't had a chance to pour over the sources for a few hours, and get
to know them, but I plan to soon.  I'm also looking into how cfs was
designed for OpenBSD because it would be nice if linux could eloquently
support encrypted root/swap.
cheers,
dave

On Sun, 2002-02-24 at 17:02, Herbert Valerio Riedel wrote:
> On Sun, 2002-02-24 at 19:22, Kyle McMartin wrote:
> > one two three.
> works!
>=20
> well, I'll take the opportunity write about the current status;
>=20
> ...we are quite alone here, just 3 of us in the mailing list so far...
> hope we become more over time :)
>=20
> ok, so we have=20
>=20
> 1. a 'cryptoapi-2.4.7' tarball which is a bit out of date at
> sourceforge.net
> 2. a CVS repository containing the latest cryptoapi code at sourceforge
> 3. the old kernel patches up to 2.4.3 at kernel.org (by alex)
> 4. the 'testing' patches up to 2.4.17 at kernel.org (by me), containing
> code from the cryptoapi-branch...
>=20
> some unresolved problem which kept me from releasing this beast finally
> are:
>=20
> 1. how to automate the task of creating a kernel patch from the
> cryptoapi-CVS? or maybe just do it like the frees/wan people do?
> 2. how to handle jari's and my loop-IV fix approach in a compatible way.
> 3. documentation update
> 4. some stuff I forgot... :-/
>=20
> ..if something is unclear (and I'm sure there is :-), please don't
> hesitate to ask! :-)
>=20
> regards,
> --=20
> Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
> Email: hv...@hv...       /    Finger hv...@gn... for GnuPG Public Key
> GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F
> 4142

On Sun, 2002-02-24 at 20:06, David Bryson wrote:
> So kyle and I breifly spoke about the IDEA algorithm being in the API.=20
> Since it is still patented(until 2007 IIRC) we felt it shouldn't be in
> there and should be available seperately as a patch.  Thoughts on this ?
> I haven't had a chance to pour over the sources for a few hours, and get
> to know them, but I plan to soon.
oh yes, that's the other thing I forgot...
I want the distribution to be that modular, that one can build easily
distros without strong ciphers, and since ciphers are self-registering
witht the crypto-api, one can distribute the idea cipher as a
self-contained package...

and then again, there'd be the problem of how to create a patch out of
the standalone distro...

> I'm also looking into how cfs was
> designed for OpenBSD because it would be nice if linux could eloquently
> support encrypted root/swap.
well, encrypted root is possible with linux afaik;
encrypted swap in theory as well over loop, although a more direct
approach would be more elegant (there's some paper about encrypting VM
at the openbsd site)

--=20
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: hv...@hv...       /    Finger hv...@gn... for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F
4142

(i'll get used to this sooner or later... sourceforge appears to not
like setting the reply-to)

On Mon, Feb 25, 2002 at 10:46:23AM +0100, Herbert Valerio Riedel wrote:
> oh yes, that's the other thing I forgot...
> I want the distribution to be that modular, that one can build easily
> distros without strong ciphers, and since ciphers are self-registering
> witht the crypto-api, one can distribute the idea cipher as a
> self-contained package...
> 

Very good, this makes it much easier to get around patent and export
laws, although, I should be okay, I'm a Canadian ;)

> well, encrypted root is possible with linux afaik;
> encrypted swap in theory as well over loop, although a more direct
> approach would be more elegant (there's some paper about encrypting VM
> at the openbsd site)
> 

I've just looked at this, it looks feasible. The question, I guess, is
CryptoAPI going to get into implementing things, or leave that to the
kernel-patch-int. Actually, is kernel-patch-int even maintained or
developed these days? Or perhaps for 2.5 a full-fledged crypto kernel
patch with _everything_ integrated together.

Anyway, I pulled CVS down, and have been getting familiar with the
source. I should be ready to be productive in a couple more days.

regards,
        kyle
> -- 
> Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
> Email: hv...@hv...       /    Finger hv...@gn... for GnuPG Public Key
> GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F
> 4142

-- 
copyleft (c) 2002, Kyle McMartin

On Mon, Feb 25, 2002 at 10:54:19AM +0100, Herbert Valerio Riedel wrote:
> well... the cryptoapi in it's current form should be version
> independent! :-)
> 
Indeed, if this can be accomplished, it is indeed good.

> actually there's no sense for the tarball distro to carry a kernel
> version number... only for the kernel patch distro...
> 
> the only annoying stuff that changes a bit is the top-level Makefile,
> and some other minor bits in the build framework...
>
This will all stabilize... eventually, I guess it isn't really an issue
with judicious shell scripting.

> btw, so far the USAGI and a NFSv4 project is already using the
> cryptoapi;
> the frees/wan people are thinking about using it, but are a bit
> disappointed about the current status...
>  
FreeS/WAN also seems to be in the middle of a complete re-design, so
compounding their troubles might not go over well :>

regards,
	kyle
-- 
copyleft (c) 2002, Kyle McMartin

So do we want to stick to stablizing the 2.4.17 branch ? or is the
thought that we move with kernel releases ? I'm decompressing 2.4.17
currently on my new box(hurray!) which i will use for cryptoAPI devel
and i'm about to pull CVS so hopefully I can get up to speed with the
both of you soon.
Dave

On Mon, 2002-02-25 at 19:50, Kyle McMartin wrote:
> On Mon, Feb 25, 2002 at 10:54:19AM +0100, Herbert Valerio Riedel wrote:
> > well... the cryptoapi in it's current form should be version
> > independent! :-)
> >=20
> Indeed, if this can be accomplished, it is indeed good.
>=20
> > actually there's no sense for the tarball distro to carry a kernel
> > version number... only for the kernel patch distro...
> >=20
> > the only annoying stuff that changes a bit is the top-level Makefile,
> > and some other minor bits in the build framework...
> >
> This will all stabilize... eventually, I guess it isn't really an issue
> with judicious shell scripting.
>=20
> > btw, so far the USAGI and a NFSv4 project is already using the
> > cryptoapi;
> > the frees/wan people are thinking about using it, but are a bit
> > disappointed about the current status...
> > =20
> FreeS/WAN also seems to be in the middle of a complete re-design, so
> compounding their troubles might not go over well :>
>=20
> regards,
> 	kyle
> --=20
> copyleft (c) 2002, Kyle McMartin
>=20
> _______________________________________________
> CryptoAPI-devel mailing list
> Cry...@li...
> https://lists.sourceforge.net/lists/listinfo/cryptoapi-devel

On Tue, 2002-02-26 at 07:20, David Bryson wrote:
> So do we want to stick to stablizing the 2.4.17 branch ? or is the
> thought that we move with kernel releases ? I'm decompressing 2.4.17
> currently on my new box(hurray!) which i will use for cryptoAPI devel
> and i'm about to pull CVS so hopefully I can get up to speed with the
> both of you soon.

well, I'd suggest to jump directly to the 2.4.18 kernel version as
common grounds... (not that it would change anything... since as already
said, the code itself is version indepentent, it's just the
build-framework which needs little adjustments sometimes...

btw, I've created a new module named 'cryptoapi-new'

please check it out... you have to always use the toplevel Makefile...

regards,
--=20
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: hv...@hv...       /    Finger hv...@gn... for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F
4142