Bug#342246: [ia64 headers] arch/ia64/modules.lds: No such file or directory

[Max Vozeler]

Package: linux-2.6
Version: 2.6.14-4
Severity: important

External module builds against ia64 headers currently fail in the
linker stage with an error about missing arch/ia64/module.lds.
Perhaps this is a reincarnation of #266804 ?

http://buildd.debian.org/fetch.php?&pkg=pwc&ver=10.0.9-1&arch=ia64&stamp=1132021994&file=log&as=raw:
  ...
LD [M]  /build/buildd/pwc-10.0.9/modules/pwc/pwc.o
  ld: cannot open linker script file 
/usr/src/linux-headers-2.6.14-1-itanium/arch/ia64/module.lds: No such file or 
directory

http://experimental.ftbfs.de/fetch.php?&pkg=loop-aes-modules&ver=3.1b%2B6%2B2&arch=ia64&stamp=1133810305&file=log&as=raw:
  ...
LD [M]  
/build/buildd/loop-aes-modules-3.1b+6+2/modules/loop-aes/loop-AES-v3.1b/tmp-d-kbuild/loop.o
  ld: cannot open linker script file 
/usr/src/linux-headers-2.6.14-2-itanium/arch/ia64/module.lds: No such file or 
directory

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#342248: [m68k headers] binaries are i386 - cannot execute binary file

[Max Vozeler]

Package: linux-2.6
Version: 2.6.12-10
Severity: important

This bug is a bit weird :-)

Apparently the binaries in m68k -headers were built for i386.
This breaks builds of external modules as they try to execute eg.
scripts/basic/fixdep on m68k.

  $ dpkg -x linux-headers-2.6.12-1-amiga_2.6.12-10_m68k.deb .
  $ cd usr/src/linux-headers-2.6.12-1-amiga/scripts/basic
  $ file fixdep
  fixdep:ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for 
GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped

http://experimental.ftbfs.de/fetch.php?&pkg=loop-aes-modules&ver=3.1b%2B6&arch=m68k&stamp=1131026070&file=log&as=raw
  ...
  make[3]: Entering directory `/usr/src/linux-headers-2.6.12-1-amiga'
CC [M]  
/build/buildd/loop-aes-modules-3.1b+6/modules/loop-aes/loop-AES-v3.1b/tmp-d-kbuild/patched-loop.o
  /bin/sh: scripts/basic/fixdep: cannot execute binary file

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#342804: loop-aes-source no longer needs reqsrc()

[Max Vozeler]

Package: module-assistant
Version: 0.10.2

Hi Eduard,

finally the day has come where loop-AES can be built without requiring
kernel source trees! :-) Please remove modass/packages/loop-aes-source
and add loop-aes-source to compliant.list.

cheers,
Max
diff -ruN module-assistant-0.10.2.orig/modass/compliant.list 
module-assistant-0.10.2/modass/compliant.list
--- module-assistant-0.10.2.orig/modass/compliant.list  2005-11-13 
12:32:25.0 +0100
+++ module-assistant-0.10.2/modass/compliant.list   2005-12-10 
17:01:43.0 +0100
@@ -28,7 +28,7 @@
 ipw2100-source
 ipw2200-source
 lm-sensors-source
-loop-aes-ciphers-source
+loop-aes-source
 lufs-source
 mga-vid-source
 ndiswrapper-source
diff -ruN module-assistant-0.10.2.orig/modass/packages/loop-aes-source 
module-assistant-0.10.2/modass/packages/loop-aes-source
--- module-assistant-0.10.2.orig/modass/packages/loop-aes-source
2005-06-16 00:19:06.0 +0200
+++ module-assistant-0.10.2/modass/packages/loop-aes-source 1970-01-01 
01:00:00.0 +0100
@@ -1,8 +0,0 @@
-#!/bin/sh
-MA_DIR=${MA_DIR:-/usr/share/modass}
-. $MA_DIR/packages/generic.sh
-reqsrc () {
-   true
-}
-$1 "$@"
-

Bug#323436: busybox-udeb: please build with CONFIG_UUENCODE=y

[Max Vozeler]

I wrote:
> It would be useful to have uuencode available in busybox-udeb for the
> support of block device encryption in partman-crypto. In particular, I'd
> like to use uuencode to create loop-AES multi-key style encryption keys.

I did the comparison again today and got updated information on the 
size increase:

du -b */bin/busybox
226152  1.01-3/bin/busybox
230248  1.01-3+uu/bin/busybox

du -b *.udeb
130854  busybox-udeb_1.01-3_i386.udeb
131424  busybox-udeb_1.01-3+uu_i386.udeb
 
dpkg --info | grep ^Installed-Size
busybox-udeb_1.01-3_i386.udeb Installed-Size: 256
busybox-udeb_1.01-3+uu_i386.udeb  Installed-Size: 260

The difference unpacked is effectively around 4k (including a few bytes
for the added symlink).

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#342248: [m68k headers] binaries are i386 - cannot execute binary file

[Max Vozeler]

Hi Christian,

On Thu, Dec 15, 2005 at 08:12:05AM +0100, Christian T. Steigies wrote:
> On Tue, Dec 06, 2005 at 03:48:40PM +0100, Max Vozeler wrote:
> > Apparently the binaries in m68k -headers were built for i386.
> 
> Yes, this may very well be possible, since the m68k linux-* packages
> were cross-compiled on i386. Since the linux-image-* packages are
> built in the same run, and they are properly cross-compiled for m68k
> and actually work (at least) on (my) m68k boxes, this must be a bug in
> the linux-headers build rules, they should be cross-compiled, too.

Thanks for looking into this.

> > This breaks builds of external modules as they try to execute eg.
> > scripts/basic/fixdep on m68k.
> 
> Do you have any external modules for m68k that are not part of the kernel?
> Who is supplying those?

It's not specific to m68k actually. The module in question is the
loop-AES extended loopback encryption module maintained by Jari Ruusu
<[EMAIL PROTECTED]>. I'm trying to build it for all 
archs that have 2.6 -di kernels in the archive.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#342248: [m68k headers] binaries are i386 - cannot execute binary file

[Max Vozeler]

On Thu, Dec 15, 2005 at 02:39:45PM +0100, Sven Luther wrote:
> Are you sure you are using the per-flavour header packages
> (linux-headers-2.6.14-2- ?

The package build-depends on linux-headers-2.6.14-2-all and 
uses the per-flavour headers for the actual build.

> Also, do you know about the external build module plan ? It is as follows :
> 
>   1) build-depend on linux-headers-2.6.14 or linux-headers-2.6.14-2-all.
>
>   2) look at /usr/src/linux-headers-2.6.14-2/flavours for a list of supported
>   flavours.
> 
>   3) for f in `cat /usr/src/linux-headers-2.6.14-2/flavours`; do 
> ...
> make ... KSRC=/lib/modules/2.6.14-2-$f
>   ...
>  done

Yes, this is basically what loop-aes-modules does. Except, I'm
extracting the available flavours from [1] at build-time of the
source package, because I want to include the package entries in
debian/control before upload and sometimes exclude flavours.

[1] /usr/src/linux-headers-2.6.14/debian/arch/*/defines 

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#343048: linux-image-2.6.14-2-686: fails to boot

[Max Vozeler]

On Tue, Dec 13, 2005 at 10:54:34AM +1030, Arthur Marsh wrote:
> Package: linux-image-2.6.14-2-686
> Version: 2.6.14-5
> Followup-For: Bug #343048
> 
> Same thing happens here. I also had problems trying to install
> loop-aes at the same time as upgrading from 2.6.14-4 to 2.6.14-5. The
> installation went ahead if I upgraded the kernel in aptitude first
> then the loop-aes stuff.

Regarding the loop-aes problem Arthur described: We worked together
to find out what the problem was and it turned out to have been a
transient error because of a previous failure to configure linux-image,
so not directly relevant for this bug.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#323436: busybox-udeb: please build with CONFIG_UUENCODE=y

[Max Vozeler]

Hi Bastian,

On Sat, Dec 17, 2005 at 02:25:25PM +0100, Bastian Blank wrote:
> On Tue, Aug 16, 2005 at 08:58:42PM +0200, Max Vozeler wrote:
> > It would be useful to have uuencode available in busybox-udeb for the
> > support of block device encryption in partman-crypto. In particular, I'd
> > like to use uuencode to create loop-AES multi-key style encryption keys.

> Reasons:
> - unneccesary, keys never needs to be readable.

They do need to be in base64 in order to retain compatibility with
previous (and future) loop-AES versions.

loop-AES multi-key contain 1, 64 or 65 newline-seperated keys. The
number of keys decides how the keyfile is used for setup: 1 key is
equivalent to normal hashed passphrase setup, 64-key format is v2
where keys are alternated to encrypt sectors, and 65-key format is
v2 with an extra key (65th) to seed MD5 IV computation.

> - reduces the entrophy.

No, the entropy does not change with different presentation. 

We have 2925 bytes of random data, or 45 bytes for each key. So
entropy available for each key (assuming ideal /dev/random) is
256^45 = 2.3485e+108. When we uuencode this data, each key
transforms into a base64-string of 60 bytes, so entropy is 64^60 =
2.3485e+108 = 256^45. The longer string makes up for the reduced
alphabet. That we only have base64 characters doesn't matter
because all keys are used as input to a hash function only.

> I reject the patch.

I understand your reservations, but I think they are not actually
justified. Please reconsider.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#323436: busybox-udeb: please build with CONFIG_UUENCODE=y

[Max Vozeler]

Hi Bastian,

On Sat, Dec 17, 2005 at 02:25:25PM +0100, Bastian Blank wrote:
> On Tue, Aug 16, 2005 at 08:58:42PM +0200, Max Vozeler wrote:
> > It would be useful to have uuencode available in busybox-udeb for the
> > support of block device encryption in partman-crypto. In particular, I'd
> > like to use uuencode to create loop-AES multi-key style encryption keys.
> 
> I reject the patch.
> Reasons:
> - unneccesary, keys never needs to be readable.
> - reduces the entrophy.

I forgot to mention one important point: Using uuencode is the way
loop-AES upstream recommends to create keyfiles. It has been documented
as recommended method since ~2003 or so [0]. So this is in fact not
something I've come up with or could reasonably decide not to adopt.

How could we go forward? Any chance it could still be added, or are
there other issues that prevent adding it from a d-i perspective?

cheers,
Max

--
[0] http://loop-aes.sf.net/loop-AES.README


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#344418: scponlyc: local privilege escalation in versions < 4.2

[Max Vozeler]

Package: scponly
Version: 4.1-1
Severity: critical

Hey Thomas,

scponly 4.2 has been released with a fix for the privilege 
escalation we've mailed about.

http://lists.ccs.neu.edu/pipermail/scponly/2005-December/001027.html:
> ...
> Problem Description: If ALL the following conditions are true,
> administrators using scponly-4.1 or older may be at risk of a local
> privilege escalation exploit:
> 
>  - the chrooted setuid scponlyc binary is installed
>  - regular non-scponly users have interactive shell access to the box
>  - a user executable dynamically linked setuid binary (such as ping)
>exists on the same file system mount as the user's home directory
> ...
>
> Fix:
> The new release of scponly-4.2 disallows chrooting to any directory that:
> - is owned by someone other than the superuser (UID 0)
> - is writeable by group or other

Some notes:
Having scponly installed and scponlyc setuid root is enough for
bug to be exploitable, hence severity critical.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#344418: scponlyc - chroot considered harmful

[Max Vozeler]

found 344418 4.0-1
tags 344418 + patch
thanks

The attached patch is extracted from 4.2 and should apply to 4.0-1 in
stable. I've verified that it builds and fixes the bug.

Note that there is a small change in behaviour that could break existing
(but unsafe) setups. If the home directory is not owned by root OR
writable by group or other, scponlyc will refuse to chroot. The solution
to this problem is to correct permissions on the home directory so that
the user cannot write to it directly.

cheers,
Max
--- scponly-4.0/scponly.c   2005-12-22 17:13:12.0 +0100
+++ scponly-4.0-chrootfix/scponly.c 2005-12-22 17:09:28.0 +0100
@@ -9,7 +9,8 @@
  
 #include  // io
 #include // for str*
-#include  // for fork, wait
+#include  // for fork, wait, stat
+#include   // for stat
 #include   // for wait
 #include // for exit, fork
 #include // EXIT_*
@@ -98,6 +99,7 @@
 {
FILE *debugfile;
int logopts = LOG_PID|LOG_NDELAY;
+   struct stat homedirstat;

/*
 * set debuglevel.  any nonzero number will result in debugging info to 
log
@@ -194,6 +196,27 @@
}
root_dir++;
}
+   if (-1 == stat(chrootdir, &homedirstat))
+   {
+   syslog (LOG_ERR, "couldnt stat chroot dir: %s with 
errno %u", chrootdir, errno);
+   exit(EXIT_FAILURE);
+   }
+   if (0 == (homedirstat.st_mode | S_IFDIR))
+   {
+   syslog (LOG_ERR, "chroot dir is not a directory: %s", 
chrootdir);
+   exit(EXIT_FAILURE);
+   }
+   if (homedirstat.st_uid != 0)
+   {
+   syslog (LOG_ERR, "chroot dir not owned by root: %s", 
chrootdir);
+   exit(EXIT_FAILURE);
+   }
+   if (0 != (homedirstat.st_mode | (S_IWOTH & S_IWGRP)))
+   {
+   syslog (LOG_ERR, "chroot dir writable by group/other: 
%s", chrootdir);
+   exit(EXIT_FAILURE);
+   }
+
if (debuglevel)
syslog (LOG_DEBUG, "chrooting to dir: \"%s\"", 
chrootdir);
if (-1==(chroot(chrootdir)))

Bug#344418: scponlyc: local privilege escalation in versions < 4.2

[Max Vozeler]

On Thu, Dec 22, 2005 at 04:56:55PM +0100, Max Vozeler wrote:
> http://lists.ccs.neu.edu/pipermail/scponly/2005-December/001027.html

This should read http_s_
https://lists.ccs.neu.edu/pipermail/scponly/2005-December/001027.html

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#344424: rssh: local privilege escalation in versions < 2.3.0 (CVE-2005-3345)

[Max Vozeler]

Package: rssh
Version: 2.2.3-3
Severity: critical
Tags: security

Hey Jesus,

rssh 2.3.0 has been released by Derek to fix the arbitrary chroot()
problem and privilege escalation we've mailed about (CVE-2005-3345)

http://www.pizzashack.org/rssh/index.shtml:
> Dec 18, 2005
> 
> rssh v2.3.0 released today!
> 
> Important Security Notice:
> 
> Max Vozeler has reported a problem whereby rssh can allow users who
> have shell access to systems where rssh is installed (and
> rssh_chroot_helper is installed SUID) to gain root access to the
> system, due to the ability to chroot to arbitrary locations. There are
> a lot of potentially mitigating factors, but to be safe you should
> upgrade immediately. This bug affects all versions of rssh from v2.0.0
> to v2.2.3, so please upgrade now!
> 
> The 2.3.0 release of rssh fixes this problem, by forcing the chroot
> helper to re-parse the config file to decide where to chroot(2) to.
> Users with shell access to the system can not subvert the chroot
> location, and may not be able to chroot at all depending on the
> configuration of rssh, which solves the problem.

Having rssh installed and rssh_chroot_helper setuid root is sufficient
for this bug to be exploitable, hence severity critical.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#338626: cdplay: ioctl subchnl: INVALID

[Max Vozeler]

Hi Ludovic,

On Fri, Nov 11, 2005 at 05:06:19PM +0100, Ludovic Rousseau wrote:
> Package: cdtool
> Version: 2.1.8-pre3-1
> Severity: important
> 
> $ cdplay
> cdplay: ioctl subchnl: INVALID
> 
> I guess the command was working before but as I don't use it often I
> don't know what I modified since then.

A very similar bug was reported upstream a few days ago and should be
fixed in the new version in unstable (2.1.8-pre4-1). Can you try that
version and let me know if it fixes the bug for you?

It would be interesting to know what kind of drive this is bug occurs
with. (hdparm -I  or similar)

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#338626: cdplay: ioctl subchnl: INVALID

[Max Vozeler]

On Fri, Nov 11, 2005 at 07:12:54PM +0100, Max Vozeler wrote:
> Hi Ludovic,
> 
> On Fri, Nov 11, 2005 at 05:06:19PM +0100, Ludovic Rousseau wrote:
> > Package: cdtool
> > Version: 2.1.8-pre3-1
> > Severity: important
> > 
> > $ cdplay
> > cdplay: ioctl subchnl: INVALID
> > 
> > I guess the command was working before but as I don't use it often I
> > don't know what I modified since then.
> 
> A very similar bug was reported upstream a few days ago and should be
> fixed in the new version in unstable (2.1.8-pre4-1). Can you try that
> version and let me know if it fixes the bug for you?

I just realized that the -pre4-1 package is still in incoming. You 
can find also it on http://people.debian.org/~xam/cdtool/ until it
enters the archive.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#338626: cdplay: ioctl subchnl: INVALID

[Max Vozeler]

On Sat, Nov 12, 2005 at 11:40:59AM +0100, Ludovic Rousseau wrote:
> Le Friday 11 November 2005 à 19:12:54, Max Vozeler a écrit:
> > It would be interesting to know what kind of drive this is bug occurs
> > with. (hdparm -I  or similar)
> 
> $ sudo hdparm -I /dev/cdrom
> 
> /dev/cdrom:
> 
> ATAPI CD-ROM, with removable media
> Model Number:   UJDA740 DVD/CDRW
> Serial Number:  
> Firmware Revision:  1.00
> Standards:
> Likely used CD-ROM ATAPI-1
> Configuration:
> DRQ response: 50us.
> Packet size: 12 bytes
> Capabilities:
> LBA, IORDY(cannot be disabled)
> Buffer size: 512.0kB
> DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2 
>  Cycle time: min=120ns recommended=120ns
> PIO: pio0 pio1 pio2 pio3 pio4 
>  Cycle time: no flow control=180ns  IORDY flow control=120ns
> HW reset results:
> CBLID- below Vih
> Device num = 0 determined by CSEL
> 
> 
> Let me know if you need more information about my configuration.

Thanks, this is useful information already.

cheers,
Max

Bug#344418: CVE reference

[Max Vozeler]

This is CVE-2005-4532.

BTW, did you have a chance to look at this bug yet? I'm considering
to do an NMU for unstable, but I'd prefer if someone who actively uses
scponly and who could test the changes would do the upload.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#346286: loop-aes-utils: mount -o loop fails with multiple loopdevices

[Max Vozeler]

Hi Bryan,

On Fri, Jan 06, 2006 at 03:07:41PM -0500, Bryan Donlan wrote:
> On my system (using udev, kernel 2.6.12-1-k7) only /dev/loop/0 is
> created automatically. This causes mount -o loop to fail after one loop
> device is in use, even though the loop module supports eight.

On this system here I'm unable to reproduce a failure. Although
only /dev/loop/0 exists, the /dev/loop$n devices up to max_loop
are created by udev and multiple mount -o loop calls work fine.

Can you tell me the exact steps leading to the failure and the 
error message mount returns? An strace log of failing mount -o 
loop would also be good for finding the error. Thanks.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#347595: mzscheme postinst fails with "reference to undefined identifier"

[Max Vozeler]

Package: mzscheme
Version: 209-9
Severity: important

The postinst of mzscheme fails when I try to upgrade to 209-9.
I can't make much sense of the error it returns unfortunately.
(log attached).

Random bits of other information:
Purging mzscheme and reinstalling gives the same failure.
Running /usr/bin/mzscheme -vm -L load.ss slibinit -e "(require
'new-catalog)" manually returns the same error.

cheers,
Max
Setting up mzscheme (209-9) ...
Completing install...This program should be used again only when the PLT tree 
was moved.
You should use bin/setup-plt instead.
finished
Building MzScheme zo files:  This can take a LONG time (10 minutes in some 
cases!)
finished.
Cataloging SLIB routines...
reference to undefined identifier: with-load-pathname
dpkg: error processing mzscheme (--configure):
 subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of drscheme:
 drscheme depends on mzscheme (= 1:209-9); however:
  Package mzscheme is not configured yet.
dpkg: error processing drscheme (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 mzscheme
 drscheme
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#347595: mzscheme postinst fails with "reference to undefined identifier"

[Max Vozeler]

On Wed, Jan 11, 2006 at 06:38:54PM +0100, Max Vozeler wrote:
> Package: mzscheme
> Version: 209-9
> Severity: important
> 
> The postinst of mzscheme fails when I try to upgrade to 209-9.
> I can't make much sense of the error it returns unfortunately.
> (log attached).

It seems like this has something to do with different versions of
slib: The failure occured with slib 3a2-3 but postinst works fine
with 3a1-4.2 installed. mzscheme works if I upgrade slib to 3a2-3
again after it has been configured.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#347595: mzscheme postinst failure related to slib

[Max Vozeler]

I've tested and confirmed the postinst failure in a clean chroot.
mzscheme configures without problem if slib is NOT installed, but
fails if slib (3a2-3) IS installed.

Perhaps this bug should be against slib. Unfortunately I have no
idea how slib and mzscheme interact.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#344418: updated patch for scponly chroot bug

[Max Vozeler]

The chroot-fix in 4.2 had a bug that refused to chroot although
directory permissions were OK. This bug was also present in the
previously attached patch. Attached is a fixed version.

cheers,
Max
diff -ur scponly-4.0/scponly.c scponly-4.0-chrootfix/scponly.c
--- scponly-4.0/scponly.c   2005-12-22 17:13:12.0 +0100
+++ scponly-4.0-chrootfix/scponly.c 2006-01-02 14:47:37.0 +0100
@@ -9,7 +9,8 @@
  
 #include  // io
 #include // for str*
-#include  // for fork, wait
+#include  // for fork, wait, stat
+#include   // for stat
 #include   // for wait
 #include // for exit, fork
 #include // EXIT_*
@@ -98,6 +99,7 @@
 {
FILE *debugfile;
int logopts = LOG_PID|LOG_NDELAY;
+   struct stat homedirstat;

/*
 * set debuglevel.  any nonzero number will result in debugging info to 
log
@@ -194,6 +196,32 @@
}
root_dir++;
}
+   if (-1 == stat(chrootdir, &homedirstat))
+   {
+   syslog (LOG_ERR, "couldnt stat chroot dir: %s with 
errno %u", chrootdir, errno);
+   exit(EXIT_FAILURE);
+   }
+   if (0 == (homedirstat.st_mode | S_IFDIR))
+   {
+   syslog (LOG_ERR, "chroot dir is not a directory: %s", 
chrootdir);
+   exit(EXIT_FAILURE);
+   }
+   if (homedirstat.st_uid != 0)
+   {
+   syslog (LOG_ERR, "chroot dir not owned by root: %s", 
chrootdir);
+   exit(EXIT_FAILURE);
+   }
+   if (0 != (homedirstat.st_mode & S_IWOTH))
+   {
+   syslog (LOG_ERR, "chroot dir writable by other: %s", 
chrootdir);
+   exit(EXIT_FAILURE);
+   }
+   if (0 != (homedirstat.st_mode & S_IWGRP))
+   {
+   syslog (LOG_ERR, "chroot dir writable by group: %s", 
chrootdir);
+   exit(EXIT_FAILURE);
+   }
+
if (debuglevel)
syslog (LOG_DEBUG, "chrooting to dir: \"%s\"", 
chrootdir);
if (-1==(chroot(chrootdir)))

Bug#339662: loop-aes-source: loop-aes does not build with kernel 2.6.14

[Max Vozeler]

close 339662 3.0a-1
thanks

Hi Evgeni,

On Thu, Nov 17, 2005 at 09:49:35PM +0100, Evgeni Golov wrote:
> I do not really understand why the make fails.

The error appears to be somewhere outside the make output you quoted.
Could you send the complete build log to this bug?

> With the Sid version of loop-aes-source everything compiles like a
> charm.

Your best bet is really to use the etch/sid package (see below for 
why I think so). The etch/sid package will continue to work/be
installable on sarge systems for some time. I'm considering to provide
backports of the package if the need should arise to change
(build-)dependencies to something not in sarge.

> Hope you can figure out, why the Sarge version does not compile and can
> fix this, so Sarge users can update to newer kernels without loosing the
> loop-aes support.

The problem is, even if we find a way to fix the build for newer
kernels while keeping it working for the older sarge kernels, there is 
a very low probability that the required changes could make it into a
sarge update. And it is non-trivial to track 2.6 kernels from an
external-module perspective, so I think this is a lost cause.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#339662: loop-aes-source: loop-aes does not build with kernel 2.6.14

[Max Vozeler]

Hi Evgeni,

On Mon, Nov 21, 2005 at 09:48:16AM +0100, Evgeni Golov wrote:
> I've still didn't try the new modules. Whats about the loop-aes-util
> package? Should I rebiuld it with Sid sources too? Or leave it and hope
> the new loop-aes module is backward-compatible?

There is no need for using newer -utils at the moment. The current
loop-aes-source in sid works fine with the version of -utils in sarge.
If some newer version of -source will require newer utils, I'll change
the dependencies of binary module packages to reflect such requirements.
By the way, you can use the upstream testsuite included in the sid
versions of loop-aes-$KVERS packages to verify that the modules and
-utils are working correctly. Just load the loop module and run
/usr/share/loop-aes-$KVERS/runtests.

> So wouldn't it be a candidate for debian-volatile then?

Perhaps, but something tells me this would be better be placed on
backports.org. I think I can directly upload to backports, so I'll 
look into this once the backports repository gets ready for sarge. 
Would that work for you like volatile, or is there something I'm 
not considering about differences between them?

> > Could you send the complete build log to this bug?
> 
> It's in the attachment - hope you can read it better than me. ;-)

There are a couple of problems actually. At least two changes that
were introduced in later versions of loop-AES to account for changes in
the kernel are missing from 2.2d: One to account for vanished
QUEUE_FLAG_ORDERED and another for change of lo_pending and perhaps
others from simple type int to struct { volatile int }. One could
probably backport the changes from a newer version, but the amount of
work that would bring doesn't seem justified given that later versions
already include them, are well tested and work OK on sarge.

cheers,
Max

--
PS: please CC the bug address [EMAIL PROTECTED] in your replies.
This way other users can find perhaps useful information in the BTS.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#312455: README.Debian in loop-aes-source is misleading.

[Max Vozeler]

Hi Samuli,

On Wed, Jun 08, 2005 at 12:17:37PM +0300, Samuli Suominen wrote:
> in /usr/share/doc/loop-aes-source/README.Debian, starting from line 15
> it says:
> 
> Kernel source requirement
> -
> 
>   loop-AES requires a full kernel source tree to build (kernel-
>   headers are not sufficient). Unless you already have a source
>   tree available, you could install one like this:
> 
> # apt-get install kernel-source-VERSION
> # cd /usr/src
> # tar -xjf kernel-source-VERSION
> 
> But in line 78 it says it's different for 2.6 users. Seems like
> kernel-headers IS sufficient for 2.6.8-2 users!

Maybe this line created a false impression :)

kernel-headers are not sufficient, also with 2.6 kernels. This is
because the Makefile for loop-AES needs the full kernel source (or
rather the file loop.c) to determine which settings should be used
for a particular kernel.

The note on line 78 about Module.symvers is to help create a source
tree that resembles the original as closely as possible - including
the correct value for symbol versions. Without that line the module 
still works, but will taint the kernel when it's inserted.

So the note is meant as: Do all the steps for 2.4 kernels, and all
the steps plus the one that says "only for 2.6" for 2.6 kernels.
Maybe this is confusing or badly worded, perhaps you have an idea
how it could be expressed better.

> And module-assistant auto-install loop-aes works. 

The interesting question is: What did you do to make it work?

Is it possible that you used module-assistant fakesource to create
that source tree?

Compilation with auto-install and only kernel-headers should fail
with a description of the problem, because loop-aes-source and
module-assistant know that it needs a full kernel source tree and
include checks for this.

> I guess this won't hit sarge but would be nice to get it fixed for 
> Etch users.

The requirement for full kernel source will probably stay for a 
while. But "module-assistant fakesource" does basically the same as
the steps described in README.Debian and is much easier, so the way
forward will probably be to document this command instead.

cheers,
Max



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#305721: /sbin/hwclock: [hwclock] Incorrect command-line option parsing

[Max Vozeler]

reassign 305721 coreutils
thanks

Hi Benjamin,

On Thu, Apr 21, 2005 at 11:24:18PM -0400, Benjamin A. Okopnik wrote:
> On Thu, Apr 21, 2005 at 11:19:11PM +0200, Mike Dornberger wrote:
> > On Thu, Apr 21, 2005 at 02:08:46PM -0400, Benjamin A. Okopnik wrote:
> > > [EMAIL PROTECTED]:~# hwclock --set --date="04-21-2005 13:58:00"
> > > [EMAIL PROTECTED]:~# hwclock
> > > Sat Feb 26 13:58:05 2011  -0.675597 seconds
> > 
> > > When '-' is used as the date delimiter, 'hwclock' sets some weird future
> > > day, month, and year - without any warning. It should either a) use the
> > > option correctly, or b) fail with an error message.
> > 
> > man hwclock refers to date(1), which prints the same date/time given
> > --date"04-...". I think the expected form with dashes is [yy]yy-mm-dd (IIRC
> > it's some ISO norm).
>  
> Ah - I see what you mean. It seems like both 'hwclock' and 'date' should
> require a '--iso' option (or something like that) to use that format;
> having it produce a result that's wildly different from the obviously
> expected one - and several people to whom I've spoken about it have
> _all_ run into a problem with this - seems really wrong.

> > It seems, there
> > are 21 month added to 2004-01-01 and then 2005 days, but I can't reproduce
> > the exact date (Feb 26 2011) myself (i.e. no "date") yet.
> 
> 
> [EMAIL PROTECTED]:~$ date --date="04-21-2005 13:58:00"
> Sat Feb 26 13:58:00 EST 2011
> [EMAIL PROTECTED]:~$ date --version
> date (coreutils) 5.2.1
> Written by David MacKenzie.
> 
> 
> Yep, seems to be repeatable. I guess it's a bug against 'glibc' -
> although both 'hwclock' and date _should_ have an option to
> differentiate between these two (very subtle but with a large
> difference in the result) options.

Maybe, but all hwclock does is to call /bin/date to parse the date
string into epoch seconds. If date returns a valid number - as opposed
to an error, there is no way for hwclock to detect the misparsing.

I'm reassigning your bug to coreutils hoping that the maintainers
knows more about this problem and can tell where exactly changes for
a solution to this could be made.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#310381: loop-aes-source: leaves diversion in place on purge

[Max Vozeler]

Hi Thomas,

(once again sorry for my slowness. I have split your bug report 
into bugs #302324 and #310381 because these are different issues.)

On Mon, Apr 04, 2005 at 06:04:10PM +0200, Thomas Braun wrote:
> > > These seems to be the consequence of the last bugfix.
> > > Going to $MODULDIR/block/drivers and issuing
> > > laptop:/lib/modules/2.6.10-nb/kernel/drivers/block# ls -l loop*
> > > -rw-r--r--  1 root root 20597 Mar 29 20:25 loop.ko-orig
> >
> > This one is confusing me.
> >
> > Just so I understand, when you purged the kernel image, was
> > loop-aes installed? Did you purge loop-aes as well? Was loop-aes
> > installed at the time you did "ls" above?
> 
> Now I got a method to show the error.



> The "FATAL" error message occurs also when I first install loop-aes
> and then the kernel. Only first kernel and afterwards loop-aes doesn't
> show the problem.

Thanks. I can reproduce this (#302324).

Are you still seeing the leftover loop.ko-orig problem? That one was
worrying me a bit, since it could mean that the system and diversions
are left in an inconsistent state. 

I have not been able to reproduce this here though, having tried all
combinations of install/purge/upgrade loop-aes- and kernel-image
I could think of. Perhaps, do you remember making some local changes
like renaming the look.ko or loop.ko-orig ?

> > Do you remember which version of loop-aes was installed before?
> Unfortunately I don't remember.

No problem, I hope we can still find the reason or perhaps some way to
reproduce the conditions.

> > I'm thinking this could be a side effect from changing the diversion
> > during upgrade from a version < 2.2d-3, if kernel-image was removed
> > before upgrade of the loop-aes package.
> >
> > Another thing, could you send output of
> >
> >  dpkg-divert --list | grep /lib/modules/2.6.10-nb
> >  dpkg -S /lib/modules/2.6.10-nb/kernel/drivers/block/loop.ko{,-orig}
> 
> Yeep after the above dpkg invocation:
> 
> thomas:/usr/src# dpkg-divert --list | grep /lib/modules/2.6.10-knoelk/
> diversion of /lib/modules/2.6.10-knoelk/kernel/drivers/block/loop.ko 
> to /lib/modules/2.6.10-knoelk/kernel/drivers/block/loop.ko-orig by 
> loop-aes-2.6.10-knoelk
> 
> thomas:/usr/src# dpkg 
> -S /lib/modules/2.6.10-knoelk/kernel/drivers/block/loop.ko{,-orig}
> diversion by loop-aes-2.6.10-knoelk 
> from: /lib/modules/2.6.10-knoelk/kernel/drivers/block/loop.ko
> diversion by loop-aes-2.6.10-knoelk 
> to: /lib/modules/2.6.10-knoelk/kernel/drivers/block/loop.ko-orig
> loop-aes-2.6.10-knoelk, 
> kernel-image-2.6.10-knoelk: 
> /lib/modules/2.6.10-knoelk/kernel/drivers/block/loop.ko
> diversion by loop-aes-2.6.10-knoelk 
> from: /lib/modules/2.6.10-knoelk/kernel/drivers/block/loop.ko
> diversion by loop-aes-2.6.10-knoelk 
> to: /lib/modules/2.6.10-knoelk/kernel/drivers/block/loop.ko-orig

This state looks sane.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#305765: umount - segfault on not permitted actions

[Max Vozeler]

tags 305765 +patch
thanks

Hi Eduard,

On Fri, Apr 22, 2005 at 03:13:33AM +0200, Eduard Bloch wrote:
> when I try to umount a partition mounted by the same user before, the
> operation fails and I get a segmentation fault. On partitions mounted by
> root, there is a proper message:
> 
> $ umount /mnt/c
> umount: only root can unmount /dev/hda1 from /mnt/c
> $ umount /mnt/d 
> Segmentation fault
> $ mount
> ...
> /dev/hda1 /mnt/c vfat 
> rw,nodiratime,nosuid,nodev,noexec,fmask=,dmask=,codepage=cp437,iocharset=utf8,utf8
>  0 0
> /dev/sda1 /mnt/d vfat 
> rw,nodiratime,nosuid,nodev,noexec,uid=1000,gid=1000,fmask=,dmask=,codepage=cp437,iocharset=utf8,utf8
>  0 0
> $ cat /etc/fstab
> ...
> /dev/hda1   /mnt/c  vfatauto,user,umask=000,utf80 
>   0
> UUID="41EB-F193"   /mnt/d  vfatauto,user,umask=000,utf8   
>  0   0
> 
> This looks odd, I cannot see the reasons for a) not allowing the umount and b)
> the segmentation fault.

For b), there are a couple of different issues at play.

The segfault happens in has_uuid(), when mount_get_devname_by_uuid()
returns NULL and umount then tries dereferencing that. Attached patch
has_uuid_segv.diff should address that.

Next thing, has_uuid() passes the device as argument to ..by_uuid().
That obviously fails, since there is no UUID of "/dev/sda1" :-) Attached
patch has_uuid_uuid.diff changes it to really pass the uuid as expected.

Still doesn't work? The uuid passed to has_uuid() includes the double
quotes around the uuid if configured like in your fstab. If you remove
those quotes, umount should now happily umount the correct device.

cheers,
Max
--- mount/fstab.c~  2005-04-22 14:21:16.730370176 +0200
+++ mount/fstab.c   2005-04-22 14:21:57.685144104 +0200
@@ -294,9 +294,12 @@
 static int
 has_uuid(const char *device, const char *uuid){
const char *devuuid;
-   int ret;
+   int ret = 0;
 
devuuid = mount_get_devname_by_uuid(device);
+if (!devuuid)
+return ret;
+
ret = !strcmp(uuid, devuuid);
/* free(devuuid); */
return ret;
--- mount/fstab.c~  2005-04-22 14:31:51.975301216 +0200
+++ mount/fstab.c   2005-04-22 14:32:12.104241152 +0200
@@ -293,14 +293,14 @@
 
 static int
 has_uuid(const char *device, const char *uuid){
-   const char *devuuid;
+   const char *devname;
int ret = 0;
 
-   devuuid = mount_get_devname_by_uuid(device);
-if (!devuuid)
+   devname = mount_get_devname_by_uuid(uuid);
+if (!devname)
 return ret;
 
-   ret = !strcmp(uuid, devuuid);
+   ret = !strcmp(device, devname);
/* free(devuuid); */
return ret;
 }

Bug#305765: umount - segfault on not permitted actions

[Max Vozeler]

Hi Eduard,

On Fri, Apr 22, 2005 at 09:19:54PM +0200, Eduard Bloch wrote:
> * Max Vozeler [Fri, Apr 22 2005, 02:45:28PM]:
> 
> > Still doesn't work? The uuid passed to has_uuid() includes the double
> > quotes around the uuid if configured like in your fstab. If you remove
> > those quotes, umount should now happily umount the correct device.
> 
> Still does not work (though not segfaulting any more). This time with:
> 
> umount: /mnt/d mount disagrees with the fstab
> 
> No matter whether there are double quotes or not.

Hmm. Could you put a few printfs in there (has_uuid) to show what
happens on your system?

My /dev/sda1 vfat partition showed identical symptoms, but those 
were fixed with the two patches.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#309622: INTL:vi

[Max Vozeler]

Hi Clytie,

On Wed, May 18, 2005 at 09:40:25PM +0930, Clytie Siddall wrote:
> Package: cdtool
> Version: 2.1.5-13
> Severity: minor
> Tags: l10n, patch
> 
> The Vietnamese translation for debconf: cdtool

Thanks. I hope to upload a version with your translation later today.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#309977: loop-aes-utils: multi-key (V3?) in losetup broken

[Max Vozeler]

Hi Anno,

On Sat, May 21, 2005 at 12:08:42AM +0200, Anno wrote:
> Package: loop-aes-utils
> Version: 2.12a-3
> Severity: important
> 
> short version:
> 
> Problem: Unable to losetup an encrypted filesystem.
> Error: "ioctl: LOOP_MULTI_KEY_SETUP_V3: invalid argument"
> TEMPORARY FIX: downgrade from 2.12p-4 to 2.12a-3

The likely reason is:

You have a keyfile in v3 format, but were using it with v2 tools and
loop-AES previously. This combination detected and used the v3 keyfile
in v2 multi-key mode. 

When you upgraded to 2.12p-4, losetup started to (correctly) identify
your keyfile as v3 and tried to use it with v3 multi-key setup. The v3
setup is not supported by 2.x versions of the loop-AES module, hence
the "invalid argument" error from losetup.

> long story:
> 
> My setup had been in a working state.
> On May 18th I did an upgrade of loop-aes-utils 2.12a-3 -> 2.12p-4
> (together with upgrade of mount 2.12-10 -> 2.12p-4.)
> Since then I didn't use the computer. Today, it refused to mount my
> encrypted filesystem that is stored in a file, giving the above error
> message. I use twofish192 encryption on it, the keys are gpg-encrypted
> stored in some part of the file (created like
> <[EMAIL PROTECTED]>).

Right, the commands Jari showed there indeed create a v3 keyfile.

> Purging and reinstalling loop-aes-utils (2.12p-4) didn't help.
> So, finally I came to downgrading and luckily found a mirror with
> 2.12a-3 still available. After the downgrade mounting the fs worked
> right away.

The problem with your current setup (v3 keyfile used in v2 mode) is 
that once you upgrade to loop-AES 3.x, this combination will likely
result in an incorrect decryption.

To avoid that problem, I would recommend to put loop-aes-utils 2.12a-3
on hold for the moment, and re-encrypt the device when you have time /
space / ... for this.

You have two options for re-encryption: Using a v2 keyfile (works with
your current loop-AES module and -utils 2.12a or 2.12p, but needs a new
v2 keyfile), or using a v3 keyfile (requires loop-aes-source 3.x from
experimental and -utils 2.12p, but you can keep your current v3 keyfile)

(It MAY be possible to avoid re-encryption by editing your keyfile and
"converting" it to v2 mode. I haven't tried this, but if you feel like
having an adventure ;-) you could try 

  # dd if=/dev/device of=keyfile-v3 bs=8192 count=1 conv=notrunc
  (try losetup with 2.12a and this keyfile-v3 to verify it's correct)

  # gpg --decrypt keyfile-v3 | head -n 64 | gpg --symmetric -a > keyfile-v2
  (try losetup again with this keyfile-v2; It should work with 2.12a
   and 2.12p; losetup -a from 2.12p should show "multi-key-v2")

  # dd if=keyfile-v2 of=/dev/device bs=8192 count=1 conv=notrunc

Please be careful though and make backups in case you want to try this.
All but the last step should be safe to try without touching your data.
Again, not tested, NO WARRANTY, etc.)

Hope this helps.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#309977: multi-key (V3?) in losetup broken

[Max Vozeler]

On Sat, May 21, 2005 at 11:30:40PM +0200, Anno wrote:
> > # gpg --decrypt keyfile-v3 | head -n 64 | gpg --symmetric -a > keyfile-v2
> > (try losetup again with this keyfile-v2; It should work with 2.12a
> > and 2.12p; losetup -a from 2.12p should show "multi-key-v2")

> With "loop-aes-utils -a" from 2.12p I get "multi-key-v3" !!! with
> keyfile-v2 and the original error message with keyfile-v3. But with
> keyfile-v2 (using loop-aes-utils 2.12p) it is set up correctly and I
> can mount it!  What is going on here?

If you do "gpg --decrypt keyfile-v2 | wc -l", does it return 64 or
something else?

If it returns 64, things are alright.

I just verified that losetup of a v2 keyfile using 2.12p shows as
multi-key-v3, when you have a loop-AES version 2.x module loaded.
With a version 3.x module, it correctly shows as multi-key-v2.

The reason is that between loop-AES 2.x and 3.x, the meaning of bit
0x8 in lo_flags changed from do_bmap to multi-key mode v3, which
caused losetup to detect multi-key-v3 if do_bmap was set.

This change affects only losetup -a display though, and the setup is 
correctly done in multi-key mode v2. 

> I noticed that keyfile-v3 has 3915 newlines at the end, is this to
> worry me for the final step (which I did not yet take)?:

I don't think it should be a problem (but note that I haven't used 
such a setup myself). The reason for the newlines is probably the 
first step Jari showed in his mail, 'yes ""', which filled the first
block with newlines. Since the keyfile is likely shorter than 8192
bytes, the padding was extracted along with it when you did the dd.

> > # dd if=keyfile-v2 of=/dev/device bs=8192 count=1 conv=notrunc
> 
> I'm planning on trying this on a copy tomorrow. I want to give my
> harddrive a little rest inbetween though it's rather large
> quantities it has to shuffle around. And a comment from you if you
> think it is safe any more would maybe spare it some heat, particularly
> if you don't think I should try this... ;-)

If it's on a copy, go ahead :-) 

The only problem I can think of is, if your converted keyfile is
smaller than the old one, parts of the old keyfile maybe left in
place where there should be newline padding. I don't know if gpg 
requires this padding, perhaps it is necessary to repeat the first
step (yes "" | dd ...) before writing the new keyfile.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#285385: cdtool: cdtool+cdown man page .IP typos

[Max Vozeler]

tags 285385 +fixed-upstream
thanks

Kevin Ryde <[EMAIL PROTECTED]> wrote:
> Package: cdtool
> Version: 2.1.5-11
> Severity: minor
> 
> Running "man cdtool" prints a warning
> 
> /tmp/zmanOAMI8V:122: warning: numeric expression expected (got `d')
> 
> (though it scrolls off the top of the screen almost immediately).
> 
> I think the line
> 
> .IP \fB-d device\fR
> 
> should be
> 
> .IP "\fB-d device\fR"
> 
> .IP takes a single argument.

