Hi, On Friday, April 21, 2006 at 17:07:01, Oliver Tennert wrote:
On Fri, 21 Apr 2006, Henne Vogelsang wrote:
I define standard to be the best working solution that exists.
Well, then define what "best solution" means. As the functionality in dm-crypt is enhanced plus the security problems are surely not greater than with cryptoloop, but most probably (to understate a bit) less, then dm-crypt is the better one, isn't it?
Ive never stated that cryptoloop is better than dm-crypt. I stated that dm-crypt is not the best working solution that exists.
The switch to cryptoloop in 9.2 was far from being trivial as i noted. The same happens if we migrate now to dm-crypt and what comes after dm-crypt? There are already other implementations "in the pipe" (CryptFS, NCryptFS, Reiserfs4 with crypto module, acrypto, etc.). As i pointed out this is something we have to seriously consider given the timeframes of an enterprise product.
how far is Reiser4 from being included in the vanilla kernel? How tested are all the solutions you mentioned? I estimate: none of them is even superficially, so they are no viable alternatives at the moment.
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).
The advantage you get however if you switch to dm-crypt is: actively maintained code plus additional features and enhanced security.
In reality dm-crypt is as maintained as cryptoloop
Is it? I just have a look at cryptoloop.c and see the latest changes are dated 2003.
The only thing that happend in dm-crypt.c since 2003 is the implementation of essiv. Nothing else.
Andrew Morton and some other people try again and again to get completely rid of the cryptoloop module, were it not for the arguments of many that for "compatibility reasons" it must stay. And I think this really means people simply do not want ro rewrite their startup scripts;)
I wont repeat again that its not only that i did so several times in the last mails even in this one...
Hm maybe we weren clear on this. The switch already happend with SUSE Linux 9.2 (and afair also in some SLES9 service pack). It is not happening now. Its mentioned in the release notes of SLES10 because thats the first SLES version since SLES9 that uses cryptoloop as default. Switching in CODE10 products (SL10, SLES10) would mean another switch.
I see, so I have misunderstood that. Nevertheless: the point is: you do not lose anything by dropping cryptoloop and using dm-crypt, even when retaining the old-fashioned plain IV mode. You just have to rewrite your startup scripts a bit, that's it. The compatibility is there, no non-trivial upgrade path is necessary.
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?
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).
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). Please keep in mind this does not mean that we will never change the cryptofs implementation again!!! It just means that while we made that switch it made more sense for us to wait than to switch to dm-crypt. Henne -- Henne Vogelsang, Core Services "Rules change. The Game remains the same." - Omar (The Wire)