From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mbroz@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by mail.saout.de (Postfix) with ESMTP
 for <dm-crypt@saout.de>; Tue, 15 Mar 2011 13:36:34 +0100 (CET)
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
 (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
 by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p2FCaX6w032250
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
 for <dm-crypt@saout.de>; Tue, 15 Mar 2011 08:36:34 -0400
Received: from [10.34.26.53] (tawny.brq.redhat.com [10.34.26.53])
 by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id
 p2FCaWPm018487
 for <dm-crypt@saout.de>; Tue, 15 Mar 2011 08:36:33 -0400
Message-ID: <4D7F5D50.9010302@redhat.com>
Date: Tue, 15 Mar 2011 13:36:32 +0100
From: Milan Broz <mbroz@redhat.com>
MIME-Version: 1.0
References: <4D7E53E5.3040007@redhat.com> <20110314221329.19d588ea@gmail.com>
 <4D7E925D.2010802@redhat.com> <20110315004559.091a1b53@gmail.com>
 <20110315010242.GB23585@tansi.org> <4D7F4973.9060509@redhat.com>
 <20110315120939.GA3660@tansi.org>
In-Reply-To: <20110315120939.GA3660@tansi.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.3.0-rc1 (test release
	candidate)
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

On 03/15/2011 01:09 PM, Arno Wagner wrote:

>> I will also limit LUKS keyfile in next version, mistake will cause problems
>> (reading the whole device in locked memory -> OOPS or something like that).
> 
> Indeed. What you could do is have it default to error instead of
> to cut-down and proceed. That would make more sense, since
> cutting it is almost always not going to work.

yup. This is common problem for all supported types, so I will probably
remove per-type limits, and add one maximal keyfile limit configurable
during compile time.

Exceeding this limit will cause fail.

Limiting keyfile read (if needed - like /dev/urandom or when stored
in the beginning of device) should be always possible using --keyfile-size
parameter (or --new-keyfile-size for new keyfile option).

(This commadline limit option should possibly override maximal compiled-in
limit if specified number is larger.)

Is it better approach? 

Milan