Thank you Kevin.

I've applied the fix upstream and will include it in the next Debian
upload.

Cheers,
Max

-- 
308E81E7B97963BCA0E6ED889D5BD511B7CDA2DC


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#315660: mount: Wrong hash generation for the loopback device.

[Max Vozeler]

Hi YAEGASHI,

On Fri, Jun 24, 2005 at 09:49:59PM +0900, YAEGASHI Takeshi wrote:
> --- util-linux-2.12p.orig/mount/lomount.c 2005-06-24 20:39:36.073263112 
> +0900
> +++ util-linux-2.12p/mount/lomount.c  2005-06-24 21:12:33.783174438 +0900

(...)

> + strcpy(passwdbuff+1,pass);
>   passwdbuff[0] = 'A';
> - rmd160_hash_buffer(keybits,pass,strlen(pass));
> - 
> rmd160_hash_buffer(keybits+HASHLENGTH,passwdbuff,strlen(pass)+1);
> + rmd160_hash_buffer(keybits,pass,passwdlen);
> + rmd160_hash_buffer(keybits+HASHLENGTH,passwdbuff,passwdlen+1);
> + memset(pass, 0, passwdlen);
> + free(passwdbuff);

This looks like it leaves the passphrase as free'd memory on the heap.
Maybe add a memset before freeing the buffer?

