lkml.org 
[lkml]   [2005]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: reiser4 plugins
Date
From
David Masover <ninja@slaphack.com> wrote:
> Kyle Moffett wrote:
> > On Jun 26, 2005, at 22:37:48, David Masover wrote:

[...]

> That just means the zip plugin has to be more carefully written than I
> thought. It would have to be sandboxed and limited to prevent buffer
> overruns and zip bombs.

[...]

> Remember that zip, at least, would not be in the kernel. I think what
> is going in the kernel is gzip and lzo, and it's being done so
> transparently that you never actually see the compressed version.

Doesn't matter if it is zip of some other compression, the problem is
exactly the same.

> > Can you illustrate for me with precise, clear, and unambiguous arguments

> That will take some time. And some thinking.

See? Exactly what has been demanded by all the "unfair", "ReiserFS-racist",
"shove-any-junk-but-do-not-accept-perfect-filesystems-into-the-kernel" etc
people here on LKML from the very start.

> > how this can avoid all possible pitfalls,

> Especially if you want perfection.

Perfection would be nice, but (IMHO) not required.

[...]

> Now, the cryptocompress as it currently stands does not involve ... and
> does not introduce any new security holes in the way that you are
> describing. There might be some issues with key management (someone
> hinted vaguely at that), but nothing insurmountable.

OK, I see a week of flamefest going by until you admit it has the same
problemas as compression (Hint: Most encryption compresses first, in order
to give would-be cryptoanalysts less of a toehold via non-uniform
distributions, and having less work to do), and then a whole lot of its
/own/ problems (that somebody can peek at a cached uncompressed copy of my
files is not so bad, if they can peek at my decrypted files I'd be rather
less pleased... and here you have to include a malicious root (Yes, I'm
paranoid. Doesn't mean root is not out to get me.).). Perhaps this can't be
all solved, but the exact boundaries of what /is/ provided, and what
/isn't/ must be made clear.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-06-27 08:08    [W:0.351 / U:0.984 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site