Re: The future of disk encryption with LUKS2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Arno,

While there is truth in what you say, the same holds true looking at it from the other side: If you get everything 'just done', you will endup with a quilt that is far from being useable and stable and which will fail more often than it works. (And possibly gets you killed too).

So yes, compromises are needed.

Then again, we all know more than enough examples where cuts in complexity/security ended in desaster, even though all features 'really needed' were in place.

Regards

-Sven


Am 10.02.2016 um 17:22 schrieb Arno Wagner:
On Wed, Feb 10, 2016 at 16:39:03 CET, Milan Broz wrote:

On 02/10/2016 04:09 PM, Sven Eschenberg wrote:
[...]
So either the layering order is fixed and determined, or you actually
will need intra-layer relationships for proper operation. As an
alternative, leave it to the user's knowledge and handling. But then we
don't need partition tables, LUKS-headers or anything else either,
afterall you can tell each layer the geometry and parameters manually
and use dmsetup for all your tasks.

It is not just black and white.
(Could we avoid these logical fallacies here please?)

Milan

I very much agree. Reality is that sometimes exceptions need to
be made and sometimes you need to deviate from "clean" design
to get good design. The trick is to keep the right balance
and to keep the overall goal firmly in mind and keep the exceptions
and added features down to those really needed, otherwise the
increased complexity kills you (see also "The second system
effect" by Brooks).

Systems were everything is designed "correctly" and "clean" have
a tendency to a) never get finished and b) not work very well.
Reality requires compromises. The trick is to make it good
compromises.

Regards,
Arno

_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt



[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux