I am beginning to sigh myself...
On Fri, 21 Apr 2006, Henne Vogelsang wrote:
> Ive never stated that cryptoloop is better than dm-crypt. I stated that
> dm-crypt is not the best working solution that exists.
It is better than cryptoloop, that is for sure and suffices within the
domain of this discussion.
> Again *sigh* :) we are not talking about today. We are talking about the
> future. We cant manoeuvre ourself in a position where providing an
> upgrade path is impossible (its getting more and more likely with each
> implementation change).
Come on. Don't only sigh. Try not to contradict yourself. If you plan to
be future-oriented, it is complete nonsense to NOW switch to cryptoloop in
SLES, instead of e.g. switch to dm-crypt in SUSE 10.1 and let SLES 10 be
the same as SLES 9 with regard to encrypted volumes.
Your argument is perverse: Switching to cryptoloop may manoeuvre yourself
in a position where providing an upgrade path is impossible, not switching
to dm-crypt.
Let us talk about it: What is the issue about upgrade paths? It is not
about startup scripts, it is about the ondisk layout of the encrypted
volumes. That's the issue. With cryptoloop-compatible solutions, a change
of encryption types or layout means copying away all the data, recreating
a new volume, and then copying all the data back. This is painsome to the
clients.
dm-crypt offers you compatibility and therefore it is at first unnecessary
to provide the above-sketched upgrade paths. On the other hand, it has
a cleaner code and allows you to also encrypt swap
space.
What else do you want?
> The only thing that happend in dm-crypt.c since 2003 is the
> implementation of essiv. Nothing else.
>
Sorry, now it is beginning to really become ridiculous: using dm-crypt
allows you e.g. to safely encrypt swap partitions, due to the use of
memory pools. The implementation of ESSIV alone would be reason to switch
to dm-crypt. You get a plethora of advantages and retain compatibility.
What is your scepticism about?
> Ok the maybe you dont understand what i mean by upgrade path's fully.
> Upgrade paths are not only about getting someone from the "past" to the
> "now" but also getting from the "now" _and_ the "past" to the "future".
> Is that more clear?
It is clear. So, in your opinion switching to cryptoloop in SLES _now_
(yes, I have learnt now that SUSE 9.2 already had it too) is
preparing you (and your enterprise clients) for the future?
>
> > Then you are halfway to a future solution which is completely based on
> > LUKS or any other format with a secure IV generation mode, i.e. half way
> > into the right direction.
>
> If dm-crypt will be the solution of the future yes. We are very unsure
> about that. If it is not this move a full way into "some" direction.
> This means we not only have to provide an upgrade path from 3 different
> implementation but from 5 different implementations (and 3*5 previous
> upgrade scenarios).
>
Surely nobody knows what will be the ultimate solution in 10 years.This is
irrelevant because a software solution mostly is a solution for about 3-5
years then something else comes. This has always been the case and will
continue to be so.
At present, however, every other distro (name one relevant which
isn't) is using dm-crypt and most of them
are trying to integrate even LUKS. Do you think is is for no good reason?
So, what kind of development in the market of volume encryption are you
waiting for? A final solution will never exist.
> > But cryptoloop is full-way into the wrong direction.
>
> Its not. Its a full stop (which we pulled with 9.2 after we analysed the
> state of the cryptofs implementations back then).
>
No, sorry. It is reverse gear, full speed. And certainly it is not
future-directed as you wish.
You will be proved when SLES 10
is going to be reviewed by the community and the press and prone to
ridicule if that item in the release notes will be read.
Best regards
Oliver
__
________________________________________creating IT solutions
Dr. Oliver Tennert
Senior Solutions Engineer
CAx Professional Services
science + computing ag
phone +49(0)7071 9457-598 Hagellocher Weg 71-75
fax +49(0)7071 9457-411 D-72070 Tuebingen, Germany
[EMAIL PROTECTED] www.science-computing.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
