On Mon, 2002-02-25 at 10:50, David Bryson wrote:
> Ok, so a few questions so clear a few things up for me. Again, i'm a
> newbie so go easy on me, but flames are appriciated it absolutly
> necessary ;-)
...why should I flame? ;)
=20
> My understanding of how the API works is:
> block write request-> filesystem
> write(ext2/3/reiserfs/whatever)->loopback(crypto)->block written.
=20
> The whole loopback thing seems a little odd to me, why is it necessary
> that we go through the loopback device ? Couldn't we interrupt the
> system call for block writing and encrypt the contents there, maybe on
> the VFS layer ?=20
if you do it in the vfs layer, you will only encrypt the data (file
contents), but not the meta-data (i.e. filenames, dirstructure and so
on)
by using the loopback device, the filesystem does not need to be adapted
anyway, as it just sees the usual block device abstraction on which to
operate...
> My current understanding of the whole CryptoAPI is that
> the loopback device limits us in some sense, so I'm trying to figure out
> if there is a way we can accomplish the same task without it. Is this
> futile ?
the loopback device is just an application of the cryptoapi, it's not
its main purpose ;)
=20
> Also... I know you guys are on the list but:
>=20
> Cryptoapi people seem to be very reluctant to fixing bugs, even if said
> bugs are pointed out to maintainer.
well the only 'cryptoapi people' you can be referring to is me... ;)
=20
> we should really try to change that. hvr do you have a list of bugs
> that have been reported to you lying around in some old emails ?
I'll put something together, although there were not many real bugs
reported (most of the problems are failed kernel compiles or failing to
load a module, or something similiar...)
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
|
