From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gmazyland@gmail.com>
Received: from mail.saout.de ([127.0.0.1])
 by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id P3JpIhgiXA4K for <dm-crypt@saout.de>;
 Sun,  6 Jan 2013 17:24:51 +0100 (CET)
Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com
 [209.85.215.181])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by mail.saout.de (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Sun,  6 Jan 2013 17:24:51 +0100 (CET)
Received: by mail-ea0-f181.google.com with SMTP id k14so7663999eaa.40
 for <dm-crypt@saout.de>; Sun, 06 Jan 2013 08:24:50 -0800 (PST)
Message-ID: <50E9A54F.1060203@gmail.com>
Date: Sun, 06 Jan 2013 17:24:47 +0100
From: Milan Broz <gmazyland@gmail.com>
MIME-Version: 1.0
References: <50DF635C.90003@gmail.com> <20121230083814.GA12005@tansi.org>
 <5f058e3c77fb70c10ba5e65e077baa3e.squirrel@ssl.verfeiert.org>
 <20121230102039.GA12533@tansi.org> <50E02816.9000001@gmail.com>
 <1357474572.2800.50.camel@scapa>
In-Reply-To: <1357474572.2800.50.camel@scapa>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.0-rc1
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: Yves-Alexis Perez <corsac@debian.org>
Cc: dm-crypt@saout.de

On 01/06/2013 01:16 PM, Yves-Alexis Perez wrote:
> On dim., 2012-12-30 at 12:40 +0100, Milan Broz wrote:

>> The switch --disable-kernel_crypto completely removes support,
>> so you can compile it with old kernel or without kernel headers.
>> (But no cipher benchmark and no tcrypt will be available.)
> 
> Is this really the proper fix? Usually, userland needing headers more
> recent than what's in linux-libc-dev should embed them, and correctly
> handle at runtime if the interfaces are available.

These are two separate problems
- you need to compile it on system where new header/kernel is not available
- you need to detect that current kernel is not able to use
userspace crypto API interface (this includes missing module etc.)

Both should be handled already.

> What happens here if cryptsetup is built on a recent enough kernel where
> the header is present, and then run on an old kernel? Will it fail
> gracefully?

It should print something like
...
Required kernel crypto interface not available.
Ensure you have algif_skcipher kernel module loaded.

Anyway, I would welcome people test this and report any problems here.
So if you have such system, please try it :)

Milan