From: dpf-lkml@fountainbay.com
To: "Andrew Morton" <akpm@osdl.org>
Cc: "James Morris" <jmorris@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Delete cryptoloop
Date: Wed, 21 Jul 2004 21:26:49 -0700 (PDT) [thread overview]
Message-ID: <4411.24.6.231.172.1090470409.squirrel@24.6.231.172> (raw)
In-Reply-To: <20040721230044.20fdc5ec.akpm@osdl.org>
Hello James and Andrew,
Hopefully someone else will follow up, but I hope I'm somewhat convincing:
Andrew Morton said:
> James Morris <jmorris@redhat.com> wrote:
>>
>> This patch deletes cryptoloop,
>
> OK - if nobody complains convincingly we'll drop cryptoloop out of 2.6.9.
>
Cryptoloop is deprecated (since 2.6.4), but that doesn't mean it should be
deleted. As is the case with many deprecated APIs, they usually hang
around for a long time (until the next major rev) so that people have a
chance to transition their tools. Is no one else using cryptoloop? Are 5
minor revs really enough time (so far about 5 months)?
>> which is buggy, unmaintained, and
>> reportedly has mutliple security weaknesses.
>
> Doesn't dm-crypt have the same security weaknesses?
>
I don't doubt the superiority of dm-crypt. But most people using a
_deprecated_ feature would know that means "buggy, unmaintained" and with
possible weaknesses.
Perhaps a better way to communicate deprecation, instead of pulling the
rug out from under people by deleting so soon, is to inject warnings
during compilation, or even during use. Or, split off the new code into a
differently named module -- leaving a clean way to throw out the old
method.
>From the cryptoloop HOWTO website:
(http://www.tldp.org/HOWTO/Cryptoloop-HOWTO/cryptoloop-introduction.html)
"Dm-crypt is available in the main kernel since 2.6.4. Cryptoloop will
still be available in the main kernel for a long time, but dm-crypt will
be the method of choice for disk encryption in the future."
And then it goes on to say:
"It is still very new and there are no easy-to-use userspace tools
available yet. Dm-crypt is considered to be much cleaner code than
Cryptoloop, but there are some important differences. For example,
creating an ecrypted filesystem within a file will still require to go
through a loop device, but this support is still in development."
So it looks like dm-crypt is still up in the air on feature compatibility
with cryptoloop.
Deleting cryptoloop in 2.6.9 seems too soon -- even the cryptoloop HOWTO
maintainer (Ralph Hölzer) seems to expect it to hang around.
In February, lkml had essentially the same discussion.
(http://kerneltrap.org/node/view/2433)
Ditching cryptoloop completely in 2.7 after dm-crypt matures would be a
better idea.
Regards,
Dale Fountain
next prev parent reply other threads:[~2004-07-22 4:26 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-21 20:16 James Morris
2004-07-21 23:44 ` David S. Miller
2004-07-22 6:00 ` Andrew Morton
2004-07-22 3:30 ` James Morris
2004-07-22 7:43 ` Matthias Urlichs
2004-07-22 14:14 ` H. Peter Anvin
2004-07-22 14:58 ` Jack Lloyd
2004-07-28 20:24 ` David Wagner
2004-07-29 0:27 ` James Morris
2004-07-29 15:50 ` Christophe Saout
2004-07-29 21:15 ` David Wagner
2004-07-30 13:13 ` Christophe Saout
2004-07-31 0:44 ` David Wagner
2004-07-31 2:05 ` Matt Mackall
2004-07-31 17:29 ` Marc Ballarin
2004-08-02 22:54 ` David Wagner
2004-08-02 23:16 ` James Morris
2004-08-07 16:27 ` Jean-Luc Cooke
2004-07-22 4:26 ` dpf-lkml [this message]
2004-07-22 5:22 ` James Morris
2004-07-22 11:58 ` Paul Rolland
2004-07-22 20:40 ` Martin Schlemmer
2004-07-22 8:46 ` Andrew Morton
2004-07-22 6:13 ` Dale Fountain
2004-07-22 6:47 ` Tim Connors
2004-07-22 15:02 ` Petr Baudis
2004-07-22 11:36 ` Aiko Barz
2004-07-24 15:11 ` Andreas Jellinghaus
2004-07-24 15:53 ` gadgeteer
2004-07-29 16:12 ` Andries Brouwer
2004-07-29 17:23 ` James Morris
2004-07-29 19:48 ` Andries Brouwer
2004-07-22 22:13 ` Bill Davidsen
2004-07-24 12:41 ` Fruhwirth Clemens
2004-07-24 16:52 ` Andrew Morton
2004-07-24 14:08 ` Andreas Henriksson
2004-07-24 19:54 ` Paul Jackson
2004-07-27 20:02 ` Bill Davidsen
2004-07-25 11:42 ` Jari Ruusu
2004-07-25 13:24 ` Fruhwirth Clemens
2004-07-25 15:24 ` Marc Ballarin
2004-07-25 16:57 ` Andreas Jellinghaus
2004-07-25 17:25 ` Jari Ruusu
2004-07-25 18:02 ` Fruhwirth Clemens
2004-07-25 19:09 ` Lee Revell
2004-07-25 19:15 ` Fruhwirth Clemens
2004-07-25 19:44 ` Marc Ballarin
2004-07-25 20:58 ` Fruhwirth Clemens
2004-07-26 10:54 ` Jari Ruusu
2004-07-26 12:45 ` Fruhwirth Clemens
2004-07-26 18:11 ` Jari Ruusu
2004-07-26 22:59 ` Fruhwirth Clemens
2004-07-26 20:01 ` Matt Mackall
[not found] ` <fa.edslbgp.q763qd@ifi.uio.no>
2004-07-27 8:40 ` Junio C Hamano
2004-07-27 8:53 ` Matt Mackall
2004-07-27 10:10 ` Marc Ballarin
2004-07-26 22:04 ` Marc Ballarin
2004-07-27 19:56 ` Bill Davidsen
[not found] <2kMAw-rl-15@gated-at.bofh.it>
2004-07-22 19:44 ` Pascal Brisset
2004-07-23 10:59 Thomas Habets
[not found] <2kvT4-5AY-1@gated-at.bofh.it>
[not found] ` <2kC85-1AH-11@gated-at.bofh.it>
[not found] ` <2kDxa-2sB-1@gated-at.bofh.it>
[not found] ` <2kECW-3a0-7@gated-at.bofh.it>
2004-07-23 12:34 ` Walter Hofmann
2004-07-23 14:01 ` Kevin Corry
2004-07-23 18:20 ` Christophe Saout
2004-07-27 19:47 ` Bill Davidsen
2004-07-23 12:50 mattia
2004-07-26 7:13 Adam J. Richter
2004-07-30 8:43 Markku-Juhani O. Saarinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4411.24.6.231.172.1090470409.squirrel@24.6.231.172 \
--to=dpf-lkml@fountainbay.com \
--cc=akpm@osdl.org \
--cc=jmorris@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®