>   memcpy((char*)loopinfo64.lo_encrypt_key,keybits,2*HASHLENGTH);
>   keylength=0;
>   for(i=0; crypt_type_tbl[i].id != -1; i++){
> @@ -423,15 +426,18 @@
>   default:
>   if (hash_password) {

(...)

> + strcpy(passwdbuff+1,pass);
>   passwdbuff[0] = 'A';
> - rmd160_hash_buffer(keybits,pass,strlen(pass));
> - 
> rmd160_hash_buffer(keybits+HASHLENGTH,passwdbuff,strlen(pass)+1);
> - memset(pass, 0, strlen(pass));
> + rmd160_hash_buffer(keybits,pass,passwdlen);
> + 
> rmd160_hash_buffer(keybits+HASHLENGTH,passwdbuff,passwdlen+1);
> + memset(pass, 0, passwdlen);
> + free(passwdbuff);

Similar thing here.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#319062: module-assistant: doesn't detect compiler for fakesource trees

[Max Vozeler]

Package: module-assistant
Version: 0.9.4

Trees created using m-a fakesource don't seem to get the correct
compiler detected. This is probably because include/linux/compile.h
doesn't exist in fakesource trees, right?

The attached patch is RFC since I'm not sure about the implications of
copying compile.h from -headers into the source tree. It works for me,
compiles loop-aes-{source,ciphers-source} correctly, but I'm not sure
whether it's a correct solution.

>From what I can gather the kernel uses the compile.h header only for
the information value, to include version, build date etc. in strings,
but does not use it for conditional compilation. So, I suppose there
would be little or no harm including it.

cheers,
Max
--- module-assistant~   2005-07-01 01:18:03.0 +0200
+++ module-assistant2005-07-19 17:21:06.0 +0200
@@ -1124,6 +1124,7 @@
my $extra=$2;
my $confile="/boot/config-$kvers";
my $symverfile="$usrc/$kheaders-$kvers/Module.symvers";
+   my $compileh="$usrc/$kheaders-$kvers/include/linux/compile.h";
print gettext("Experimental kernel source recreating method...\nGetting 
source...") . "\n";
return 0 if withecho "apt-get ".($opt_noninter?"-y":"")." install 
$ksource-$knmbr";
if(! -f $confile) {
@@ -1142,6 +1143,9 @@
if (-f $symverfile) {
   withecho "cp", $symverfile, "$usrc/$ksource-$kvers/Module.symvers";
}
+   if (-f $compileh) {
+  withecho "cp", $compileh, 
"$usrc/$ksource-$kvers/include/linux/compile.h";
+   }
rmdir $tmpdir;
if($extra) {
   open(mk,"<$usrc/$ksource-$kvers/Makefile");

Bug#319633: module-assistant: fakesource does not work for 2.4 kernels

[Max Vozeler]

Package: module-assistant
Version: 0.9.5
Tags: patch

It would be nice if fakesource could be used to create source trees
also for 2.4.x kernels.

This currently fails in the make dep step because autoconf.h is not
available. I suppose this is because oldconfig is implied in the 2.6
prepare target, but needs to be run explicitly for 2.4.x.

The attached patch makes fakesource work for me to the point that
loop-aes-{source,ciphers-source} can be built correctly for 2.4.27.
Please consider applying it.

cheers,
Max
# m-a -l 2.4.27-2-386 fakesource
Experimental kernel source recreating method...
Getting source...
Reading package lists... Done
Building dependency tree... Done
kernel-source-2.4.27 is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
Config not found, getting headers to extract the config...
Reading package lists... Done
Building dependency tree... Done
kernel-headers-2.4.27-2-386 is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
Extracting pristine kernel source, please wait...
Installing to final location and configuring, please wait...
make: *** No rule to make target `prepare'.  Stop.
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep 
scripts/mkdep.c
make[1]: Entering directory `/usr/src/kernel-source-2.4.27-2-386/arch/i386/boot'
make[1]: Nothing to be done for `dep'.
make[1]: Leaving directory `/usr/src/kernel-source-2.4.27-2-386/arch/i386/boot'
rm -f .depend .hdepend
make _sfdep_kernel _sfdep_drivers _sfdep_mm _sfdep_fs _sfdep_net _sfdep_ipc 
_sfdep_lib _sfdep_crypto _sfdep_arch/i386/kernel _sfdep_arch/i386/mm 
_sfdep_arch/i386/lib _sfdep_arch/i386/math-emu _FASTDEP_ALL_SUB_DIRS="kernel 
drivers mm fs net ipc lib crypto arch/i386/kernel arch/i386/mm arch/i386/lib 
arch/i386/math-emu"
make[1]: Entering directory `/usr/src/kernel-source-2.4.27-2-386'
make -C kernel fastdep
make[2]: Entering directory `/usr/src/kernel-source-2.4.27-2-386/kernel'
make[2]: *** No rule to make target 
`/usr/src/kernel-source-2.4.27-2-386/include/linux/autoconf.h', needed by 
`/usr/src/kernel-source-2.4.27-2-386/include/linux/modules/signal.ver'.  Stop.
make[2]: Leaving directory `/usr/src/kernel-source-2.4.27-2-386/kernel'
make[1]: *** [_sfdep_kernel] Error 2
make[1]: Leaving directory `/usr/src/kernel-source-2.4.27-2-386'
make: *** [dep-files] Error 2

Faked kernel source for the Kernel 2.4.27-2-386.
Warning: the configuration may not match the running kernel.

--- module-assistant~   2005-07-01 01:18:03.0 +0200
+++ module-assistant2005-07-19 05:46:14.0 +0200
@@ -1158,7 +1158,7 @@
   close(mk);
}
 
-   withecho "cd $usrc/$ksource-$kvers ; make prepare || make dep";
+   withecho "cd $usrc/$ksource-$kvers ; make prepare || make oldconfig dep";
print "\n" . wrap('', '', sprintf(gettext("Faked kernel source for the 
Kernel %s.\nWarning: the configuration may not match the running kernel."), 
$kvers)) . "\n\n";
&initksrc;
 }

Bug#319757: netpbm: arbitrary postscript code execution

[Max Vozeler]

Package: netpbm
Version: 2:10.0-8
Severity: important
Tags: security woody sarge etch sid patch

Hi Andi,

we've already talked about this, I'm just filing it to keep track.
Please refer to message <[EMAIL PROTECTED]>
(sent to maintainer and security team) for all details.

Quick description: pstopnm calls the ghostscript interpreter on
potentially untrusted postscript without specifying the -dSAFER option.
Not running under -dSAFER allows postscript code to do file IO and to
open pipes to arbitrary external programs, including /bin/sh.

I'm filing this as important bug since I'm not clear in which situations
users would run pstopnm on untrusted postscript. In principle, when that
happens, an attacker could have arbitrary shell commands executed with
the permissions of the user who runs pstopnm.

This bug affects oldstable, stable, testing and sid (as of 2:10.0-8)

cheers,
Max
--- netpbm-free-10.0/pnm/pstopnm.c~ 2005-06-02 16:20:03.205694176 +0200
+++ netpbm-free-10.0/pnm/pstopnm.c  2005-06-02 16:24:24.978262856 +0200
@@ -568,11 +568,11 @@
 pm_message("execing '%s' with args '%s' (arg 0), "
"'%s', '%s', '%s', '%s', '%s', '%s', '%s'",
ghostscriptProg, arg0,
-   deviceopt, outfileopt, gopt, ropt, "-q", "-dNOPAUSE", "-");
+   deviceopt, outfileopt, gopt, ropt, "-q", "-dNOPAUSE", 
"-dSAFER",  "-");
 }
 
 execl(ghostscriptProg, arg0, deviceopt, outfileopt, gopt, ropt, "-q",
-  "-dNOPAUSE", "-", NULL);
+  "-dNOPAUSE", "-dSAFER", "-", NULL);
 
 pm_error("execl() of Ghostscript ('%s') failed, errno=%d (%s)",
  ghostscriptProg, errno, strerror(errno));

Bug#319758: pstotext: arbitrary postscript code execution

[Max Vozeler]

Package: pstotext
Version: 1.9-1
Severity: grave
Justification: remote code execution
Tags: security woody sarge etch sid patch

Hi Ray,

we've already talked about this, I'm just filing it to keep track.
Please refer to message <[EMAIL PROTECTED]>
(sent to maintainer and security team) for all details.

Quick description: pstotext calls the ghostscript interpreter on
untrusted postscript without specifying the -dSAFER option. Not running
under -dSAFER allows postscript code to do file IO and to open pipes to
arbitrary external programs, including /bin/sh. 

I'm filing this as a grave bug since pstotext is listed in mailcap and
used to display postscript by several programs, including for example 
mutt. An attacker who knows that one is using a mail program that uses
mailcap could exploit this bug by sending malicious postscript as email
attachment and tricking the user into viewing it.

This bug affects oldstable, stable, testing and sid (as of 1.9-1). 

cheers,
Max
--- pstotext-1.9/main.c~2005-06-02 15:42:33.754177096 +0200
+++ pstotext-1.9/main.c 2005-06-02 15:45:20.412084016 +0200
@@ -231,9 +231,9 @@
   sprintf(
 gs_cmdline,
 #ifdef VMS
-"%s -r72 \"-dNODISPLAY\" \"-dFIXEDMEDIA\" \"-dDELAYBIND\" 
\"-dWRITESYSTEMDICT\" %s \"-dNOPAUSE\" %s %s %s",
+"%s -r72 \"-dNODISPLAY\" \"-dFIXEDMEDIA\" \"-dDELAYBIND\" 
\"-dWRITESYSTEMDICT\" %s \"-dNOPAUSE\" \"-dSAFER\" %s %s %s",
 #else
-"%s -r72 -dNODISPLAY -dFIXEDMEDIA -dDELAYBIND -dWRITESYSTEMDICT %s 
-dNOPAUSE %s %s %s",
+"%s -r72 -dNODISPLAY -dFIXEDMEDIA -dDELAYBIND -dWRITESYSTEMDICT %s 
-dNOPAUSE -dSAFER %s %s %s",
 #endif
 gs_cmd,
 (debug ? "" : "-q"),

Bug#320039: libdebian-installer: please include /dev/loop/$n in mapdevfs

[Max Vozeler]

Package: libdebian-installer
Version: 0.30
Severity: wishlist
Tags: patch

Hi,

please include /dev/loop/$n devices in the mapdevfs table. This would
be useful to have for the loop-AES support in partman-crypto that I'm
working on at the moment.

cheers,
Max
Index: libdebian-installer/src/system/devfs.c
===
--- libdebian-installer/src/system/devfs.c  (Revision 29486)
+++ libdebian-installer/src/system/devfs.c  (Arbeitskopie)
@@ -59,6 +59,7 @@
 { 3,   0,  "hd",   ENTRY_TYPE_DISC,0,  6 },
 { 4,   64, "ttyS", ENTRY_TYPE_NUMBER,  0,  0 },
 { 4,   0,  "tty",  ENTRY_TYPE_NUMBER,  0,  0 },
+{ 7,   0,  "loop", ENTRY_TYPE_NUMBER,  0,  0 },
 { 8,   0,  "sd",   ENTRY_TYPE_DISC,0,  4 },
 { 9,   0,  "md",   ENTRY_TYPE_NUMBER,  0,  0 },
 { 11,  0,  "scd",  ENTRY_TYPE_NUMBER,  0,  0 },

Bug#318944: loop-aes-utils: losetup man page example wrong

[Max Vozeler]

Hi Diego,

On Mon, Jul 25, 2005 at 08:44:42PM +0200, Diego Biurrun wrote:
> On Fri, Jul 22, 2005 at 03:53:49PM +0200, Max Vozeler wrote:
> > On Mon, Jul 18, 2005 at 09:11:21PM +0200, Diego Biurrun wrote:
> > > Please update the man page accordingly, this is a major inconvenience.
> > 
> > I'm afraid I can no longer change this for stable though.
> 
> Are you 100% sure about this?  Documentation updates are uncritical and
> this bug is really painful until you figure things out...

Actually, I'm not completely sure.

Looking at [1] and the developer's reference suggests that it would not
qualify - unless the requirements have changed for sarge - since it
doesn't fix a bug that would be considered release critical.

The risk of introducing breakage is pretty non-existant though, and I
would like to get this updated myself. I might ask the stable release
manager whether he would consider approving an upload fixing this.

For people reading the bug report (it will stay available for the
sarge version thanks to versioned BTS), please use the example given
in README.gz instead of the one from losetup.8.

cheers,
Max

[1] http://people.debian.org/~joey/3.0r6/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#299887: [INTL:ru] patch

[Max Vozeler]

Hi Basil, 

Basilius <[EMAIL PROTECTED]> wrote:
> Update russian templates file (fix some typos)
> 
> I apologize.

No problem! But I only noticed after uploading cdtool with the last
version you sent.

How important do you consider these fixed typos? I would wait with
another upload until 2.1.5-12 makes it into testing, but depending
on what you tell me, I would upload sooner.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#315198: libc6-dev: FTBFS with gcc-4.0: Fix xdr.h lvalue casts

[Max Vozeler]

Hi glibc maintainers,

> GCC-4.0 is now the default compiler, this bug should be fixed ASAP as it's 
> blocking uploads to packages build-depending on this functionality.

Do you already have plans or a timeframe for uploading 2.3.5 to
unstable?

The bug currently causes util-linux and loop-aes-utils to FTBFS in
unstable, and I can confirm that building with libc6-dev from
experimental works fine.

I can't think of a clean way to work around this bug in packages that
include xdr.h until the macro is changed, should you see one, I would 
very much appreciate to learn.

cheers,
Max



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#315198: libc6-dev: FTBFS with gcc-4.0: Fix xdr.h lvalue casts

[Max Vozeler]

Hi GOTO,

On Tue, Jul 12, 2005 at 09:11:03PM +0900, GOTO Masanori wrote:
> At Mon, 11 Jul 2005 19:10:28 +0200,
> Max Vozeler wrote:
> > The bug currently causes util-linux and loop-aes-utils to FTBFS in
> > unstable, and I can confirm that building with libc6-dev from
> > experimental works fine.
> 
> OK.  2.3.5 will be appeared at last - please wait a bit with your
> kindful patience.

Will do - many thanks for your work on this!

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#318478: qemu: NIC detection in d-i fails and occasional hangs

[Max Vozeler]

Package: qemu
Version: 0.7.0-2
Severity: normal

Hi,

when using d-i in qemu, NIC detection fails since a couple of days ago.
I *think* this coincides with the upgrade to xorg in unstable. The NIC
works fine if manually selected, but cannot be detected anymore.

Another issue that I think could be related is that qemu occasionally
hangs now during normal operation. By "hang" I mean that at different
stages of the d-i install, nothing happens (no IO, no significant CPU
load) until I do a couple of console switches or give keyboard input -
not sure which one actually makes it continue again.

cheers,
Max

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages qemu depends on:
ii  bochsbios 2.1.1+20041109-3   BIOS for the Bochs emulator
ii  libc6 2.3.2.ds1-22   GNU C Library: Shared libraries an
ii  libsdl1.2debi 1.2.7+1.2.8cvs20041007-5.1 Simple DirectMedia Layer
ii  openhackware  0.4.1-1OpenFirmware emulator for PowerPC
ii  proll 18-1   JavaStation PROM 2.x compatible re
ii  vgabios   0.5c-1 VGA BIOS software for the Bochs an
ii  zlib1g1:1.2.2-8  compression library - runtime

Versions of packages qemu recommends:
ii  debootstrap   0.3.1.4Bootstrap a basic Debian system
ii  sharutils 1:4.2.1-14 shar, unshar, uuencode, uudecode

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#302324: loop-aes-source: initrd complains about missing module loop.ko_orig

[Max Vozeler]

Hi Thomas,

[EMAIL PROTECTED] wrote:
> seems that I'm the only user of loop-aes ;)

Dunno, but you have a good touch for shaking out the corner
cases :-)

> When I now install the kernel-image (before I have purged the same
> version) I get the following message:
> [...]
> Setting up kernel-image-2.6.10-nb (01) ...
> /usr/sbin/mkinitrd: add_modules_dep_2_5: modprobe failed
> FATAL: Module loop.ko_orig not found.
> WARNING: This failure MAY indicate that your kernel will not boot!
> but it can also be triggered by needed modules being compiled into
> the kernel.
> [...]

What happens here is that mkinitrd does not ignore non-.o/.ko/.gz
modules as it probably should. The warning is "just" annoying though,
it makes no difference for the initrd build in any way. 

> These seems to be the consequence of the last bugfix.
> Going to $MODULDIR/block/drivers and issuing
> laptop:/lib/modules/2.6.10-nb/kernel/drivers/block# ls -l loop*
> -rw-r--r--  1 root root 20597 Mar 29 20:25 loop.ko-orig

This one is confusing me. 

Just so I understand, when you purged the kernel image, was 
loop-aes installed? Did you purge loop-aes as well? Was loop-aes
installed at the time you did "ls" above?

Do you remember which version of loop-aes was installed before?
I'm thinking this could be a side effect from changing the diversion
during upgrade from a version < 2.2d-3, if kernel-image was removed
before upgrade of the loop-aes package.

Another thing, could you send output of 
 
 dpkg-divert --list | grep /lib/modules/2.6.10-nb
 dpkg -S /lib/modules/2.6.10-nb/kernel/drivers/block/loop.ko{,-orig}

Thanks.

> When is this diversion thing issued ?
> When I install loop-aes or the korresponding kernel-image ?

It's added in preinst of the loop-aes module package, so when you
install that one.

> I don't know if this bug would be better directed to initrd-tools ...

The spurious warning from mkinitrd can be fixed in initrd-tools.
I think I'll prepare a patch and later clone/submit the bug there.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#331268: ITP: loop-aes-modules -- auto-build loop-AES binary modules

[Max Vozeler]

Package: wnpp
Owner: Max Vozeler <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: loop-aes-modules
  Version : 3.0d+3.0b+1
  Upstream Author : Max Vozeler <[EMAIL PROTECTED]>
* URL : http://svn.decl.org/public/loop-aes-modules
* License : GPL
  Description : auto-build loop-AES binary modules (deb and udeb)

This package auto-builds loop-AES binary module packages for a
configurable list of kernels and archs (currently 2.6.12).

The module packages are required to support installing onto
loop-AES encrypted partitions in debian-installer. This needs an 
udeb for the d-i kernel in first stage and a module package that
can be installed before booting into second stage.

I would appreciate feedback/review from people with experience
auto-building external modules.

cheers,
Max

--
(There was a promising discussion on debian-kernel recently about
a common framework for auto-building external modules. The need for
this package will likely go away once that framework can be used.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#331439: RM: loop-aes-ciphers-source -- RoM; superseded by loop-aes-source

[Max Vozeler]

Package: ftp.debian.org

Hi ftp-masters,

loop-aes-ciphers-source has been merged into loop-aes-source as of
version 3.1b-1. The two can coexist, but -ciphers-source is no longer
actually useful. Please remove the package from unstable.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#325131: gcc-4.0: regression on hppa and arm, possibly wrong code

[Max Vozeler]

On Fri, Aug 26, 2005 at 02:15:11PM +0200, Max Vozeler wrote:
> On Fri, Aug 26, 2005 at 01:27:43PM +0200, Falk Hueffner wrote:
> > Max Vozeler <[EMAIL PROTECTED]> writes:
> >
> > > I can reproduce the problem in paer's sid chroot (hppa) and have put
> > > gcc-3.4 and gcc-4.0 builds with -save-temps on [1]. If there is
> > > other information that could be useful to you, please let me know.
> >
> > It would be nice to know how to reproduce the problem.
> >
>
> Note sure if this is what you are asking, if you copy the
> 2.3b-gcc-4.0 directory [1] to a hppa machine and run "make tests"
> there it should show the wrong result.

I've been able to find a reduced testcase that shows the problem. You
can find below the results using gcc-3.4 and gcc-4.0 with -O1/-O2 each.
The problem only shows with gcc-4.0 and -O2 on hppa.

  [EMAIL PROTECTED]:~/testcase7$ make OPT=-O1 CC=gcc-4.0 clean test; ./test
  rm test
  gcc-4.0 -Wall -O1 -gtest.c   -o test
  j=16 x=13aec3aec3aec3ae

  [EMAIL PROTECTED]:~/testcase7$ make OPT=-O2 CC=gcc-4.0 clean test; ./test
  rm test
  gcc-4.0 -Wall -O2 -gtest.c   -o test
  j=16 x=13aec3aac3aec3ae
^

  [EMAIL PROTECTED]:~/testcase7$ make OPT=-O1 CC=gcc-3.4 clean test; ./test
  rm test
  gcc-3.4 -Wall -O1 -gtest.c   -o test
  j=16 x=13aec3aec3aec3ae

  [EMAIL PROTECTED]:~/testcase7$ make OPT=-O2 CC=gcc-3.4 clean test; ./test
  rm test
  gcc-3.4 -Wall -O2 -gtest.c   -o test
  j=16 x=13aec3aec3aec3ae
  [EMAIL PROTECTED]:~/testcase7$ exit

The same tests on my i386 machine gives the correct result
(x=13aec3aec3aec3ae) for each combination of gcc-3.4/gcc-4.0 and -O1/-O2

In case you can see some flaw in the testcase that would explain the
result, please educate me :) It looks OK to my untrained eye and gives
no compiler warnings. 

For reference the exact compiler versions installed on paer:

  $ gcc-4.0 -v
  Using built-in specs.
  Target: hppa-linux-gnu
  Configured with: ../src/configure -v 
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls 
--without-included-gettext --enable-threads=posix --program-suffix=-4.0 
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk 
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre 
--enable-mpfr --disable-werror --enable-checking=release hppa-linux-gnu
  Thread model: posix
  gcc version 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)

  $ gcc-3.4 -v
