loop-aes module can't be created in Dapper Drake

I was also unable to create the necessary loop aes module for my crypted partition under dapper drake.

With breezy I had no problemto build the module with
cd /usr/src/linux
make-kpkg --append-to-version=-i-386 configure
make-kpkg --append-to-version=-i-386 modules

dpkg -i ../loop-aes*.deb

But for Dapper I had to manual build the kernel with
  cd /usr/src/linux
  make bzImage
because loop-aes complains about the missing "vmlinux" file
---snip---
(cd /usr/src/linux && ./scripts/mod/modpost -m vmlinux /usr/src/modules/loop-aes/loop-AES-v3.1b/loop.o >/dev/null 2>&1
/bin/sh: line 1: 18593 Aborted ./scripts/mod/modpost -m vmlinux /usr/src/modules/loop-aes/loop-AES-v3.1b/loop.o >/dev/null 2>&1
make[2]: *** [loop.ko] Error 134
make[1]: *** [modules] Error 2
---snap---
After manual building the kernel I was able to build the loop-aes module.

diffstat between loop-aes-source 3.1b-8 and 3.1d-3

changelog of loop-aes 3.1d

Hum - the diffstat is not entirely useful. Can you run debian/rules configure on both an old and a new tarball and then do a diffstat again?

hi,

On Sunday 21 May 2006 14:07, Daniel Holbach wrote:
> Hum - the diffstat is not entirely useful. Can you run debian/rules
> configure on both an old and a new tarball and then do a diffstat
> again?

there is no such thing as debian/rules configure because it's just
a "plain" kernel patch for module-assistant.

please check as well the attached upstream changelog

regards,

\sh

Here's the diffstat:

 ChangeLog | 22
 Makefile | 31
 README | 14
 aes-x86.S | 1
 dkms.conf | 2
 glue.c | 4
 gnupg-1.4.2.diff | 11
 gnupg-1.4.3.diff | 11
 kernel-2.4.31.diff | 6542 ----------------------------------------------
 kernel-2.4.32.diff | 6543 ++++++++++++++++++++++++++++++++++++++++++++++
 kernel-2.6.13.diff | 6961 -------------------------------------------------
 kernel-2.6.16.diff | 7057 ++++++++++++++++++++++++++++++++++++++++++++++++++
 loop.c-2.4.patched | 4
 loop.c-2.6.patched | 156 -
 util-linux-2.12r.diff | 226 -
 15 files changed, 13935 insertions(+), 13650 deletions(-)

 ChangeLog | 6 ++++++
 Makefile | 27 +++++++++++++++++++--------
 README | 6 +++---
 dkms.conf | 2 +-
 4 files changed, 29 insertions(+), 12 deletions(-)

and here the complete ChangeLog diff:

--- ./loop-aes-source-3.1b/ciphers-v3.0b/ChangeLog 2005-03-18 16:54:54.000000000 +0100
+++ ./loop-aes-source-3.1d/ciphers-v3.0d/ChangeLog 2006-04-10 13:47:01.000000000 +0200
@@ -114,3 +114,9 @@
     - Changed gcc command line parameter order to be same as in kernel
       Makefile. Wrong parameter order caused miscompilation with Xen
       architecture (2.6 kernels).
+
+ciphers-v3.0c January 18 2006
+ - Makefile changed to work around 2.6.16-rc1 build breakage.
+
+ciphers-v3.0d April 10 2006
+ - Fixed Makefile incompatibility with USE_KBUILD=y build option.
--- ./loop-aes-source-3.1b/loop-AES-v3.1b/ChangeLog 2005-09-24 13:54:48.000000000 +0200
+++ ./loop-aes-source-3.1d/loop-AES-v3.1d/ChangeLog 2006-04-10 13:47:01.000000000 +0200
@@ -458,3 +458,25 @@
     - Added losetup -R option which recomputes size of loop device. Useful
       with loop device on top of LVM volume. Patch from Jim MacBaine. (2.4
       and 2.6 kernels)
+
+loop-AES-v3.1c January 18 2006
+ - WBINVD assembler instruction is no longer used on Xen builds.
+ - Makefile changed to probe .h header files instead of .c source files.
+ (2.4 and 2.6 kernels)
+ - compat_ioctl code updated to handle all 32bit/64bit loop ioctl
+ conversions on 2.6 kernels. No longer depends on fs/compat_ioctl.c
+ handling them.
+ - Semaphores are not used/needed anymore on 2.6 kernels.
+ - Makefile changed to work around 2.6.16-rc1 build breakage.
+
+loop-AES-v3.1d April 10 2006
+ - Fixed Makefile incompatibility with USE_KBUILD=y build option.
+ - Fixed incompatibility with CONFIG_PAX_KERNEXEC=y PAX config option.
+ - Fixed incompatibility with old SuSE 8.0 kernel that caused scheduler
+ interface to be misdetected.
+ - Changed mount to honor offset=N and sizelimit=N mount options when
+ they were used in combination with random keys generating phash=random
+ mount option. Old encrypted data is used in new keys generation, but
+ earlier buggy version always read and erased old data at offset=0.
+ - Added mount patch from Max Vozeler that makes it easier to first fsck
+ and then mount encrypted file systems....

Hm. I don't think we can really support this package, but if users report the debian package to be working but ours not, I'd agree with updating

What does it need to sync the package just before release? I think it's approved for syncing, right?

mfg.
\sh

I agree with Reinhard, Sebastian?

Fine with me too (Reinhard is on holidays for the next days AFAIK so let's set this to confirmed already)

I can also confirm the bug.

I had the same problem with this package. The file "modules/loop-aes/debian/rules" included in "loop-aes.tar.bz2" seems to have the wrong file permissions in this package version. (It lacks the "x" for owner or group).

Here is annother description of this bug:
http://www.ubuntuforums.org/showthread.php?t=178469&highlight=loop-aes

Btw: because everyone says that loop-aes is superior in security when compared to other encryption systems, why isn't it better supported in Ubuntu?

(IMO, encryption is becoming more important in the future due to the government increasingly intruding private spaces with the excuse of crime-fighting)

I am not sure since it works for me without but eventually loop-aes-utils have to be updated if loop-aes-source is upgraded to 3.1d since the util-linux patch has changed. Maybe only a fix of the error "/usr/share/modass/packages/generic.sh: line 70: debian/rules: Permission denied" is better but I don't know how.

Get this into Edgy, then see if it's -updates or -backports material.

Sorry, I filed bug number 49324 for the same package. I searched the bug reports before filing it, but never found this report.

Anyway, the problem is the file loop-aes/debian/rules in the source tarball does not have execute permissions. After assigning execute permissions for this file and then re-creating the tarball, I was able to successfully build the package.

motu-uvf cannot do anything about this

This package is important to me. My laptop is dual boot with Windows and the whole Dapper partition is encrypted with loop-aes for two reasons: a) to protect it from misbehaving Windows and b) in case my laptop is lost or stolen.

At present, loop-aes is the only secure encryption option in Linux. See http://mareichelt.de/pub/texts.cryptoloop.php for more details.

Thanks for a great distribution.

Reinhard, why can't this bug be fixed? It is a very simple fix. I enjoy using Ubuntu, and I think it is a very good distribution. However, refusing to fix a bug in a released package which prevents it from being used at all is simply irresponsible. Remember, Dapper is supposed to be supported for three to five years. Are you seriously going to allow this bug to remain during the entire support lifecycle?

A friendly Ubuntu user sent a message telling me about this bug. I'm not
clear what the current status is, but I can provide a simple fix. It has
already been included in later versions of the package. HTH.

cheers,
Max

diff -ru loop-aes-source-3.1b/debian/rules loop-aes-source-3.1b+x/debian/rules
--- loop-aes-source-3.1b/debian/rules 2006-07-07 13:34:57.000000000 +0200
+++ loop-aes-source-3.1b+x/debian/rules 2006-07-07 13:35:30.000000000 +0200
@@ -25,6 +25,7 @@

  dh_fixperms

+ chmod +x $(MODULES)/loop-aes/debian/rules
  cd $(MODULES)/.. && tar -cv modules | bzip2 -9 > loop-aes.tar.bz2
  rm -rf $(MODULES)

Why is this bug still present?

There is only one file permission to be changed to fix this.

Instead, you are scaring away users who simply want things to work.

so Max has given the solution are we happy in Dapper drake has it been tried?

alex

Fixed in 8.10 alpha.