Reading specs from /usr/lib/gcc/hppa-linux-gnu/3.4.5/specs
Configured with: ../src/configure -v 
--enable-languages=c,c++,f77,pascal,objc,ada --prefix=/usr 
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4 
--enable-shared --with-system-zlib --enable-nls --without-included-gettext 
--program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt 
--enable-clocale=gnu --enable-libstdcxx-debug hppa-linux-gnu
Thread model: posix
gcc version 3.4.5 20050821 (prerelease) (Debian 3.4.4-8)

  $ uname -a
  Linux paer 2.6.12-1-64-smp #1 SMP Wed Aug 10 16:47:43 UTC 2005 parisc64 
GNU/Linux

cheers,
Max
CFLAGS = -Wall $(OPT) -g

test:

clean:
-rm test
#include 
#include 

#define R(x,y)  ((y) >> (x))
#define S(x,y)  (((y) >> (x)) | ((y) << (64 - (x
#define lSig1(x)((S(19,(x))) ^ (S(61,(x))) ^ (R(6,(x

int main(int argc, char **argv)
{
u_int64_t W[80], Wm2, x;
register int j;

for (j=0; j < 80; j++)
W[j] = 0x1234123412341234ll;

j = 16;
Wm2 = W[j - 2];
x = lSig1(Wm2);

printf("j=%02d x=%llx\n", j, x);
return 0;
}

Bug#325131: gcc-4.0: regression on hppa and arm, possibly wrong code

[Max Vozeler]

On Mon, Sep 12, 2005 at 01:29:38PM +0200, Max Vozeler wrote:
> I've been able to find a reduced testcase that shows the problem.
> can find below the results using gcc-3.4 and gcc-4.0 with -O1/-O2 each.
> The problem only shows with gcc-4.0 and -O2 on hppa.

In case this helps analyze the problem, attached is the difference in
generated code as seen by objdump -d. Both binaries were compiled using
gcc-4.0 on paer, one with -O1 and the other with -O2.

cheers,
Max
--- test.O1.disas   2005-09-12 11:23:31.0 +
+++ test.O2.disas   2005-09-12 11:23:24.0 +
@@ -118,41 +118,41 @@
 
 00010550 :
10550:  6b c2 3f d9 stw rp,-14(,sp)
-   10554:  37 de 05 80 ldo 2c0(sp),sp
-   10558:  34 13 00 00 ldi 0,r19
-   1055c:  37 df 3a 91 ldo -2b8(sp),r31
-   10560:  22 a0 62 46 ldil 12341000,r21
-   10564:  36 b5 04 68 ldo 234(r21),r21
-   10568:  22 c0 62 46 ldil 12341000,r22
-   1056c:  36 d6 04 68 ldo 234(r22),r22
+   10554:  34 13 00 00 ldi 0,r19
+   10558:  37 de 05 80 ldo 2c0(sp),sp
+   1055c:  22 a0 62 46 ldil 12341000,r21
+   10560:  36 b5 04 68 ldo 234(r21),r21
+   10564:  22 c0 62 46 ldil 12341000,r22
+   10568:  36 d6 04 68 ldo 234(r22),r22
+   1056c:  37 df 3a 91 ldo -2b8(sp),r31
10570:  34 14 05 00 ldi 280,r20
10574:  0b f3 0a 1c add,l r19,r31,ret0
-   10578:  0f 95 12 80 stw r21,0(,ret0)
-   1057c:  0f 96 12 88 stw r22,4(,ret0)
-   10580:  36 73 00 10 ldo 8(r19),r19
+   10578:  36 73 00 10 ldo 8(r19),r19
+   1057c:  0f 95 12 80 stw r21,0(,ret0)
+   10580:  0f 96 12 88 stw r22,4(,ret0)
10584:  8a 74 3f dd cmpb,<> r20,r19,10578 
10588:  0b f3 0a 1c add,l r19,r31,ret0
-   1058c:  4b d7 3b 71 ldw -248(,sp),r23
-   10590:  4b d8 3b 79 ldw -244(,sp),r24
-   10594:  08 17 02 55 copy r23,r21
-   10598:  d3 15 09 94 shrpw r21,r24,19,r20
-   1059c:  d2 f8 09 93 shrpw r24,r23,19,r19
-   105a0:  d2 f8 08 5d shrpw r24,r23,29,ret1
-   105a4:  d3 15 08 5c shrpw r21,r24,29,ret0
-   105a8:  0b 93 02 93 xor r19,ret0,r19
-   105ac:  0b b4 02 94 xor r20,ret1,r20
-   105b0:  d6 b5 0b 5a depw,z r21,5,6,r21
-   105b4:  d3 18 1b 26 extrw,u r24,25,26,r24
-   105b8:  0b 15 02 58 or r21,r24,r24
-   105bc:  d2 f7 1b 26 extrw,u r23,25,26,r23
-   105c0:  23 48 10 00 ldil 10800,r26
-   105c4:  37 5a 02 70 ldo 138(r26),r26
-   105c8:  0a f3 02 97 xor r19,r23,r23
-   105cc:  0b 14 02 98 xor r20,r24,r24
+   1058c:  4b dc 3b 71 ldw -248(,sp),ret0
+   10590:  4b dd 3b 79 ldw -244(,sp),ret1
+   10594:  08 1c 02 56 copy ret0,r22
+   10598:  d3 93 1b 26 extrw,u ret0,25,26,r19
+   1059c:  d3 b6 09 98 shrpw r22,ret1,19,r24
+   105a0:  d3 9d 09 97 shrpw ret1,ret0,19,r23
+   105a4:  d3 b4 1b 26 extrw,u ret1,25,26,r20
+   105a8:  d3 9d 08 5d shrpw ret1,ret0,29,ret1
+   105ac:  d6 b6 0b 5a depw,z r22,5,6,r21
+   105b0:  d3 b6 08 5c shrpw r22,ret1,29,ret0
+   105b4:  0a 95 02 54 or r21,r20,r20
+   105b8:  0b 97 02 97 xor r23,ret0,r23
+   105bc:  0b b8 02 98 xor r24,ret1,r24
+   105c0:  34 19 00 20 ldi 10,r25
+   105c4:  0a 77 02 97 xor r23,r19,r23
+   105c8:  0a 98 02 98 xor r24,r20,r24
+   105cc:  23 48 10 00 ldil 10800,r26
105d0:  e8 5f 1c b5 b,l 10430 <_end_init+0x14>,rp
-   105d4:  34 19 00 20 ldi 10,r25
-   105d8:  34 1c 00 00 ldi 0,ret0
-   105dc:  4b c2 3a 59 ldw -2d4(,sp),rp
+   105d4:  37 5a 02 70 ldo 138(r26),r26
+   105d8:  4b c2 3a 59 ldw -2d4(,sp),rp
+   105dc:  34 1c 00 00 ldi 0,ret0
105e0:  e8 40 c0 00 bv r0(rp)
105e4:  37 de 3a 81 ldo -2c0(sp),sp
 

Bug#325131: gcc-4.0: regression on hppa and arm, possibly wrong code

[Max Vozeler]

On Mon, Sep 12, 2005 at 03:49:26PM +0200, Falk Hueffner wrote:
> 
> Max Vozeler <[EMAIL PROTECTED]>, [EMAIL PROTECTED] schrieb am 12.09.05 
> 13:48:41:
> > On Mon, Sep 12, 2005 at 01:29:38PM +0200, Max Vozeler wrote:
> > > I've been able to find a reduced testcase that shows the problem.
> > > can find below the results using gcc-3.4 and gcc-4.0 with -O1/-O2 each.
> > > The problem only shows with gcc-4.0 and -O2 on hppa.
> 
> Thanks a lot, this is really helpful.
> 
> Here is a smaller test case. It also fails on i386 with
> gcc-4.120050705 at  -O2 -fschedule-insns, but not with
> -fno-schedule-insns, so the bug seems to be in instruction scheduling.

Indeed, I can confirm this.

Building aespipe with -fno-schedule-insns -O2 in the same environment
that previously failed (paer sid chroot) produces correct results and
makes it pass the testsuite.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#328141: mount: umount -r drops nosuid flag

[Max Vozeler]

tags 328141 +patch
thanks

On Wed, Sep 14, 2005 at 06:22:00AM +1000, Paul Szabo wrote:
> [ .. umount -r drops flags ]
>   http://www.securityfocus.com/archive/1/410333

The attached patch is extracted from 2.12r-pre1, it simply
disallows user r/o remounts.

cheers,
Max
--- /home/max/deb/loop-aes-utils/trunk/mount/umount.c   2005-08-27 
12:24:13.0 +0200
+++ util-linux-2.12r-pre1/mount/umount.c2005-09-10 20:07:38.0 
+0200
@@ -714,7 +714,7 @@
 
if (getuid () != geteuid ()) {
suid = 1;
-   if (all || types || nomtab || force)
+   if (all || types || nomtab || force || remount)
die (2, _("umount: only root can do that"));
}
 

Bug#328141: CAN-2005-2876

[Max Vozeler]

This bug has been assigned CAN-2005-2876

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#328626: Sarge update for loop-aes-utils (CAN-2005-2876)

[Max Vozeler]

Hi security team,

the loop-aes-utils package in sarge is affected by CAN-2005-2876 
(#328626). I've prepared a stable-security upload of 2.12p-4sarge1 
with a fix backported from 2.12r-pre1:

http://people.debian.org/~xam/security/loop-aes-utils/

This bug will be fixed in unstable with 2.12p-9 (pending upload).

Note that this update will not be effective until mount is also
fixed. The /bin/umount binary from 'mount' is diverted to
/bin/umount.orig and remains setuid root, so an attacker could 
just use that binary instead of the one from loop-aes-utils.

cheers,
Max
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 16 Sep 2005 15:12:02 +0200
Source: loop-aes-utils
Binary: loop-aes-utils
Architecture: source i386
Version: 2.12p-4sarge1
Distribution: stable-security
Urgency: high
Maintainer: [EMAIL PROTECTED]
Changed-By: Max Vozeler <[EMAIL PROTECTED]>
Description: 
 loop-aes-utils - Tools for mounting and manipulating filesystems
Changes: 
 loop-aes-utils (2.12p-4sarge1) stable-security; urgency=high
 .
   * [SECURITY] CAN-2005-2876. Applied patch from 2.12r-pre1 to
 fix a local privilege escalation vulnerability in umount -r.
Files: 
 e708365ea3b674ef3983edda999d8070 684 admin optional 
loop-aes-utils_2.12p-4sarge1.dsc
 f085322d67f1300c914910c1ca1fd95f 69614 admin optional 
loop-aes-utils_2.12p-4sarge1.diff.gz
 de42b52353becd80ee61922a1b21486a 142250 admin optional 
loop-aes-utils_2.12p-4sarge1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDKssbnVvVEbfNotwRAhUGAKCSHj4ioqGwIT2pmDgFH7xl+l5VjQCfR273
6QgKuGXJnEKqu+Sx9mStamA=
=BVgD
-END PGP SIGNATURE-

Bug#325131: gcc-4.0: regression on hppa and arm, possibly wrong code

[Max Vozeler]

Package: gcc-4.0
Version: 4.0.1-6

Hi gcc maintainers,

I'm seeing an interesting failure of the aespipe testsuite on hppa 
when built with gcc-4.0. I can't say for sure that gcc-4.0 is at fault,
but it does look like it and a hppa porter suggested it likely is.

The problem shows up in aespipe's C implementation of SHA256/384/512
(sha512.c). SHA256 works as expected, but SHA384 and -512 give wrong
results when built with gcc-4.0 and -O2, but only on hppa and arm.

This is what I've found out so far:
 - No problem with gcc-3.3 or gcc-3.4
 - No problem with -O0 or -O1
 - No runtime problem; old binary passes the testsuite
 - No difference in preprocessed sha512.c between gcc-3.4 and gcc-4.0

I can reproduce the problem in paer's sid chroot (hppa) and have put
gcc-3.4 and gcc-4.0 builds with -save-temps on [1]. If there is other
information that could be useful to you, please let me know.


cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#325135: maildrop: lockmail doesn't drop privileges

[Max Vozeler]

Package: maildrop
Version: 1.5.3-1.1
Severity: critical
Justification: local privilege escalation
Tags: security sarge sid patch

Hi Josip,

I've already tried to contact you about this, but have not heard
from you. I'm filing it now to keep track. Please refer to message
<[EMAIL PROTECTED]> for full details.

Short description: 
lockmail.maildrop (setgid mail) lets the user specify a program and
execvp()s it, but does not drop egid mail privilege before doing so.
This opens a trivial privilege escalation (see "poc") to group mail.

The bug affects 1.5.3-1.1 sarge/etch/sid and 1.8.1-2 in experimental,
and should be easy to fix: Just add setgid(getgid()) before the
execvp(). I tested the attached patch briefly and verified that it
builds and prevents this bug.

The bug appears to be specific to Debian, upstream doesn't
seem to install lockmail with a setgid flag.

cheers,
Max
$ id
uid=1000(user) gid=1000(user) groups=1000(user)
$ lockmail.maildrop foo /bin/sh
$ id
uid=1000(user) gid=1000(user) egid=8(mail) groups=1000(user)
--- liblock/lockmail.c~ 2005-06-01 21:43:06.273749472 +0200
+++ liblock/lockmail.c  2005-06-01 21:32:04.0 +0200
@@ -160,6 +160,8 @@
 
if (pid == 0)
{
+   setgid(getgid());
+
(void)caught();
execvp(argvec[0], argvec);
 

Bug#325131: gcc-4.0: regression on hppa and arm, possibly wrong code

[Max Vozeler]

On Fri, Aug 26, 2005 at 01:27:43PM +0200, Falk Hueffner wrote:
> Max Vozeler <[EMAIL PROTECTED]> writes:
> 
> > I can reproduce the problem in paer's sid chroot (hppa) and have put
> > gcc-3.4 and gcc-4.0 builds with -save-temps on [1]. If there is
> > other information that could be useful to you, please let me know.
> 
> It would be nice to know how to reproduce the problem.
> 

Note sure if this is what you are asking, if you copy the
2.3b-gcc-4.0 directory [1] to a hppa machine and run "make tests"
there it should show the wrong result. 

I can tell that sha512.c is at fault because tests involving
AES128/192/256 using a different hash function (-H rmd160) gave 
expected results. 

Further reduced: 
 dd if=/dev/zero of=test-file3 bs=1024 count=10
 echo 12345678901234567890 >test-file4
 ./aespipe -p 3 -e AES256 -H SHA512 -C 0 < test-file3 > test-file1 \
   3http://people.debian.org/~xam/aespipe/hppa/>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#329365: mailleds: user may kill any process

[Max Vozeler]

Package: mailleds
Version: 0.93-11
Severity: important
Tags: security patch

Hi Dennis,

I did a quick security audit of mailleds today and noticed a small but
significant flaw in the way it handles the pidfile. It can be abused
by local users to kill arbitrary processes on the system by making it
create a pidfile with write permission for the user.

It uses fopen() to create the pidfile, which respects the calling user's
umask. If the user calls mailleds with umask of 0, the pidfile will be
created writable for the user with 0666 permission. The user could now
write any pid into it, run mailleds -k and have the process killed.
Someone could use this to eg. kill syslogd.

To fix this, I would suggest adding a call to umask(022) explicitly
before write_pidfile() function gets called. Attached patch to this
effect is compile tested and verified to fix this bug.

cheers,
Max
$ umask 0
$ mailleds -x
$ ls -al /var/run/mailleds-user.pid
-rw-rw-rw-  1 root user 5 2005-09-21 13:52 /var/run/mailleds-user.pid

$ x=$(pidof syslogd)
$ ps $x
  PID TTY  STAT   TIME COMMAND
 4995 ?Ss 0:00 /sbin/syslogd

$ echo $x > /var/run/mailleds-user.pid
$ mailleds -k
mailleds: process 4995 killed sucessfully

$ ps $x
  PID TTY  STAT   TIME COMMAND
--- mailleds-0.93/mailleds.c~   2005-09-21 13:40:32.0 +0200
+++ mailleds-0.93/mailleds.c2005-09-21 13:44:31.0 +0200
@@ -425,6 +425,9 @@
}
 #endif
 
+   /* set umask for pidfile */
+   umask(022);
+   
/*if (!opt_x) {*/
pid = getpid();
write_pidfile();

Bug#326482: partman requires plural form for strings

[Max Vozeler]

On Sat, Sep 03, 2005 at 11:00:09PM +0200, Denis Barbier wrote:
> [...]
> > So, unfortunately, the only solution is to actually document in the
> > templates that MINIMUM=8
> 
> Maybe this variable could be dropped, it seems pretty useless.

Agreed, at present it is not actually useful.

The minimum is variable because some key modes exist that require a
certain length passphrase, but none of them have been implemented yet.
The 8 character limit is in fact quite artificial and will likely be
replaced by a more precise per-cipher/crypt_type limit eventually.

For the moment I think we could simply drop the variable if it makes
translator's lifes more difficult. If it's not too bad, perhaps we could
also live with the (probably minor?) inaccuracy in translations. Both
options are fine with me, let me know what you prefer.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#321964: linux-2.6: package that depends on all -headers for $arch

[Max Vozeler]

Package: linux-2.6
Version: 2.6.12-1
Severity: wishlist

There used to exist packages that depend on all -headers packages for a
particular arch (eg. kernel-headers-2.6.11-1-i386). This is very useful
for build-depends when autobuilding external module packages. 

Such packages seem to no longer exist with the new kernel packaging -
please consider to re-add something like it.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#323436: busybox-udeb: please build with CONFIG_UUENCODE=y

[Max Vozeler]

Package: busybox-udeb
Version: 1.00-4
Severity: wishlist

It would be useful to have uuencode available in busybox-udeb for the
support of block device encryption in partman-crypto. In particular, I'd
like to use uuencode to create loop-AES multi-key style encryption keys.

$ du -b busybox-udeb_1.00-4*
130536  busybox-udeb_1.00-4_i386.udeb
130574  busybox-udeb_1.00-4+uuencode.udeb

Interestingly, the busybox binary doesn't seem to get any larger from
including uuencode. I've verified that one binary supports uuencode and
the other does not, but somehow I still don't trust this result:

$ du -b */bin/busybox
226152  udeb/bin/busybox
226152  udeb+uuencode/bin/busybox

cheers,
Max
--- busybox-1.00/debian/config-udeb-linux~  2005-08-04 14:36:41.0 
+0200
+++ busybox-1.00/debian/config-udeb-linux   2005-08-04 14:37:03.0 
+0200
@@ -139,7 +139,7 @@
 CONFIG_UNIQ=y
 # CONFIG_USLEEP is not set
 # CONFIG_UUDECODE is not set
-# CONFIG_UUENCODE is not set
+CONFIG_UUENCODE=y
 # CONFIG_WATCH is not set
 CONFIG_WC=y
 # CONFIG_WHO is not set

Bug#323442: liferea: NET_TIMEOUT sometimes too low

[Max Vozeler]

Package: liferea
Version: 0.9.4-1

The network timeout in liferea is sometimes too low for feeds that
take a long time to send data. 

For example, I'm subscribed to
 for
commit messages to the d-i repository. Sometimes the WebSVN feed takes
very long to reply and liferea shows a 404 error.

I've been setting NET_TIMEOUT to 60 seconds using attached patch and
this seems to be working fine. I have no idea whether it could bring
unwanted side effects, but it worked for me during the last two days.

cheers,
Max
--- liferea-0.9.4/src/net/netio.c~  2005-08-16 21:28:00.0 +0200
+++ liferea-0.9.4/src/net/netio.c   2005-08-16 21:28:11.0 +0200
@@ -63,7 +63,7 @@
 #include "../update.h"
 
 static int const MAX_HTTP_REDIRECTS = 10;  /* Maximum number of redirects 
we will follow. */
-static int const NET_TIMEOUT = 30; /* Global network 
timeout in sec */
+static int const NET_TIMEOUT = 60; /* Global network 
timeout in sec */
 static int const NET_READ = 1;
 static int const NET_WRITE = 2;
 

Bug#320443: partman: humandev for /dev/loop/*

[Max Vozeler]

Package: partman
Version: 68
Severity: wishlist
Tags: patch

Hi,

this patch adds an entry for /dev/loop/* to the humandev function which
shows loop devices as "Loopback (loop%d)". Something like this would be
useful to have for the loop-AES support in partman-crypto.

cheers,
Max

Index: debian/partman.templates
===
--- debian/partman.templates(Revision 29310)
+++ debian/partman.templates(Arbeitskopie)
@@ -256,6 +256,10 @@
 Type: text
 _Description: LVM VG %s, LV %s
 
+Template: partman/text/loopback
+Type: text
+_Description: Loopback (loop%d)
+
 Template: partman/text/cancel_menu
 Type: text
 _Description: Cancel this menu
Index: definitions.sh
===
--- definitions.sh  (Revision 29310)
+++ definitions.sh  (Arbeitskopie)
@@ -554,6 +554,11 @@
db_metaget partman/text/lvm_lv description
printf "$RET" $vg $lv
;;
+   /dev/loop/*)
+   n=${1#/dev/loop/}
+   db_metaget partman/text/loopback description
+   printf "$RET" $n
+   ;;
*)
# Check if it's an LVM1 device
vg=`echo "$1" | sed -e 's,/dev/\([^/]\+\).*,\1,'`

Bug#320443: partman: humandev for /dev/loop/*

[Max Vozeler]

On Fri, Jul 29, 2005 at 08:17:07PM +0200, Frans Pop wrote:
> On Friday 29 July 2005 14:46, Max Vozeler wrote:
> > this patch adds an entry for /dev/loop/* to the humandev function
> > which shows loop devices as "Loopback (loop%d)". Something like this
> > would be useful to have for the loop-AES support in partman-crypto.

> Thanks. Applied with one change.
> 
> Instead of
>_Description: Loopback (loop%d)
> I've committed
>_Description: Loopback (loop%s)
> to be consistent with the rest of the script.

That works for me. Thanks! 

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#316810: loop-aes-source: clarify requirement for kernel-source

[Max Vozeler]

Hi Andrew,

thanks for your suggestions for improving the documentation. I have
done some work on it and committed the current version into SVN. 

Could you have a look at

and ideally give me feedback whether it addresses your points, and/or
which parts could be further improved?

On Sun, Jul 03, 2005 at 12:35:24AM -0700, Andrew Pimlott wrote:
> I found a few things confusing when I decided to build the loop-aes
> driver.  First, the package description didn't mention that I would
> need a kernel-source package, not just kernel-headers, so I had to go
> back and install that.  You could probably also add a Recommends:
> kernel-source (or maybe Suggests:).  

I would rather not include this in the package description, because it
is already quite long as is. Your suggestion to add a Recommends is
sensible and I think expresses this requirement well, so I will likely
do this for the next upload.

> Second, I was surprised that I had to install the kernel-source
> package, but I didn't have to actually rebuild the kernel.  Perhaps
> you could clarify that in the package description and/or
> README.Debian:
> 
> Although you must have a full kernel source tree to build the
> loop-aes driver, it does not patch the kernel, so you don't need
> to rebuild.  The newly build module will load into your old
> kernel.

Using an unconfigured/uncompiled source tree will work most of the 
time, but is not actually safe or recommended. 

The loop-AES Makefile looks at a number of files in the source tree to
determine build settings, and among them are Makefile and
include/linux/autoconf.h which do not exist or do not contain correct
settings in unconfigured trees.

It is in fact strongly recommended to build the kernel one intends to
use before using it to build loop-AES. I hope this requirement is now
clearer in the new version of README.Debian. If not perhaps you see a
possible better wording?

> Third, the instructions for using make-kpkg to build loop-aes are a
> bit incomplete.  If you follow the instructions, when you run
> make-kpkg, you will get hit with a zillion questions from make
> oldconfig (or at least I did).  Perhaps best would be to get the
> .config that Debian uses, which can be copied from /boot.

This step (copying /boot/config-$KVERS) and the observation from your
other mail that --append-to-version is required would be useful to add.
But - I decided to drop this entire section about building for official
kernels using make-kpkg in favour of describing how one can use
module-assistant to the same effect. 

Overall I hope the documentation is more usable in the new version.
Suggestions how to clarify certain points, add more information or
simply express things better than my half-broken english is capable of
are of course always welcome :)

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#321948: gnupg: build a gnupg-udeb

[Max Vozeler]

Package: gnupg
Severity: wishlist

it would be very useful if there was a gnupg-udeb available for use in
debian-installer. In particular, I'd like to use gnupg-udeb to create
keyfiles as used by loop-AES block device encryption. 

The attached patch is what I've been using for my local tests. Ideally
also the patch for increased passphrase iterations from #237908 could be
applied to the udeb (though that is actually a separate wishlist bug).

Please consider building a gnupg-udeb.

cheers,
Max
--- gnupg-1.4.1/debian/control  2005-07-23 23:33:45.0 +0200
+++ gnupg-1.4.1+udeb/debian/control 2005-07-18 20:15:22.0 +0200
@@ -21,6 +21,19 @@
  GnuPG does not use any patented algorithms so it cannot be compatible
  with PGP2 because it uses IDEA (which is patented worldwide).
 
+Package: gnupg-udeb
+Section: debian-installer
+Priority: extra
+Architecture: any
+Depends: ${shlibs:Depends}
+Description: GNU privacy guard - a free PGP replacement
+ GnuPG is GNU's tool for secure communication and data storage.
+ It can be used to encrypt data and to create digital signatures.
+ It includes an advanced key management facility and is compliant
+ with the proposed OpenPGP Internet standard as described in RFC2440.
+ .
+ This is GnuPG packaged in minimal form for use in debian-installer.
+
 Package: gpgv-udeb
 Section: debian-installer
 Priority: extra
--- gnupg-1.4.1/debian/rules2005-07-23 23:33:45.0 +0200
+++ gnupg-1.4.1+udeb/debian/rules   2005-07-18 20:15:34.0 +0200
@@ -119,6 +119,20 @@
chmod -R go=rX debian/gpgv-udeb
dpkg --build debian/gpgv-udeb 
../gpgv-udeb_$(VERSION)_$(DEB_BUILD_ARCH).udeb
 
+   rm -rf debian/gnupg-udeb
+   $(install_dir) debian/gnupg-udeb/DEBIAN/ debian/gnupg-udeb/usr/bin/
+   $(install_binary) build-udeb/g10/gpg debian/gnupg-udeb/usr/bin/
+   find debian/gnupg-udeb/ -type f | xargs file | grep ELF | cut -d: -f 1 
| xargs dpkg-shlibdeps -Tdebian/gnupg-udeb.substvars
+
+   : # Don't let dpkg-gencontrol write incorrect guesses to debian/files.
+   : # Instead, register the udeb manually.
+   dpkg-gencontrol -pgnupg-udeb -Tdebian/gnupg-udeb.substvars 
-Pdebian/gnupg-udeb -isp -fdebian/files~
+   dpkg-distaddfile gnupg-udeb_$(VERSION)_$(DEB_BUILD_ARCH).udeb 
debian-installer extra
+
+   chown -R root.root debian/gnupg-udeb
+   chmod -R go=rX debian/gnupg-udeb
+   dpkg --build debian/gnupg-udeb 
../gnupg-udeb_$(VERSION)_$(DEB_BUILD_ARCH).udeb
+
 define checkdir
test -f g10/g10.c && test -f debian/rules
 endef

Bug#393363: loop-aes-utils: Common loop-AES configuration file for initramfs creators

[Max Vozeler]

Hello Peter,

On Mon, Oct 16, 2006 at 11:54:58AM +0200, Peter Colberg wrote:
> concerning full loop-AES support for yaird (and for initramfs-tools),
> I would like to discuss the idea of a common configuration file for
> loop-AES devices.

Thanks for thinking out this idea of a common configuration 
file. I think the idea has many good aspects that would help in
particular with more complex setups (LVM, raid). Unfortunately
I've been so busy that I've not managed to really sit down and
think this through until now. I hope to get to it sometime this
weekend and write a more detailed reply. 

Just a thought: I think the configuration file would be useful
in a larger context than Debian. Maybe it would be good so send
a description to the linux-crypto mailinglist[0] to see if other
distributors/users and maybe Jari have some thoughts on what they
would need in terms of features/flexibility in it or have some
other ideas regarding it. It would be great if something like it
could be adopted cross-distribution IMHO.

cheers,
Max

-- 
[0] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#378488: v5 of initramfs-tools root fs on loop integration

[Max Vozeler]

Hey Lionel,

On Sun, Nov 05, 2006 at 05:02:30PM +0100, Lionel Elie Mamane wrote:
> Was easier than anticipated, at the price of some code
> duplication.  Patch attached.

Thanks, I have applied the patch to SVN.

How do we best proceed from here? I would be happy to upload
2.12r-15 with the scripts enabled, but I'm hesitating as I'm not
sure if there will be enough time to get feedback and solve any
problems that may come up before the freeze/release though.

We could upload ASAP and try to shake out all bugs in the coming
weeks. There is still the option to disable the scripts through an
upload to t-p-u in case there are any serious problems we have
overlooked - though at the risk of breaking the setups of people
who are already using them by that time.

Alternatively, the scripts could be included now but changed to
only do anything if they have been explicitly enabled by the user.
Or we could upload to experimental now and wait until after the
release before we enable them by default in unstable.

What do you think?

cheers,
Max

--
BTW: You might want to subscribe to the pkg-loop-aes-maint list
on alioth and consider joining the project group. :-)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#378488: [Pkg-loop-aes-maint] Re: Bug#378488: v5 of initramfs-tools root fs on loop integration

[Max Vozeler]

Hey Lionel,

On Sat, Nov 11, 2006 at 04:03:59PM +0100, Lionel Elie Mamane wrote:
> Etch seems to be still planned for a December release, so uploading it
> would seem a bit risky to me. At this point in time I would upload it
> to sid just after etch release.

I have the same feeling - it's probably a bit too risky. 

> On Sat, Nov 11, 2006 at 01:57:14PM +0100, Max Vozeler wrote:
> > Alternatively, the scripts could be included now but changed to only
> > do anything if they have been explicitly enabled by the user.
> 
> Yes, that would be adequate, too. And would avoid having to manage two
> branches until etch is released. Seems like the best solution.

Indeed, that's one nice advantage I didn't think about yet. Let's go
for this approach. I'll have some time later tonight where I could
check which changes are required for the scripts and documentation
.. unless you are faster or tell me to wait. :-)

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#378488: [Pkg-loop-aes-maint] Re: Bug#378488: v5 of initramfs-tools root fs on loop integration

[Max Vozeler]

Hey all,

On Sat, Nov 11, 2006 at 05:39:56PM +0100, Max Vozeler wrote:
> Indeed, that's one nice advantage I didn't think about yet. Let's go
> for this approach. I'll have some time later tonight where I could
> check which changes are required for the scripts and documentation

This was rather straight forward. I've commited the attached patch
to SVN.. does it look OK to you?

cheers,
Max
Index: debian/changelog
===
--- debian/changelog(Revision 1320)
+++ debian/changelog(Arbeitskopie)
@@ -1,11 +1,11 @@
 loop-aes-utils (2.12r-15) UNRELEASED; urgency=low
 
   * Set Maintainer to Debian Loop-AES Team
-  * Enable initramfs-tools integration for encrypted root, thanks to
+  * Include initramfs-tools integration for encrypted root, thanks to
 Lionel Elie Mamane <[EMAIL PROTECTED]> (Closes: #378488)
   * Update config.sub to 2006-09-20
 
- -- Max Vozeler <[EMAIL PROTECTED]>  Sun, 22 Oct 2006 19:01:50 +0200
+ -- Max Vozeler <[EMAIL PROTECTED]>  Sat, 11 Nov 2006 14:31:16 +0100
 
 loop-aes-utils (2.12r-14) unstable; urgency=low
 
Index: debian/initramfs-tools-hook
===
--- debian/initramfs-tools-hook (Revision 1320)
+++ debian/initramfs-tools-hook (Arbeitskopie)
@@ -24,10 +24,15 @@
 1|yes|on)
FORCE_LOOPAES=1
;;
-auto|)
+auto)
;;
+'')
+   # Default not doing anything
+   exit 0
+   ;;
 *)
echo "WARNING! (loop-aes) ignoring invalid INITRAMFS_LOOPAES value: 
'${INITRAMFS_LOOPAES}'" 1>&2
+   ;;
 esac
 
 . /usr/share/initramfs-tools/hook-functions
Index: debian/NEWS.Debian
===
--- debian/NEWS.Debian  (Revision 1320)
+++ debian/NEWS.Debian  (Arbeitskopie)
@@ -1,11 +1,8 @@
 loop-aes-utils (2.12r-15) unstable; urgency=low
 
   * This version includes support for root on loop-aes encrypted
-device when using an initramfs-tools generated initramfs.
-
-If you had a working loop-aes encrypted root and you are using
-initramfs-tools, this support may interfere and cause initramfs-tools
-to produce an initramfs that will not boot your system. See
+device when using an initramfs-tools generated initramfs. The
+support is not enabled by default. See
 /usr/share/doc/loop-aes-utils/README.Debian.gz for details.
 
  -- Lionel Elie Mamane <[EMAIL PROTECTED]>  Sun,  6 Aug 2006 15:20:24 +0200
Index: debian/README
===
--- debian/README   (Revision 1320)
+++ debian/README   (Arbeitskopie)
@@ -31,13 +31,14 @@
   encrypted (or not) loop device. This needs initramfs-tools version
   0.81 or later.
 
-  This support is automatically enabled at initramfs creation time
-  when your root device in /etc/fstab has a "loop=/dev/loopN"
-  option. You can also force it on by setting the environmental
-  variable INITRAMFS_LOOPAES to "1", "yes" or "on"; you can force it
-  off by setting INITRAMFS_LOOPAES to "0", "no" or
-  "off". INITRAMFS_LOOPAES can be set in the shell calling mkinitramfs
-  or in /etc/initramfs-tools/initramfs.conf .
+  This support is not automatically enabled by default.
+  
+  You can activate the support by setting INITRAMFS_LOOPAES in
+  /etc/initramfs-tools/initramfs.conf or in the shell calling
+  mkinitramfs to "auto" or "yes". The recommended setting is "auto".
+  It checks at initramfs creation time if your root device in
+  /etc/fstab has a "loop=/dev/loopN" option. You can also forcibly
+  activate the support with "yes" or force it off with "no".
 
   When support is forced on, support for all ciphers is included; when
   automatically enabled, only the necessary cipher module is included
Index: debian/initramfs-tools-conf
===
--- debian/initramfs-tools-conf (Revision 1320)
+++ debian/initramfs-tools-conf (Arbeitskopie)
@@ -1,3 +1,5 @@
+# This script is sourced by initramfs-tools; It should not exit
+
 get_rootoptions() {
 [ -r /etc/fstab ] || return
 
@@ -18,8 +20,12 @@
;;
1|yes|on)
;;
-   auto|)
+   auto)
;;
+   '')
+   # Default to not doing anything
+   return 1
+   ;;
*)
echo "WARNING! (loop-aes) ignoring invalid INITRAMFS_LOOPAES value: 
'${INITRAMFS_LOOPAES}'" 1>&2
 esac

Bug#398222: man pages don't match names of diverted binaries

[Max Vozeler]

Package: loop-aes-utils
Version: 2.12r-14
Severity: important

$ ls /bin/mount*
/bin/mount /bin/mount.orig
$ man mount.orig
No manual entry for mount.orig
$ man mount-orig
Reformatting mount-orig(8), please wait...

The man pages should be renamed so that they match the names of the
diverted binaries.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#400055: loop-aes-modules: FTBFS: build-dep on removed package loop-aes-source

[Max Vozeler]

tags 400055 + confirmed pending
thanks

On Thu, Nov 23, 2006 at 06:09:24PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in etch, I discovered that your
> package failed to build on i386.
> 
> Your package depends on loop-aes-source (>= 3.1d-3), but this package
> was removed from Debian.

Confirmed. I'm not sure why loop-aes-source was already removed,
but it doesn't matter too much anymore: loop-aes-modules has been
obsoleted by the source package loop-aes and will be removed from
the archive as soon as d-i RC2 comes out. It currently remains in
the archive only to keep d-i RC1 crypto installs working.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#298113: module-assistant: fakesource and Module.symvers for versioned symbols

[Max Vozeler]

Package: module-assistant
Version: 0.7.5
Severity: wishlist
Tags: patch

Hi blade,

inserting a module built against a "fakesource" tree taints the kernel
here, because the __versions section is empty and so the symbol version
for struct_module is not available.

This could be remedied by copying the Module.symvers file included in
kernel-headers to the fakesource tree. Makefile.modpost will use it if
available to look up the correct versions for the symbols used.

I've been doing this for some time manually with the loop-AES binary
module packages and think it would make sense for m-a. Find attached
a small patch to this effect.

cheers,
Max

--- module-assistant.orig   2005-03-02 18:45:44.553183376 +0100
+++ module-assistant2005-03-02 18:46:18.559013704 +0100
@@ -850,6 +850,7 @@
$knmbr=~s/^([\d\.]+)(.*)/$1/;
my $extra=$2;
my $confile="/boot/config-$kvers";
+   my $symverfile="$usrc/$kheaders-$kvers/Module.symvers";
print "Experimental kernel source recreating method...\nGetting 
source...\n";
return 0 if withecho "apt-get install $ksource-$knmbr";
if(! -f $confile) {
@@ -865,6 +866,9 @@
print "Installing to final location and configuring, please wait...\n";
withecho "mv", "$tmpdir/$ksource-$knmbr", "$usrc/$ksource-$kvers";
withecho "cp", $confile, "$usrc/$ksource-$kvers/.config";
+   if (-f $symverfile) {
+  withecho "cp", $symverfile, "$usrc/$ksource-$kvers/Module.symvers";
+   }
rmdir $tmpdir;
if($extra) {
   open(mk,"<$usrc/$ksource-$kvers/Makefile");

Bug#295876: fails to umount a user mounted device as user

[Max Vozeler]

Hi Stefan,

"Stefan-W. Hahn" <[EMAIL PROTECTED]> wrote:
> Also sprach Max Vozeler am Tue, 22 Feb 2005 at 20:30:48 +0100:
> Hello Max,
> 
> > I'm wondering BTW why this works as expected when you remove
> > loop-aes-utils. Here the original mount 2.12 behaves the same way
> > and refuses user umount when mtab is a symlink to /proc/mounts.

> Now I tried with:
> mount   2.12-10 testing
> 
> And there it does not work with a symlinked /etc/mtab !!

Ah, Thanks for following up on this!

> Now, is it a feature or a bug. BTS for mount haven't told me.
> Perhaps you can make a suggestion how to go on with it.

I would say it's a known limitation. 

There have been attempts to get the relevant options included in
/proc/mounts so that it could fully replace mtab, but it seems kernel
hackers are/were not happy with the proposed solutions.

The problems with /proc/mounts are documented in mount(8), although 
not in the version from loop-aes-utils. (I'm investigating why)

| It  is  possible  to  replace /etc/mtab  by  a symbolic link to
| /proc/mounts, [...] but some information is lost that way, and in
| particular working with the loop device will be less convenient, and
| using the  "user" option will fail.

So, for now, it's recommended to not use the /proc/mounst symlink with
loopbacks or the "user" option - at least until someone comes up with a
good patch for Linux upstream. 

cheers,
Max

-- 
308E81E7B97963BCA0E6ED889D5BD511B7CDA2DC


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#413422: RM: loop-aes-modules -- RoM; superseded by loop-aes

[Max Vozeler]

Package: ftp.debian.org

Please remove loop-aes-modules from the archive. It has been
superseded by other packages (loop-aes and linux-modules-di-*)
and as such is no longer useful.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403974: Unofficial kernels and debian packages...

[Max Vozeler]

severity 403974 important
thanks

On Sun, Feb 18, 2007 at 09:39:54PM +0100, Thomas Weinbrenner wrote:
> James Westby wrote:
> > On (17/02/07 19:51), Thomas Weinbrenner wrote:
> 
> [...]
> > > But if it is meant to help building modules for other kernel, then it
> > > should support them and this bug should be more severe than merely
> > > "wishlist".
> 
> [...]
> > The fact that you can't build from the loop-aes-source against newer
> > kernels is regrettable, but does not warrant a bug of severity serious
> > I'm afraid.
> 
> All right, but shouldn't it be at least "normal" (if not "important",
> after all, if you build your own kernel, you usually want the newest)?
> 
> A "minor" severity level would be a "a problem which doesn't affect the
> package's usefulness" and since this affects the packages usefulness it
> should be more severe than that.

Agreed.

I plan to build build loop-aes v3.1e + patches this coming 
weekend and upload it to experimental. Jari has already hinted at 
a new upstream release, and there are some patches for newer kernel
releases. I think it will be useful to maintain newer versions in
experimental this way for some time, at least until the time 
unstable is open for post-etch uploads again. 

The main reason the package hasn't been updated to the latest
upstream version (from my perspective) is that loop-aes is now used
in partman-crypto as part of debian-installer; updating it would 
have meant more work and possible delays for d-i RC1 and RC2. Now 
that we're basically in freeze preparing for release of etch, (barring
any unforseen troubles) etch will likely stay at and release with
loop-aes version v3.1d. I hope that we can maintain a version in
backports.org for use with newer kernels though.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#414309: cannot configure encrypted volume if stray swap exists

[Max Vozeler]

reassign 414309 partman-crypto
thanks

Hi Stephen,

Thanks for your bug report.

On Sat, Mar 10, 2007 at 03:03:20PM -0500, Stephen Gildea wrote:
> In the "Partition disks" step, using the "Manual" partitioning method,
> I cannot configure encrypted volumes.
> 
> I create a partition, for use as a physical volume for encryption.
> When I try to "Configure encrypted volumes", I get the error screen
> "Unsafe swap space detected" and cannot proceed.
> 
> The error screen suggests running swapoff.  I press Alt-F2 RET and
> type "swapoff -a" to the shell there; it does not help.  (But it
> should, yes?  Is this another bug?)

Sounds like another bug. The normal swapoff in util-linux looks at
/proc/swaps when called with -a and deconfigures all swap devices
listed therein. I'll need to check what busybox swapoff does.

> It also works to, in the partitioner, edit the swap partition on the
> other disk and set its "Use as" field to "do not use".  It took me a
> while to figure this out, and I feel this step should not be
> necessary.

I don't think we can skip this step if we still want to
automatically configure existing swap partitions on the system,
but I agree that it should be easier to handle.

What we could try: Find out how much normal memory is available
and whether the system really needs the swap space, then, if 
possible, offer to deconfigure the swap partitions automatically.
This change is too big to happen before etch is released, but 
definitely something I'll look at afterwards.

If the above should turn out to be impossible or too much work,
I'll try to improve the error template to mention that one can set
the "Use as" field rather than switch to a different VT and use 
swapoff to deconfigure it manually. (This is post-etch as well)

> If I select "Guided partitioning" and ask for "Guided - encrypted
> LVM", it works fine.  Somehow this method gets rid of the unwanted
> swap device.

I would guess that this is because guided partitioning doesn't
try to automatically setup existing swap partitions, but I'm not 
sure about that.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#302324: initrd-tools: Misleading error message for files in /lib/modules/$KVERS/kernel that have non-.o/.ko suffix

[Max Vozeler]

reassign 302324 initrd-tools
retitle 302324 Misleading error message for files in /lib/modules/$KVERS/kernel 
that have non-.o/.ko suffix
severity 302324 minor
thanks

This bug included a number of different issues. Summarizing the
relevant point for initrd-tools:

If an admin or package creates a file in /lib/modules/$KVERS/kernel
that doesn't end in .o or .ko - like some kernel module packages do
by diverting a module to e.g. foo.ko.orig when they provide a newer
versions of some module that is also included in the kernel package 
itself - mkinitrd outputs a grave error message:

  Setting up kernel-image-2.6.10-nb (01) ...
  /usr/sbin/mkinitrd: add_modules_dep_2_5: modprobe failed
  FATAL: Module loop.ko_orig not found.
  WARNING: This failure MAY indicate that your kernel will not boot!
  but it can also be triggered by needed modules being compiled into
  the kernel.

The resulting initrd works without problems and the stray file IMHO
doesn't justify an error message of that severity. Instead of warning
about the file, mkinitrd could ignore anything not named .o or .ko 
when looking for kernel modules. [I realize initrd-tools is kept alive
in low-maintenance mode mostly (only?) for sarge -> etch upgrade
support, but I wanted to process this old bug report.]

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#408786: please add armel support

[Max Vozeler]

Hey Riku,

On Sun, Jan 28, 2007 at 02:52:19PM +0200, Riku Voipio wrote:
> Package: loop-aes-modules
> Severity: wishlist
> Tags: patch
> User: debian-arm@lists.debian.org
> Usertags: eabi
> 
> Please add support for arm eabi[1] and bigendian ports. In this packages
> case it only needs adding "armel" and "armeb" to Architecture: line.

Thanks for your patch. Unfortunately loop-aes-modules is already
scheduled for removal right after the release of d-i RC2, so I 
don't expect there will be any more uploads.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#419334: RFA: cdtool -- text-based audio CD player and CD-ROM control commands

[Max Vozeler]

Package: wnpp

I find that I don't actually play audio CDs much anymore and I now
have only occasional access to a machine that cdtool works on (one 
that can play audio CDs without DAE), so I'm sure there is someone 
out there who can do a better job maintaining it :-)

It would be ideal if whoever adopts could also take over as cdtool
upstream maintainer. The code is relatively small and simple and 
usually not much work. There was a proposal to port cdtool to libcdio
which is probably a good idea - it could make cdtool work for the
increasing number of systems that can only do DAE. 

If you are interested in adopting it, let me know. I'm happy to
answer questions, provide an SVN dump, etc.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#382523: Please add option +/- to cdvolume

[Max Vozeler]

Hi Michelle,

Am 2006-07-10 18:59:22, schrieb Michelle Konzack:
> cdvolume works curently if the parameter is an integer of 0 to 255.
> 
> Please add the option +/- to the parameter to let $USER increase or
> decrease the volume like
> 
> cdvolume -10
> cdvolume +5
> ...
> 
> But since the options -0 to -9 already exist, what about the prefix
> d(decrease) and i(ncrease) like
> 
> cdvolume d10
> cdvolume i5
> 
> This can then be used on "very light desktops" with multimedia
> keyboards without the need of heavy X tools.
> 
> Currently I use a wraper, which invokes "cam" but its not a real
> solution since it must store the current value in a file.

I think this would be a good feature. Perhaps using 
"cdvolume increase/decrease " and "cdvolume decrease "
instead of the new prefix. 

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#382524: cdctrl does not more work under sarge

[Max Vozeler]

Hi Michelle,

Am 2006-07-10 19:16:20, schrieb Michelle Konzack:
> I am using ATA and SCSI Cd-Drives which are /dev/hdc or /dev/scd0.
> 
> Now if I try 'cdctrl e' it access the drive and nothing happen.
> I must use ^C to interupt the operation, because other programs
> like "eject" can not access the CD-Drive.

I'm not sure I understand your bug report correctly.

The strace shows that it tried to open a device called "e"
in the current directory, because the first command line
argument is intepreted as path to the device. This failed,
and then cdctrl seems to have exited normally.

Is the problem that cdctrl keeps the device open if you
use it like "cdctrl /dev/cdrom" and that this prevents 
other programs from accessing the device? This could be,
because IIRC that behaviour changed some versions back.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#250471: still missing eth1 on Sparc64

[Max Vozeler]

Hi Geert,

On Wed, May 26, 2004 at 11:23:11AM +0200, Geert Stappers wrote:
> On Sun, May 23, 2004 at 12:29:57PM +0200, Geert Stappers wrote:
> > On Sun, May 23, 2004 at 09:36:52AM +0200, Geert Stappers wrote:
> > > At boot there is a message like "hardware detect", I assume it is in
> > >  /etc/init.d/
> > > But here neither detection of the second NIC.
> > 
> > The exact message at boot:
> > 
> > Discovering hardware:
> > Running 0dns-down to make sure resolv.conf is ok...done.
> > Cleaning: /etc/network/ifstate.
> > Starting hotplug subsystem:
> >input
> >  [failed]   net
> >pci
> > ** can't synthesize pci hotplug events
> >  [failed]   usb
> > ** can't synthesize root hub events
> > done
> > 
> After a install with the daily build of 2004-05-26
> I got the same messages as above.
> 
> Not having eth1 is not good.

Can you confirm whether eth1 is now detected correctly? If not,
I think it might be good to reassign to the kernel so it can be
added to modules.pcimap.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#256067: Installation failure

[Max Vozeler]

retitle 256067 [i386][20040624] aic7xxx and 3C905C-tx problems
tags 256067 + moreinfo
thanks

Hello Michael Satterwhite,

On Thu, Jun 24, 2004 at 03:11:51PM -0500, Michael Satterwhite wrote:
> Debian-installer-version: <06/24/2004  Sid Installation 386 / Current >
> uname -a: 
> Date: <6/24/2004  15:00>
> Method: 
> 
> Machine: 
> Processor: Pentium III
> Memory: 256 Mb

I'm trying to process old installation reports and would like to
ask a couple of questions about this report you filed in 2004.
You reported two problems:

 1) 3Com 3C905C-tx not working.
 2) aic7xxx module failing to load

If you still have access to this system, can you please send us
information about whether the NIC and SCSI controller work with 
another distribution / newer version of Debian, and if so, which
kernel version and modules they work with?

Important information would be:
 - Output of uname -a 
 - Output of lsmod
 - Output of lspci and lspci -n 

Please also let us know in case the system is no longer in use.
Thanks.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#270936: marked as done ([ia64][20040901][netinst] various issues)

[Max Vozeler]

On Mon, Aug 28, 2006 at 06:03:31AM -0700, Debian Bug Tracking System wrote:
> > > * Incorrect default keymap:
> > > 
> > > Selected "English"
> > > Selected "United States"
> > > Default keymap is "European"; should be "American English"
> 
> The default is now "en_US.UTF-8".

Err, this is of course nonsense. :-)

The default _keymap_ is now "American English"

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#383129: ITA: pgpdump -- PGP packet visualizer

[Max Vozeler]

owner 383129 !
retitle 383129 ITA: pgpdump -- PGP packet visualizer
thanks

I've found pgpdump useful and plan to take care of it.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#383129: ITA: pgpdump -- PGP packet visualizer

[Max Vozeler]

owner 383129 Jose Luis Rivas <[EMAIL PROTECTED]>
thanks

Jose told me that he has already done work on a new upload and
would like to be the maintainer. 

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#385437: RFH: loop-aes

[Max Vozeler]

Package: wnpp
Severity: normal

Hi all,

I'm starting a new fulltime job, which will leave me with less
time to work on these packages (at least initially).

The loop-AES packages (-source, -utils, -modules) usually 
don't require large amounts of attention, but there are a few
decisions about big changes in the packaging that I'd like to
discuss and scrutinize together with a co-developer. The modules
and -utils are used in d-i (as part of partman-crypto) and
sometimes need work to do timely updates to a newer kernel
version. Integration with linux-modules-extra-2.6 is another
topic and I'm sure there are many other improvements possible.
Plus, I think it's always good to have another brain and 
pair of eyes for peer review.  :-)

Anyways, please get in touch with me if you are interested in
co-maintaining any or all of them.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#385446: PTS: handling of udebs could be improved

[Max Vozeler]

Package: qa.debian.org

Looking at packages.qa.debian.org/partman-crypto, there are two
points specific to udebs that could be improved. They would make
the page more useful (and correct) for udeb-only packages:

1. TODO and Problems warn about outdated Standards-Version. The
current practice for udeb-only packages is to not include a
Standards-Version header and to add a lintian source override for
no-standards-version-field.

2. Testing Status mentions that "partman-crypto has no binaries 
on any arch", which is not correct. It actually has one arch: any 
package and two with arch: all.

Thanks,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#389740: aespipe pads data

[Max Vozeler]

Hi Marc,

On Wed, Sep 27, 2006 at 02:50:13PM +0200, Marc Lehmann wrote:
> aespipe pads data to the cipher blocksize on encryption. as aespipe has no
> container format there is no way this cna be avoided, but many programs
> barf on the extra data appended (and give ghastly error messages), so this
> should be mentioned in the manpage.

Thanks for your bug report. I think this is in fact already
mentioned in the man page:

| If input size is not
| multiple of 16 or 512 bytes, input data is padded with null bytes so
| that both input and output sizes are multiples of 16 or 512 bytes.

If you can think of a wording that makes it more clear
(which I cannot right now), I'd be happy to apply a patch and
forward it to aespipe upstream.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#390554: loop-aes - FTBFS: /usr/src/linux-headers-2.6.17-2-s390-tape: No such file or directory. Stop.

[Max Vozeler]

tags 390554 + pending
thanks

On Sun, Oct 01, 2006 at 09:21:13PM +0200, Bastian Blank wrote:
> > /usr/bin/make -C /usr/src/linux-headers-2.6.17-2-s390-tape 
> > M=/build/buildd/loop-aes-3.1d/debian/build/build_s390_none_s390-tape 
> > make: Entering an unknown directory
> > make: *** /usr/src/linux-headers-2.6.17-2-s390-tape: No such file or 
> > directory.  Stop.

We've inherited this problem from linux-support-2.6.17-2. I've 
commited a fix to the local copy of gencontrol.py which will be
included in the next upload.

cheers,
Max

-- 
< _Max> waldi: could you help me understand s390-tape? should modules 1) not 
build for/against s390-tape or 2) build for s390-tape but against s390 headers?
< waldi> should not build
< _Max> waldi: ok, thanks
< _Max> it seems gencontrol.py in linux-support could be made aware of this, or 
there some other mechanism I could use?
< waldi> hmm, it should do that
< _Max> the one in 2.6.18-1 generated entries for s390-tape, iirc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#381891: Mountpoint and other options lost when partman restarts

[Max Vozeler]

On Mon, Aug 07, 2006 at 06:02:06PM +0200, Max Vozeler wrote:
> Mountpoints and other options for encrypted volumes are not
> remembered when partman restarts. For example: Setting up an
> encryption volume, setting the mountpoint and afterwards
> configuring LVM makes the mountpoint get lost.

Some results:

init.d/parted (partman-base) moves /var/lib/partman/devices to
/var/lib/partman/old_devices and then restores directories for
all devices returned by parted_devices, which includes dm-crypt
devices but doesn't include loops. As consequence loops are not
restored and lose their configured options.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#384532: partman-crypto: implement on-demand loading

[Max Vozeler]

Hey David,

thanks for working on this.
Just a quick comment, as I leave for the weekend in 10 mins:

On Fri, Aug 25, 2006 at 12:04:24AM +0200, David Härdeman wrote:
> Index: debian/control
> ===
> --- debian/control(revision 40192)
> +++ debian/control(working copy)
> @@ -8,17 +8,18 @@
>  Package: partman-crypto
>  XC-Package-Type: udeb
>  Architecture: any
> -Depends: partman-base (>= 87), partman-crypto-dm, partman-crypto-loop, 
> cdebconf-newt-entropy (>= 0.3), ${shlibs:Depends}, ${misc:Depends}
> +Priority: standard
> +Depends: partman-base (>= 87), ${shlibs:Depends}, ${misc:Depends}
>  Description: Add to partman support for block device encryption
>  
>  Package: partman-crypto-dm
>  XC-Package-Type: udeb
>  Architecture: all
> -Depends: partman-crypto, crypto-modules, cryptsetup-udeb
> +Depends: partman-crypto, crypto-modules, cryptsetup-udeb, 
> cdebconf-newt-entropy (>= 0.3)
>  Description: Add to partman support for dm-crypt encryption

To prevent -dm and -loop from being included automatically, I
think we'll need to change their Priority to optional.

Looks good to me apart from that -- in an early morning hurried
reading. I hope to take a closer look on Sat/Sun, however feel
free to commit already.

cheers,
Max

Bug#385629: debian-installer: Encrypted filesystem setup and swap

[Max Vozeler]

clone 385629 -1
retitle -1 Swap check fails for swap-on-LVM-on-crypto
thanks

Hi James,

On Mon, Oct 09, 2006 at 11:59:55PM +0100, James Westby wrote:
> I am playing around with the installer and I believe I have hit this
> problem.
> 
> If I select automatically set up LVM and crypto I get a good setup,
> but if I then go to Configure encrypted partitions I am told I can't
> as swap is not encrypted.
> 
> The swap is an LVM partition on a dm-crypt device, so I think
> partman-crypto's detection of encrypted swap in this case is not
> working. 

Ah, good catch. Our swap check takes the swap device and checks if it's
an encrypted loop (using losetup) or dm device (dmsetup). In case of
swap-on-LVM-on-crypto, the check only sees swap-on-LVM and so concludes
that the setup is unsafe.

> [Also it seems that I cannot delete an encrypted partition, even if I
> get to free space on it, it still says "In use for ...", is there a way
> to do this? It was annoying having to restart the installer every time I
> wanted to try something different. Could you point me to the apprpriate
> package for this, I'm not sure it is partman-crypto]

Deleting encrypted partitions has not been implemented. The relevant
package is partman-crypto.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#391664: partman-auto-crypto: Some questions and issues

[Max Vozeler]

Hi all,

On Tue, Oct 10, 2006 at 01:51:34AM +0200, David Härdeman wrote:
> The loop is there because it needs to look not for the $dev device but 
> the virtual device-mapper device which has been created ontop of the 
> device pointed to by $dev after the crypto_setup step. It should be a 
> bit smarter and make sure the virtual-$dev <-> $dev mapping is correct 
> thoughand it should probably exit the loop once that is 
> established...but I don't think the loop can be removed...

Just a quick thought before I rush to work: Couldn't we use the
$part/crypt_active file after crypto_setup?

  part=$(dev_to_devdir $dev)
  [ -f $part/crypt_active) ] || problem
  cryptdev=$(cat $part/crypt_active)
  cryptdevdir=$(dev_to_devdir $cryptdev)

cheers,
Max

Bug#381875: loop-AES key generation requires tiresome typing

[Max Vozeler]

Hi James,

On Tue, Oct 10, 2006 at 08:39:07PM +0100, James Westby wrote:
> 1) Make a game that involves typing,
> 
> I was reminded of a game called Daley Thompson's Decathlon, which
> involved bashng two keys in turn as quickly as possible, while this
> wouldn't be good I thought some sort of game might be. Bear with mw
> while I outline an idea,
> 
>   Implement tetris (hmm, I'm not really volunteering for this bit.)
>   then the user is making key presses, and is more happy to spend the
>   time. The progress bar could be inverted to count down, then it is
>   score as many points as possible before it runs out.
> 
> Yeah it's probably not workable, but I thought it was quite fun anyway.

I like the idea a lot. In fact, this was my first approach before
cdebconf-entropy. :-)

I actually started to implement "EntroPong" (classic pong) in newt; I
should still have the sources somewhere. I got a bit discouraged because
it turned out that the amount of entropy contributed to the kernel pool
was very low. IIRC (should check) what contributes entropy are the
inter-keypress timings, not the actual keys pressed, so the concept of
Decathlon you describe could in fact be very suitable.

> 2) Use a source of entropy on another machine.
> 
> There are sites (I forget the name, you probably know them), that
> provide entropy across the Internet. While I'm not that sure of the
> idea, it would solve the problem some what.

I think there are two implications to this: First, we would need to
trust the provider of the random data to never look at it and/or clear
all records of it after transmission. If you had a particular "randomn-
ness provider" you trust, this could be feasible. Except that we'd
transfer the random bits over the network, where anyone could look at
them. My understanding is that mixing in such a source cannot hurt the
resulting random output, but overall I think such input would not
actually help us for encryption key generation.

> 3) Allow randomness/key to be retrieved from elsewhere.
> 
> Similar to preseeding, either grab a file of a disk or server that has
> entropy or the keys. Obviously it needs to be done right, but I think
> this should perhaps be done anyway to help with multiple installs. You
> can have the file in any format you like (cat /dev/random > file or
> actually create GPG encrypted keys), and provide a script to create one
> on a running machine.

This seems like the most practical solution. I suppose it 
would be easiest to just generate complete GPG keys on another machine;
That would save us from having to worry about secure transport of the
random data. There is a small script loop-aes-keygen(1) in package
loop-aes-utils which can be used to create GPG-wrapped encryption keys
on another system. They could be stored on some removable medium 
and get loaded by partman-crypto.

> 4) Make d-i harder to use.
> 
> If entropy is gathered during the install, it should be made harder, so
> that more key presses are required before partman-crypto is reached, and
> so increasing the entropy in the pool without the user realising it is
> for encryption.

:-)

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#392285: partman-crypto: Fails to cause cryptomount to be loaded

[Max Vozeler]

tags 392285 + confirmed pending
thanks

Hi James,

On Tue, Oct 10, 2006 at 07:40:18PM +0100, James Westby wrote:
> I had the first partition for / unencrypted, then two partitions, a
> random key for swap, and a GPG encrypted key for /home. I used
> twofish128 for minimum impact while testing. The install went
> fine, until I rebooted.

> I was asked for my passphrase, and when I entered it I was told /home
> couldn't be mounted. The following message accompanied it.

>   LOOP_SET_STATUS: Invalid argument, requested cipher or key length (128
>   bits) not supported by kernel.

> I googled the error, and found a message written by Max indicating that
> another module was needed. I modprobed cryptoloop, and it changed the
> error message. So it seems like some magic chould be done to load this
> module at boot time.

That's only partially correct. :-)

The above error is shown if the LOOP_SET_STATUS/64 ioctl failed for
the chosen combination of cipher/keysize. In this case, it indicates
that the kernel had no support for loopback crypto as neither the
cryptoloop nor a loop-AES module was loaded. As shown by the second
error you quoted below, however, the newer crypto modes of loop-AES 
are not supported by the old cryptoloop module, so it can not be 
used as a replacement for the loop-AES module.

> After adding cryptoloop I get the error message

>   LOOP_MULTI_KEY_SETUP_V3: Invalid argument

> #318944 suggests this is because a v3 key was used with a v2 module, but
> I have a v3 module installed. 

Yes, this indeed used to be a frequent cause for similar errors.
In this case though, I think the reason is likely to be that the
cryptoloop module doesn't know about multi-key modes and therefor
doesn't handle this particular ioctl. 

> Apologies if I am doing something stupid here, please punish me if I am.

> Also I don't know what version I am supposed to put for these, but I am
> using the daily image downloaded 8th October, and installed the day
> after. I have loop-aes-2.6.16-2-686 3.1d+3+3 installed by the installer.
 ^^

I strongly suspect that this is the problem. The default kernel
currently installed by daily builds is 2.6.17-2, but loop-aes-* is
only available in testing for 2.6.16-2. The installer likely tried
to install the meta package loop-aes-2.6-686 and so ended up with
the old modules package. If you still have the VM, you should be 
able to verify by installing loop-aes-2.6.17-2-686 from unstable.

 So I have just completed a test install and can 
confirm that this is indeed reproducible and can be fixed by
installing the package loop-aes-2.6.17-2-686. The problem will
exist until we manage to migrate loop-aes modules for 2.6.17-2 to
testing (hopefully soon), or until the 2.6.18 kernel becomes the
default kernel in testing along with new loop-AES modules.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#381677: initramfs-tools: Temporary files and initramfs world-readable

[Max Vozeler]

Hi all,

On Tue, 12 Sep 2006 16:33:07 +0200, Lionel Elie Mamane wrote:
> > what you want is a conf dir for build specific package specific
> > settings.
> 
> Actually, if we look at the details, I'm not sure the loopaes-utils
> package should unconditionally set the umask of initramfs-tools, as
> a significant portion of the users may have the package installed,
> but not an encrypted _root_ filesystem. So in the best case, we would
> want the loopaes hooks to be able to decide whether they touch the
> umask or not at runtime (runtime = building the initramfs), but this
> seems difficult at best. So, I suppose that the next best thing would
> be to give the _administrator_ a way to change the umask. But that's
> up to the maintainer of loopaes-utils, naturally.

The hook could still abort if it detects an encrypted root 
filesystem with a too permissive setting of UMASK, no? If it
can do that, I think relying on the admin to configure it
appropriately before it'll work would be reasonable.

A configuration directory like the mkinitramfs.d maks described
would still be very useful for setting up encrypted root on 
loop-AES from inside d-i (partman-crypto) though, as we will
need to take care of configuration there and set UMASK=077 
before the first initrd gets created.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#387897: Installation report

[Max Vozeler]

Hi Timo,

On Sun, Sep 17, 2006 at 12:44:04PM +0300, Timo Myyrä wrote:
> I had troubles with the crypting my harddrive. It just said that error 
> happened. I could choose the encryption and all but when I was supposed
> to write them to disk it started complaing about error. This happened after 
> it asked the passphrase. Also, I couldn't create LVM-partitions on the 
> encrypted partition.
> I tried both, dm-crypt and the loop-AES. Unfortunately I don't have the 
> logs anymore. I checked the partman log when trying encryption and it said 
> something like following: 
> "/lib/partman/choose_partitions/35crypto/do_option: cryptsetup failed"
> Encryption seemed to work the first time when I wiped the partition and 
> tested it but I couldn't make the partitioning I wanted so I exited the 
> installer and booted to retry
> but it wouldn't work anymore.

Do you remember if one or more of the partitions were 
configured to use a random key ?

I'm asking because there is a known problem with using random 
key encryption in the GUI installer. This affects both normal
loop-AES partitions with "keyfile" key and dm-crypt partitions
with "random" key. Those cannot be setup using the GUI installer
because a component required for those configurations is not
available for the gtk frontend.

On the other hand, you said it showed a normal error dialog, so
maybe this was actually caused by something different. If the
problem was indeed the missing component, it should have shown an
error dialog saying "tools missing for encryption", instead of
simple "an error occured".

I will try to reproduce this problem. David, maybe you have an
idea what might have gone wrong?

cheers,
Max

Bug#378488: Directions for Creating an Encrytped Root Debian System

[Max Vozeler]

Hi Russell,

many thanks for your document. I will try to have a detailed reading 
and integrate it along with the scripts.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#389014: [Priorities] partman-crypto-{dm,loop} should be 'optional' not 'standard'

[Max Vozeler]

Package: ftp.debian.org
Patch: d-i

Hi ftp-masters,

debian-installer currently loads udebs partman-crypto-loop and
partman-crypto-dm by default.

We have lowered their priority to optional in recent uploads so
that they can be loaded on demand. This will help us to decrease
the overall memory requirements of the installer. 

Please change their priorities in the overrides file.

cheers,
Max


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]