Re: Upcoming transition: libcryptsetup4 -> libcryptsetup12

[Jonas Meurer]

Am 17.12.2017 um 13:32 schrieb Cyril Brulebois:
>> How shall we proceed? The package is ready to be uploaded. Shall we go
>> ahead? Will you (the Release Managers) trigger the binary rebuilds
>> afterwards? Or can/shall we do this ourselves?
> 
> You would usually request a transition slot through a bug report against
> release.debian.org (pick 'transition'), and coordinate uploads & binNMUs
> with the release team.

This is done now: #884618

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Upcoming transition: libcryptsetup4 -> libcryptsetup12

[Jonas Meurer]

Hi there,

the upcoming upload of cryptsetup 2.0.0-1 will bump the libcryptsetup
soname from 4 to 12. According to (the very thoughtful) upstream, the
API (old functions) is backwards-compatible, so simple rebuilds of the
reverse depenencies should be enough.

Here's a list of reverse depends:

bruteforce-luks
cryptmount
libpam-mount
luksmeta
systemd
volume-key
libblockdev
zulucrypt

Debian-boot is Cc'ed as cryptsetup provides udebs, so debian-installer
is affected as well.

How shall we proceed? The package is ready to be uploaded. Shall we go
ahead? Will you (the Release Managers) trigger the binary rebuilds
afterwards? Or can/shall we do this ourselves?

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Fw: wow that was amazing

[Jonas Meurer]

Hello friend, 

I've had  an incredible weekend with my relatives  and  buddies, therefore i 
just wanted to reveal  this great stories together with you, just  take a  peek 
 
http://www.haciendahomestyle.com/limit.php?UE9idXN5Ym94QHBhY2thZ2VzLmRlYmlhbi5vcmc-

Jonas Meurer


-

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of US. If you are not the intended recipient of this email, you 
must neither take any action based upon its contents, nor copy or show it to 
anyone. Please contact the sender if you believe you have received this email 
in error.

Re: [pkg-cryptsetup-devel] Bug#783297: breaks initramfs if BUSYBOX=n

[Jonas Meurer]

clone 783297 -1 -2
reassign -1 busybox
retitle -1 don't source initramfs.conf in busybox initramfs hook
reassign -2 initramfs-tools
retitle -2 remove busybox hook, leave responsibility to busybox package
severity -2 important
retitle 783297 split initramfs integration into a separate package
severity 783297 wishlist
thanks

This mail clones the original bugreport two times and reassigns the
clones to the busybox and initramfs-tools packages with appropriate
titles. See below for details.

Am 27.12.2015 um 07:35 schrieb Ben Hutchings:
> On Fri, 2015-12-25 at 14:46 +0100, Jonas Meurer wrote:
> [...]
>>
>>> /usr/share/initramfs-tools/hooks/busybox will see the BUSYBOX=y setting
>>> and copy the busybox binary.
>>>
>>> /usr/share/initramfs-tools/hooks/zz-busybox sources
>>> /etc/initramfs-tools/initramfs.conf, therefor BUSYBOX=n will be set
>>> again, and the symlinks are not created.
>>
>> Honestly, this looks like a bug in busybox to me. What's the reason for
>> the two busybox initramfs hook scripts at all?
>>
>> *) /usr/share/initramfs-tools/hooks/busybox copies bin/busybox to the
>>initramfs and links /bin/sh to it without sourcing initramfs.conf.
> 
> This is part of initramfs-tools.

So this busybox initramfs hook should be dropped from initramfs-tools
and responsibility for installing busybox into initramfs be handed over
to the busybox package.

>> *) /usr/share/initramfs-tools/hooks/zz-busybox-initramfs sources
>>initramfs.conf, removes busybox binary from initramfs if existent,
>>and copies bin/busybox to initramfs and links all aliases provided
>>by busybox to it.
> 
> This is actually called zz-busybox, and is part of busybox.  Somehow I
> failed to notice this exists. :-/
> 
>> I don't understand the following:
>>
>> What's the purpose of /usr/share/initramfs-tools/hooks/busybox at all,
>> if changes are reverted by
>> /usr/share/initramfs-tools/hooks/zz-busybox-initramfs later on anyway
>> and redone in a slightly different fashion?
> 
> Yes, this is stupid.  We should arrange to properly hand over
> responsibility for installing busybox, and adjust package dependencies
> accordingly.

Ack.

> 
>> Why does /usr/share/initramfs-tools/hooks/zz-busybox-initramfs source
>> initramfs.conf? The BUSYBOY variable is exported by mkinitramfs anyway.
>>
>> The simplest fix to this bug would be to stop sourcing initramfs.conf in
>> hooks/zz-busybox-initramfs.
> 
> It should certainly stop doing that.

This is about the bug in busybox: stop sourcing initramfs.conf from the
zz-busybox initramfs hook.

> [...]
>>> b/ /usr/share/initramfs-tools/conf-hooks.d/cryptsetup drops the
>>> BUSYBOX=y line. And if this is not an option, because cryptsetup
>>> requires busybox, then this should be reflected in the package
>>> dependencies accordingly by making the Recommends a Depends.
>>
>> Do you think that the cryptsetup packages should depend on
>> initramfs-tools and busybox despite the fact that they're usable without?
> 
> No, they should only recommend them.   The busybox hook script is
> changed in initramfs-tools 0.121~rc2 to hard fail if busybox is wanted
> but not installed.  If it's dropped in favour of the zz-busybox hook
> script, then I can move that check into mkinitramfs.

So indeed the check needs to be moved to mkinitramfs as soon as
responsibility for installing busybox is handed over to the busybox
package itself.

Am 27.12.2015 um 14:21 schrieb Michael Biebl:
> Am 25.12.2015 um 14:46 schrieb Jonas Meurer:
>> Yes, cryptsetup initramfs scripts do depend on busybox. At least this
>> was the case some years ago.
>>
>> As cryptsetup can be used without initramfs (e.g. only home
>> partition or removable storage encrypted), the cryptsetup package
>> doesn't depend on "initramfs-tools, busybox" but merely recommends
>> them.
>
> If you want to cleanly support those two different use cases, it looks
> like the cleanest solution would be, to ship the initramfs integration
> in a separate binary package, say cryptsetup-initramfs-tools.
>
> This subpackage would have a strict dependency on initramfs-tools and
> busybox. The main cryptsetup package could have a recommends on that
> subpackage.

This part is about the cryptsetup package itself: it is suggested to
split the initramfs stuff out into a seperate binary package (I prefer
the name 'cryptsetup-initramfs'). This is a wishlist bug.

Cheers,
 jonas




signature.asc
Description: OpenPGP digital signature

Re: [pkg-cryptsetup-devel] Bug#783297: breaks initramfs if BUSYBOX=n

[Jonas Meurer]

Hi Michael, hi Ben,

Am 26.04.2015 um 01:35 schrieb Michael Biebl:
> On Sat, 25 Apr 2015 16:22:13 +0200 Michael Biebl  wrote:
>> if the cryptsetup package is installed, it also installed a
>> initramfs-tools hook.
>>
>> I use BUSYBOX=no in initramfs.conf, but the  cryptroot hook copies
>> /bin/busybox to the initramfs nonetheless.
>>
>> As a result, the initramfs is unable to boot the system
> 
> I looked into this in more detail, and the culprit seems to be
> /usr/share/initramfs-tools/conf-hooks.d/cryptsetup
> which forcefully set's
> BUSYBOX=y.

Yes, cryptsetup initramfs scripts do depend on busybox. At least this
was the case some years ago.

As cryptsetup can be used without initramfs (e.g. only home partition or
removable storage encrypted), the cryptsetup package doesn't depend on
"initramfs-tools, busybox" but merely recommends them.

> /usr/share/initramfs-tools/hooks/busybox will see the BUSYBOX=y setting
> and copy the busybox binary.
> 
> /usr/share/initramfs-tools/hooks/zz-busybox sources
> /etc/initramfs-tools/initramfs.conf, therefor BUSYBOX=n will be set
> again, and the symlinks are not created.

Honestly, this looks like a bug in busybox to me. What's the reason for
the two busybox initramfs hook scripts at all?

*) /usr/share/initramfs-tools/hooks/busybox copies bin/busybox to the
   initramfs and links /bin/sh to it without sourcing initramfs.conf.
*) /usr/share/initramfs-tools/hooks/zz-busybox-initramfs sources
   initramfs.conf, removes busybox binary from initramfs if existent,
   and copies bin/busybox to initramfs and links all aliases provided
   by busybox to it.

I don't understand the following:

What's the purpose of /usr/share/initramfs-tools/hooks/busybox at all,
if changes are reverted by
/usr/share/initramfs-tools/hooks/zz-busybox-initramfs later on anyway
and redone in a slightly different fashion?

Why does /usr/share/initramfs-tools/hooks/zz-busybox-initramfs source
initramfs.conf? The BUSYBOY variable is exported by mkinitramfs anyway.

The simplest fix to this bug would be to stop sourcing initramfs.conf in
hooks/zz-busybox-initramfs.

> The result is a broken initramfs.
> 
> I'm not sure, what is supposed to take precedence in such a case: The
> configuration in /etc/initramfs-tools/initramfs.conf or
> /usr/share/initramfs-tools/conf-hooks.d/cryptsetup and if it's a bug in
> cryptsetup which forcefully overrides BUSYBOX= or if it's a bug in
> busybox, which sources /etc/initramfs-tools/initramfs.conf in
> /usr/share/initramfs-tools/hooks/zz-busybox and therefor doesn't respect
> the settings which are set via conf-hooks.d.

To my understanding, the purpose of
/usr/share/initramfs-tools/hooks-conf.d is to provide a place where
packages that include an initramfs hook script can overwrite settings to
initramfs.conf without altering the config file itself. In other words,
this directory is like an include directory for initramfs.conf. This
implies, that every script which explicitly uses/sources initramfs.conf,
needs to honour this include directory as well.

In fact, we (Guilhem Moulin and me) discuss a related topic with the
initramfs-tools maintainers in bugreport #807527[1] at the moment. In
our eyes, initramfs-tools should provide a clear API or best practice
for custom initramfs hook configuration.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807527

> If cryptsetup really requires busybox and forcefully sets BUSYBOX=y, why
> does the cryptsetup package not depend on busybox?

See above.

> I see several possible fixes here
> 
> a/ /usr/share/initramfs-tools/hooks/zz-busybox doesn't source
> /etc/initramfs-tools/initramfs.conf directly and as a result respects
> settings from hooks directories.

If there's no reason for sourcing initramfs.conf in hooks/zz-busybox,
then this definitely is the way to go.

> b/ /usr/share/initramfs-tools/conf-hooks.d/cryptsetup drops the
> BUSYBOX=y line. And if this is not an option, because cryptsetup
> requires busybox, then this should be reflected in the package
> dependencies accordingly by making the Recommends a Depends.

Do you think that the cryptsetup packages should depend on
initramfs-tools and busybox despite the fact that they're usable without?

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Re: [pkg-cryptsetup-devel] Bug#758755: Bug#758756: libgcrypt20: missing udeb: libgcrypt20-udeb

[Jonas Meurer]

Hey Andreas and Cyril,

Am 21.08.2014 um 19:25 schrieb Cyril Brulebois:
 Andreas Metzler ametz...@bebt.de (2014-08-21):
 On 2014-08-21 Cyril Brulebois k...@debian.org wrote:
 Package: libgcrypt20
 [...]
 but there's no libgcrypt20-udeb! (in the archive or in NEW)
 [...]

 I have just uploaded 1.6.1-3 with the udeb included. I hope NEW
 processing works out well.

Thanks a lot Andreas, it's much appreciated!

 I'll try poking ftpmasters to see if it can get accepted soon. That'd
 avoid thinking about a revert on the cryptsetup side.

Thanks for your help Cyril. Does this mean, that you're ok with
cryptsetup keeping libgcrypt20 dependency now that the corresponding
udeb will be in Debian soon?

Sorry that I didn't coordinate with debian-boot. I simply didn't think
about the consequences enough. I guess that's due to me not being
involved in library transitions too often :-/ *sorry*

Kind regards,
 jonas


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f6f87c.5080...@freesources.org

Re: [pkg-cryptsetup-devel] Bug#758755: libcryptsetup4-udeb: depends on libgcrypt20-udeb, which doesn't exist

[Jonas Meurer]

Hi Cyril,

Am 2014-08-21 01:10, schrieb Cyril Brulebois:

Package: libcryptsetup4-udeb
Version: 2:1.6.6-1
Severity: grave
Justification: renders package unusable

Hi,

your package is no longer installable, because it now depends on
libgcrypt20-udeb, which is nowhere to be found.


now that you report the bugs I realize that I should have checked 
myself.


@GnuTLS-Maint: what's the reason for not shipping a libgcrypt20-udev 
yet?

Do you intend to fix #758756 soon?

Likely a bug in libgcrypt20 (which builds no udeb but leads you to get 
a
dependency on it) which I'm about to file. I don't see it in the 
archive

or in NEW at least.

The switch to libgcrypt20 seems premature to me.


I see. Reason for the switch to gcrypt 1.6 was the recent Whirlpool 
cipher

bug in gcrypt 1.5.3:

http://lists.gnupg.org/pipermail/gcrypt-devel/2014-January/002889.html
http://www.saout.de/pipermail/dm-crypt/2014-January/003799.html
http://www.saout.de/pipermail/dm-crypt/2014-February/003956.html

Also see section '8.3 Gcrypt after 1.5.3 breaks Whirlpool' in cryptsetup 
FAQ:

https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#8._Issues_with_Specific_Versions_of_cryptsetup

Kind regards,
 jonas


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/b74945834b3953f8f7807a2b9c7b5...@imap.steindlberger.de

Re: cryptsetup migration: libcryptsetup1-udeb package?

[Jonas Meurer]

On 03/01/2011 Julien Cristau wrote:
 On Mon, Jan  3, 2011 at 02:21:24 +0100, Jonas Meurer wrote:
 
  Is this due to the fact, that no libgcrypt11-udeb package is available
  at the debian archive yet? It currently sits in NEW, awaiting approval.
 
 Yes.

Will a udeb in experimental satisfy the build system (pbuilder with
/usr/lib/pbuilder/pbuilder-satisfydepends-experimental)? And is it
possible to give a local udeb as dependency instead of waiting until the
NEW queue has been processed?

greetings,
 jonas


signature.asc
Description: Digital signature

Re: cryptsetup migration: libcryptsetup1-udeb package?

[Jonas Meurer]

Hello,

On 02/01/2011 Otavio Salvador wrote:
 On Sat, Jan 1, 2011 at 16:30, Jonas Meurer jo...@freesources.org wrote:
 ...
  I guess that the relavant point is rather: will any d-i component use
  libcryptsetup1 without the need for the cryptsetup binary anytime soon?
  I know that systemd developers intend to use libcryptsetup1.
 ...
 
 Let's split it; it won't hurt.
 
 It is not planned to be used without the binary right now but I think
 it is easier for you to have both working as equal as possible.
 
 Please do it in experimental :-)

Sure, I intended to upload the new packages to experimental anyway. They
will not enter unstable before squeeze has been released.

But now that I added a libcryptsetup1-udeb package, I faced a problem:
libcryptsetup1-udeb depends on libgcrypt11 (= 1.4.2) instead of
libcrypt11-udeb. libgcrypt11 is not a udeb package and thus not
available at debian-installer.
Is this due to the fact, that no libgcrypt11-udeb package is available
at the debian archive yet? It currently sits in NEW, awaiting approval.
Or does it have another reason?

See the information and content of udebs below.

greetings,
 jonas

That's the result:

$ dpkg-deb -I cryptsetup-udeb_1.2.0-1_amd64.udeb 
 new debian package, version 2.0.
 size 33288 bytes: control archive= 669 bytes.
 961 bytes,19 lines  control  
 Package: cryptsetup-udeb
 Source: cryptsetup
 Version: 2:1.2.0-1
 Architecture: amd64
 Maintainer: Debian Cryptsetup Team 
pkg-cryptsetup-de...@lists.alioth.debian.org
 Installed-Size: 176
 Depends: libc6-udeb (= 2.11), libcryptsetup1-udeb (= 2:1.2.0), libpopt0-udeb 
(= 1.16), dmsetup-udeb
 Section: debian-installer
 Priority: optional
 Description: configures encrypted block devices
  Cryptsetup provides a command-line interface for configuring encrypted
  devices. This is done using the Linux kernel device mapper target
  dm-crypt. This version of cryptsetup has integrated support for LUKS.
  .
  cryptsetup is backwards compatible with the on-disk format of cryptoloop,
  but also supports more secure formats. This package includes support for
  automatically configuring encrypted devices at boot time via the config
  file /etc/crypttab. Additional features are cryptoroot support through
  initramfs-tools and several supported ways to read a passphrase or key.

$ dpkg-deb -c cryptsetup-udeb_1.2.0-1_amd64.udeb 
drwxr-xr-x root/root 0 2011-01-03 02:19 ./
drwxr-xr-x root/root 0 2011-01-03 02:19 ./lib/
drwxr-xr-x root/root 0 2011-01-03 02:19 ./lib/cryptsetup/
drwxr-xr-x root/root 0 2011-01-03 02:19 ./lib/cryptsetup/scripts/
-rwxr-xr-x root/root  1476 2011-01-03 02:19 
./lib/cryptsetup/scripts/decrypt_opensc
-rwxr-xr-x root/root  2686 2011-01-03 02:19 
./lib/cryptsetup/scripts/decrypt_keyctl
-rwxr-xr-x root/root  9576 2011-01-03 02:19 ./lib/cryptsetup/scripts/passdev
-rwxr-xr-x root/root  1785 2011-01-03 02:19 
./lib/cryptsetup/scripts/decrypt_openct
-rwxr-xr-x root/root   576 2011-01-03 02:19 
./lib/cryptsetup/scripts/decrypt_gnupg
-rwxr-xr-x root/root   730 2011-01-03 02:19 
./lib/cryptsetup/scripts/decrypt_derived
-rwxr-xr-x root/root   349 2011-01-03 02:19 
./lib/cryptsetup/scripts/decrypt_ssl
-rwxr-xr-x root/root 15888 2011-01-03 02:19 ./lib/cryptsetup/askpass
drwxr-xr-x root/root 0 2011-01-03 02:19 ./lib/cryptsetup/checks/
-rwxr-xr-x root/root   827 2011-01-03 02:19 ./lib/cryptsetup/checks/un_blkid
-rwxr-xr-x root/root   147 2011-01-03 02:19 ./lib/cryptsetup/checks/xfs
-rwxr-xr-x root/root   148 2011-01-03 02:19 ./lib/cryptsetup/checks/swap
-rwxr-xr-x root/root  1040 2011-01-03 02:19 ./lib/cryptsetup/checks/blkid
-rwxr-xr-x root/root   387 2011-01-03 02:19 ./lib/cryptsetup/checks/ext2
-rw-r--r-- root/root 15481 2011-01-03 02:19 
./lib/cryptsetup/cryptdisks.functions
drwxr-xr-x root/root 0 2011-01-03 02:19 ./etc/
drwxr-xr-x root/root 0 2011-01-03 02:19 ./etc/init.d/
-rwxr-xr-x root/root   868 2010-07-22 12:52 ./etc/init.d/cryptdisks
-rwxr-xr-x root/root   817 2010-07-22 12:52 ./etc/init.d/cryptdisks-early
drwxr-xr-x root/root 0 2011-01-03 02:19 ./etc/default/
-rw-r--r-- root/root   652 2010-06-16 15:07 ./etc/default/cryptdisks
drwxr-xr-x root/root 0 2011-01-03 02:19 ./sbin/
-rwxr-xr-x root/root 34440 2011-01-03 02:19 ./sbin/cryptsetup

$ dpkg-deb -I libcryptsetup1-udeb_1.2.0-1_amd64.udeb 
 new debian package, version 2.0.
 size 43564 bytes: control archive= 528 bytes.
 671 bytes,15 lines  control  
 Package: libcryptsetup1-udeb
 Source: cryptsetup
 Version: 2:1.2.0-1
 Architecture: amd64
 Maintainer: Debian Cryptsetup Team 
pkg-cryptsetup-de...@lists.alioth.debian.org
 Installed-Size: 108
 Depends: libc6-udeb (= 2.11), libdevmapper1.02.1-udeb (= 2:1.02.48), 
libgcrypt11 (= 1.4.2), libuuid1-udeb (= 2.16)
 Section: debian-installer
 Priority: optional
 Description: configures encrypted block devices

cryptsetup migration: libcryptsetup1-udeb package?

[Jonas Meurer]

Hello,

I'm in the process of migrating cryptsetup packages to a dynamically
linked binary, which uses the shared libcryptsetup1 library. In order to
do so, the libgpg-error0 and libgcrypt11 libraries need to move to /lib
first, as libcryptsetup1 links against them.

Additionally, libgpg-error0-udeb and libgcrypt11-udeb packages are
required in order to satisfy the dependencies for the cryptsetup-udeb
package.

but now that most of the above issues have been solved by uploads of
libgcrypt11 and libgpg-error to experimental, I wonder whether the split
of cryptsetup binary and libcryptseup1 library packages should be
continued in the udeb packages or not.

in other words: shall I add a libcryptsetup1-udeb package and make the
cryptsetup-udeb package depend on it? or is it better to have only one
cryptsetup-udeb package, containing both the dynamically linked binary
(cryptsetup) and the shared library (libcryptsetup1)?

I guess that the relavant point is rather: will any d-i component use
libcryptsetup1 without the need for the cryptsetup binary anytime soon?
I know that systemd developers intend to use libcryptsetup1.

greetings,
 jonas


signature.asc
Description: Digital signature

Re: [pkg-cryptsetup-devel] UUID in fstab for device mapper devices?

[Jonas Meurer]

hello max,

On 07/08/2009 Max Vozeler wrote:
 Hello fellow maintainers,
 
 we recently changed d-i (partman-target, to be precise) to use 
 UUIDs in fstab in order to get stable device naming.
 
 Currently UUIDs are used for all devices except 
  - /dev/fd*
  - cryptsetup mappings
  - those specified by explicit /dev/disk/by-* paths
 
 Since then, we concluded that it is preferable to go back to plain
 /dev/mapper/ paths for LVM LVs because those already provide stable 
 device naming (and are more descriptive).
 
 What about your types of devices? (dmraid, multipath)
 
 Should we refer to them by UUID or with the /dev/mapper/ paths?

i suggest to go the same way for all device-mapper devices. at least the
same argument (stable device names and more descriptive) holds for all
of them. so i don't see a reason why to treat lvm devices different
from dmraid or dm-crypt devices.

greetings,
 jonas


signature.asc
Description: Digital signature

hint cryptsetup/2:1.0.6+20090405.svn49-1 for debian/squeeze

[Jonas Meurer]

[resent with debian-boot cc'ed]

hey,

cryptsetup/2:1.0.6+20090405.svn49-1 has been in unstable for 59 days now
without migrating to testing. I guess that this is due to the udeb it
creates. It would be great if you could hint it for migration to
testing/squeeze.

here's the relevant changelog:

cryptsetup (2:1.0.6+20090405.svn49-1) unstable; urgency=low

  * New upstream svn snapshot. Highlights include:
- Uses remapping to error target instead of calling udevsettle for
  temporary crypt device. (closes: #514729, #498964, #521547)
- Removes lots of autoconf stuff as it's generated by autogen.sh anyway.
- Uses autopoint in build process, thus needs to Build-Depend on cvs.
- Fixes signal handler to proper close device.
- Wipes start of device before LUKS-formatting.
- Allows deletion of key slot with it's own key. (closes: #513596)
- Checks device mapper communication and gives proper error message in
  case the communication fails. (closes: #507727)
  * Update debian patches accordingly:
- Remove obsolete patches 01_gettext_package and 03_check_for_root
- Update patch 02_manpage
  * Add missing newlines to some error messages in passdev.c. Thanks to
Christoph Anton Mitterer for bugreport and patch. (closes: #509067)
  * Move keyscripts in initramfs from /keyscripts to /lib/cryptsetup/scripts
for the sake of consistency between initramfs and normal system. Document
this change in NEWS.Debian. (closes: #509066)
  * Fix $LOUD in cryptdisks.init and cryptdisks.functions to take effect. Add
LOUD=yes to cryptdisks_start. (closes: #513149)
  * cryptdisks_{start,stop}: print error message if no entry is found in
crypttab for the given name.
  * Actually fix watchfile to work with code.google.com.
  * Update Homepage field to code.google.com URL. (closes: #516236)
  * Fix location of ltmain.sh, build-depend on versioned libtool.
(closes: #521673, #522338)
  * Some minor changes to make lintian happy:
- use set -e instead of /bin/sh -e in preinst.
- link to GPL v2 in debian/copyright
  * Bump standards-version to 3.8.1, no changes needed.
  * Fix a typo in NEWS.Debian. (closes: #522387)
  * Taken from ubuntu:
- debian/checks/un_vol_id: dynamically build the unknown volume type
  string, to allow for encrypted swap, (closes: #521789, #521469). Fix
  sed to replace '/' with '\/' instead of '\\/' in device names.
- disable error message 'failed to setup lvm device' (LP 151532).

 -- Jonas Meurer m...@debian.org  Mon, 06 Apr 2009 08:49:14 +0200


greetings,
 jonas


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

please consider to unblock cryptsetup 1.0.6-7 for lenny

[Jonas Meurer]

Hello,

I just uploaded cryptsetup 1.0.6-7 with urgency=medium to
debian/unstable. This version should be unblocked for lenny as it fixes
one grave , one important and several normal to wishlist bugs. The
complete changelog entry and debdiff are attached.

The debdiff is not that small, but it includes mostly documentation
changes.

cryptsetup provides a udeb, thus i'm cc-ing debian-boot.

Changelog:

cryptsetup (2:1.0.6-7) unstable; urgency=medium

  * Add patches/01_gettext_package.patch: Remove -luks from GETTEXT_PACKAGE
in configure.in.
  * Support keyfiles option in bash completion. Thanks to Stefan Goebel for
the patch. (closes: #499936)
  * Update patches/02_manpage.patch: Fix the documnetation of default cipher
for LUKS mappings. (closes: #495832)
  * Update debian/watch file to reflect the move of project home to
code.google.com.
  * Check for $CRYPTDISKS_ENABLE in cryptdisks initscripts instead of
cryptdisks.functions. This way, cryptdisks_start/stop work even with
$CRYPTDISKS_ENABLE != yes. Thanks to Pietro Abate. (closes: #506643)
  * Add force-start to cryptdisks(-early).init in order to support starting
noauto devices manually. Thanks to Niccolo Rigacci. (closes: #505779)
  * Document how to enable remote device unlocking via dropbear ssh server
in the initramfs during boot process. Thanks to Chris deb...@x.ray.net
for the great work. (closes: #465902)
  * Completely remove support and documentation of the timeout option,
document this in NEWS.Debian. (closes: #495509, #474120)
  * Use exit instead of return in decrypt_ssl keyscript. Thanks to Rene Wagner.
(closes: #499704)
  * Fix initramfs/cryptpassdev-hook to check for passdev instead of mountdev.
Thanks to Christoph Anton Mitterer.
  * cryptdisks.functions:
- Search for keyscript in /lib/cryptdisks/scripts. the cryptoroot initramfs
  script already supports keyscripts without path as argument. Thanks to
  Christoph Anton Mitterer.
  * README.initramfs:
- Remove the mention of bug #398302 from the section about suspend/resume,
  as this bug has been fixes for some time now.
- Remove step 6 (mkswap) from the section about decrypt_derived, as it was
  superfluous. Thanks to Helmut Grohe. (closes: #491867)
  * Fix initramfs/cryptroot-script to use the lvm binary instead of vgchange.
Thanks to Marc Haber. (closes: #506536)
  * Make get_lvm_deps() recursive in initramfs/cryptroot-hook. This is required
to detect the dm-crypt device in setups with more than one level of device
mapper mappings. For example if LVM is used with snapshots on top of the
dm-crypt mapping. Thanks to Christian Jaeger for bugreport and patch, Ben
Hutchings and Yves-Alexis Perez for help with debugging. (closes: #507721)
  * urgency=medium due to several important fixes.

 -- Jonas Meurer m...@debian.org  Wed, 17 Dec 2008 21:25:45 +0100

Please don't hesitate to ask when you've questions regarding the upload.

greetings,
 jonas
diff -u cryptsetup-1.0.6/debian/watch cryptsetup-1.0.6/debian/watch
--- cryptsetup-1.0.6/debian/watch
+++ cryptsetup-1.0.6/debian/watch
@@ -2 +2 @@
-opts=uversionmangle=s/luks-//;s/-pre/~pre/;s/-rc/~rc/ http://luks.endorphin.org/source/cryptsetup-(.*)\.tar\.bz2
+opts=uversionmangle=s/luks-//;s/-pre/~pre/;s/-rc/~rc/ http://cryptsetup.googlecode.com/files/cryptsetup-(.*)\.tar\.bz2
diff -u cryptsetup-1.0.6/debian/NEWS cryptsetup-1.0.6/debian/NEWS
--- cryptsetup-1.0.6/debian/NEWS
+++ cryptsetup-1.0.6/debian/NEWS
@@ -1,3 +1,19 @@
+cryptsetup (2:1.0.6-7) unstable; urgency=medium
+
+  Support for the timeout option has been removed from cryptdisks initscripts
+  in order to support splash screens and remote shells in boot process.
+  The implementation had been unclean and produced many anyway.
+  If you used the timeout option on headless systems without physical access,
+  then it's a much cleaner solution anyway, to use the 'noauto' option in
+  /etc/crypttab, and start the encrypted devices manually with
+  '/etc/init.d/cryptdisks force-start'.
+  Another approach is to start a minimal ssh-server in the initramfs and unlock
+  the encrypted devices after connecting to it. This even supports encrypted
+  root filesystems for headless server systems.
+  For more information, please see /usr/share/docs/cryptsetup/README.Debian.gz
+
+ -- Jonas Meurer m...@debian.org  Tue, 16 Dec 2008 18:37:16 +0100
+
 cryptsetup (2:1.0.6-4) unstable; urgency=medium
 
   The obsolete keyscript decrypt_old_ssl and the corresponding example script
diff -u cryptsetup-1.0.6/debian/README.initramfs cryptsetup-1.0.6/debian/README.initramfs
--- cryptsetup-1.0.6/debian/README.initramfs
+++ cryptsetup-1.0.6/debian/README.initramfs
@@ -138,9 +138,6 @@
 in combination with encryption to keep the resume image safe from potential
 attackers.
 
-Note: This will not work as expected until #398302 has been fixed as the
-decrypted suspend image will currently not be recognized

freeze exception for cryptsetup/2:1.0.6-5

[Jonas Meurer]

Hello,

I just uploaded cryptsetup 2:1.0.6-5, which fixes two release-critical
bugs, to unstable. Please consider a freeze exception for this upload.

See exact changelog below and debdiff attached.

greetings,
 jonas

cryptsetup (2:1.0.6-5) unstable; urgency=high

  * Fix watch file to not report -pre and -rc releases as superior.
  * Remove the global var $SIZE from cryptdisks.functions again but keep the
extended value checks.
  * Remove the udev rules file also in preinst, code taken from example at
http://wiki.debian.org/DpkgConffileHandling. Thanks Marco d'Itri.
(closes: #493151)
  * Remove duplicated configuration of --key-file in $PARAMS at do_noluks().
(closes: #493848).
  * Invoke mount_fs() and umount_fs() in cryptdisks_start, add
log_action_begin_msg() and log_action_end_msg() to both cryptdisk_start
and cryptdisks_stop.
  * Copy fd 3 code from do_start and do_stop to cryptdisks_start and
cryptdisks_stop  to fix keyscript | cryptsetup. (closes: #493622)
  * This upload fixes two RC bugs, thus upload with severity=high.

 -- Jonas Meurer [EMAIL PROTECTED]  Wed, 06 Aug 2008 10:19:21 +0200
diff -u cryptsetup-1.0.6/debian/watch cryptsetup-1.0.6/debian/watch
--- cryptsetup-1.0.6/debian/watch
+++ cryptsetup-1.0.6/debian/watch
@@ -2 +2 @@
-opts=uversionmangle=s/luks-// http://luks.endorphin.org/source/cryptsetup-(.*)\.tar\.bz2
+opts=uversionmangle=s/luks-//;s/-pre/~pre/;s/-rc/~rc/ http://luks.endorphin.org/source/cryptsetup-(.*)\.tar\.bz2
diff -u cryptsetup-1.0.6/debian/changelog cryptsetup-1.0.6/debian/changelog
--- cryptsetup-1.0.6/debian/changelog
+++ cryptsetup-1.0.6/debian/changelog
@@ -1,3 +1,22 @@
+cryptsetup (2:1.0.6-5) unstable; urgency=high
+
+  * Fix watch file to not report -pre and -rc releases as superior.
+  * Remove the global var $SIZE from cryptdisks.functions again but keep the
+extended value checks.
+  * Remove the udev rules file also in preinst, code taken from example at
+http://wiki.debian.org/DpkgConffileHandling. Thanks Marco d'Itri.
+(closes: #493151)
+  * Remove duplicated configuration of --key-file in $PARAMS at do_noluks().
+(closes: #493848).
+  * Invoke mount_fs() and umount_fs() in cryptdisks_start, add
+log_action_begin_msg() and log_action_end_msg() to both cryptdisk_start
+and cryptdisks_stop.
+  * Copy fd 3 code from do_start and do_stop to cryptdisks_start and
+cryptdisks_stop  to fix keyscript | cryptsetup. (closes: #493622)
+  * This upload fixes two RC bugs, thus upload with severity=high.
+
+ -- Jonas Meurer [EMAIL PROTECTED]  Wed, 06 Aug 2008 10:19:21 +0200
+
 cryptsetup (2:1.0.6-4) unstable; urgency=medium
 
   [ David Härdeman ]
diff -u cryptsetup-1.0.6/debian/preinst cryptsetup-1.0.6/debian/preinst
--- cryptsetup-1.0.6/debian/preinst
+++ cryptsetup-1.0.6/debian/preinst
@@ -12,19 +12,47 @@
 	fi
 }
 
+# Remove a no-longer used conffile
+rm_conffile() {
+	PKGNAME=$1
+	CONFFILE=$2
+	if [ -e $CONFFILE ]; then
+		md5sum=`md5sum \$CONFFILE\ | sed -e \s/ .*//\`
+		old_md5sum=`dpkg-query -W -f='${Conffiles}' $PKGNAME | sed -n -e \' $CONFFILE '{s/ obsolete$//;s/.* //p}\`
+		if [ $md5sum != $old_md5sum ]; then
+			echo Obsolete conffile $CONFFILE has been modified by you.
+			echo Saving as $CONFFILE.dpkg-bak ...
+			mv -f $CONFFILE $CONFFILE.dpkg-bak
+		else
+			echo Removing obsolete conffile $CONFFILE ...
+			rm -f $CONFFILE
+		fi
+	fi
+}
+
+LASTVERSION=2:1.0.6-5
 case $1 in
-  install)
-create_etc_keys
-create_crypttab
-  ;;
-	
-  upgrade|abort-upgrade)
-  ;;
-	
-  *)
-echo preinst called with unknown argument '$1' 2
-exit 1
-  ;;
+	install)
+		create_etc_keys
+		create_crypttab
+		if dpkg --compare-versions $2 le $LASTVERSION; then
+			rm_conffile cryptsetup /etc/udev/rules.d/z60_cryptsetup.rules
+		fi
+	;;
+
+	upgrade)
+		if dpkg --compare-versions $2 le $LASTVERSION; then
+			rm_conffile cryptsetup /etc/udev/rules.d/z60_cryptsetup.rules
+		fi
+	;;
+
+	abort-upgrade)
+	;;
+
+	*)
+		echo preinst called with unknown argument '$1' 2
+		exit 1
+	;;
 esac
 
 #DEBHELPER#
diff -u cryptsetup-1.0.6/debian/cryptdisks.functions cryptsetup-1.0.6/debian/cryptdisks.functions
--- cryptsetup-1.0.6/debian/cryptdisks.functions
+++ cryptsetup-1.0.6/debian/cryptdisks.functions
@@ -36,7 +36,6 @@
 	opts=$(echo -n $1 | sed 's/ *#.*//')
 	LOUD=
 	PARAMS=
-	SIZE=
 	CHECK=
 	CHECKARGS=
 	PRECHECK=
@@ -67,12 +66,12 @@
 			PARAMS=$PARAMS -c $VALUE
 			;;
 		size)
-			if echo $VALUE | grep -q ^[[:digit:]]\+$  [ $VALUE -gt 0 ]; then
-SIZE=$VALUE
+			if [ -z $VALUE ] || echo $VALUE | grep -q ^[[:digit:]]\+$  [ $VALUE -gt 0 ]; then
+PARAMS=$PARAMS -s $VALUE
 			else
-log_warning_msg $dst: option size used with an incorrect argument - forced to $SIZE
+log_warning_msg $dst: option size used with an incorrect argument, skipping
+return 1
 			fi
-			PARAMS=$PARAMS -s $SIZE
 			;;
 		hash)
 			if [ -z $VALUE ]; then
@@ -355,8 +354,6 @@
 		return 1
 	fi
 
-	PARAMS=$PARAMS --key-file=$key
-
 	if [ -n

Re: freeze exception for cryptsetup 1.0.6-4

[Jonas Meurer]

On 27/07/2008 Luk Claes wrote:
  I'd like to request a freeze exception for cryptsetup 1.0.6-4. I didn't
  upload it to unstable yet, but if no objections are raised, I'll do so
  tomorrow.
 
 Cc-ing debian-boot as it contains a udeb... no objections from the RT.

Ok, I just uploaded cryptsetup 1.0.6-4 to unstable; with urgency=medium,
as important (#492451) and security (#477203) bugs get fixed.

I suggest to wait the full five days before unblock, so it gets at least
some testing in unstable before actually migrating to testing/lenny.

No changes relevant to debian-installer are made since 1.0.6-1, thus 
debian-boot shouldn't have any objections.

The final changelog is attached. The changes since my initial post to
[EMAIL PROTECTED] are manly documentation improvements, and one
new feature (splashy support in askpass: #492451).

greetings,
 jonas

cryptsetup (2:1.0.6-4) unstable; urgency=medium

  [ David Härdeman ]
  * Make sure $IGNORE is reset as necessary, patch by Thomas Luzat
[EMAIL PROTECTED] (closes: #490199)
  * Use askpass in init scripts as well (closes: #489033, #477203)

  [ Jonas Meurer ]
  * Don't copy_exec libgcc1 in cryptopensc initramfs hook, as it's already
copied by copy_exec /usr/sbin/pcscd automaticly. Thanks to Evgeni Golov
[EMAIL PROTECTED]. (closes: #490300)
  * Remove the udev rules file again as the relevant rules are now provided
by dmsetup package which cryptsetup depends on.
  * Add splashy support to askpass, thanks to John Hughes [EMAIL PROTECTED]
for the patch. (closes: #492451) The support is limited to cryptroot
though, as splashy freezes for passphrase input dialogs from initscripts.
Document that in README.Debian.
  * Now that askpass is used as keyscript for interactive mode, it's not
necessary to set cryptsetup parameter '--tries=$TRIES' and TRIES=1 for
interactive mode anymore in cryptdisks.functions.
  * Implement special treatment for random passphrases now that we use
--key-file=- for all situations. Only necessary in do_noluks.
  * Fix the passphrase prompt string in initramfs/cryptroot.script to use
$cryptsource instead of $cryptsources.
  * Major documentation cleanup for lenny:
- Rewrite CryptoSwap.HowTo in README.Debian, remove CryptoSwap.HowTo.
- Refer to README.initramfs instead of CryptoRoot.HowTo for encrypted root
  filesystem in README.Debian.
- Remove outdated docs CryptoRoot.HowTo, usbcrypto.udev and gen-old-ssl-key
  as well as the decrypt_old_ssl keyscript.
- Remove debian/TODO, didn't have any useful content anyway.
- Fix section ''9. The decrypt_derived keyscript'': Add swap option to
  the example line for crypttab and other minor fixes. Thanks to
  Helmut Grohne [EMAIL PROTECTED]. (closes: #491867)
  * urgency=medium since important (#492451) and security (#477203) bugs get
fixed by this upload.

 -- Jonas Meurer [EMAIL PROTECTED]  Mon, 28 Jul 2008 00:21:44 +0200

cryptsetup (2:1.0.6-3) unstable; urgency=low

  [ Jonas Meurer ]
  * Fix cryptdisks.functions to actually recognize the noauto option. Thanks
to Christian Pernegger [EMAIL PROTECTED] (closes: #483882)
  * Update patches/02_manpage.patch to fix two more typos, thanks to Bruno
Barrera Yever [EMAIL PROTECTED] (closes: #476624) and to remove a
duplicate sentence.
  * Rephrase Enter password for $crypttarget to Enter password to unlock
the disk $cryptsource ($crypttarget) in initramfs/cryptroot.script.
  * Bump Standards-Version to 3.8.0:
- Add a README.source which references /usr/share/doc/quilt/README.source.
- Add support for debian build option parallel=n to debian/rules.
  * Add a udev rules file to ignore temporary-cryptsetup-* devices, as
suggested in bug #467200. Thanks to Sam Morris [EMAIL PROTECTED].
  * Transform debian/copyright into machine-readable code as proposed in
http://wiki.debian.org/Proposals/CopyrightFormat. Update and add several
copyright notices.
  * Change reference to docbook xml v4.2 driver file from an online version
to a local one in the manpage files, as the build process should not
depend on internet access. Add docbook-xml to build-depends. Thanks to
Lucas Nussbaum [EMAIL PROTECTED]. (closes: #487056)

  [ David Härdeman ]
  * Hopefully fix askpass to properly handle console and usplash input
(closes: #477203)
  * Clarify crypttab manpage (closes: #487246)
  * Make regex work if keyfile has extended attributes,
https://launchpad.net/bugs/231339 (closes: #488131)
  * Support comments in options part of crypttab (closes: #488128)

 -- Jonas Meurer [EMAIL PROTECTED]  Mon, 07 Jul 2008 00:30:07 +0200

cryptsetup (2:1.0.6-2) unstable; urgency=low

  [ Jonas Meurer ]
  * Taken from ubuntu:
- debian/scripts/luksformat: Use 256 bit key size by default. (LP: #78508)
- debian/patches/02_manpage.patch: Clarify default key sizes (128 for
  luksFormat and 256 for create) in cryptsetup.8. (side-note in LP #78508

daily netinst image: problems with installing grub(2)

[Jonas Meurer]

Hello,

I just tried the daily built netinst image (for i386) from
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/
in qemu, and they worked well. I setup several test systems with
encrypted root with and without lvm.

I used the debian-testing-i386-netinst.iso image from Feb. 16 2008.

The only thing that always failed, was installing grub/grub2 at the end
of the installation process. Only way to fix that, was to change to a
console, chroot into /target, and run apt-get update manually. After
that, grub2 installed without problems.

So I guess that somewhere in the installation process an apt-get update
is missing.

greetings,
 jonas


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

Re: unknown-field-in-control homepage

[Jonas Meurer]

On 06/02/2008 Russ Allbery wrote:
  I'm not sure whether this is an issue with dpkg or rather with lintian,
  but if I check the cryptsetup deb+udeb packages after building them,
  lintian reports that udebs don't allow the Homepage field in
  debian/control.
 
 This is what I was told by (a d-i maintainer | someone who was willing to
 express an opinion).  I'm happy to change lintian if having Homepage in
 udeb is deemed acceptable.  Otherwise, dpkg should probably be modified to
 not propagate Homepage fields into udebs.

Hey,

I raised this issue on #debian-boot (irc), and was told that the
concerns by (a d-i maintainer | someone who was willing to express an
opinion were correct. Frans Pop from the debian-installer team verified
that the Homepage field should not be included in the udeb:

20:11  mejo fjp: did you see Russ's response to my question regarding
  Homepage Field in udebs?
20:11  mejo fjp: i mean on [EMAIL PROTECTED]
[...]
20:12  fjp mejo: Please file a bug against dpkg-dev.
20:14  fjp mejo: Russ is correct: we don't want the homepage field in
 the control file of udebs


If nobody has any objections, i'll follow Frans' advice and file a bug
against dpkg-dev.

greetings,
 jonas


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

[EMAIL PROTECTED]: [Pkg-cryptsetup-devel] Bug#402417: handle chainmode/essiv plain correctly]

[Jonas Meurer]

Hello,

I need some advice regarding this bug. Unforuntately i don't know
nothing about initramfs, and David Härdeman, the one who usually does
all the cryptsetup initramfs stuff, is unavailable currently.

Could somebody comment on this patch, so that the fix can make it into
etch in case that it is ok?

...
 jonas

- Forwarded message from Leonard Norrgard [EMAIL PROTECTED] -

Date: Thu, 28 Dec 2006 11:56:57 +0200
From: Leonard Norrgard [EMAIL PROTECTED]
Subject: [Pkg-cryptsetup-devel] Bug#402417: handle chainmode/essiv plain
correctly
To: [EMAIL PROTECTED]
Reply-To: Leonard Norrgard [EMAIL PROTECTED],
[EMAIL PROTECTED]

 [ Leonard Norrgård [EMAIL PROTECTED] ]
 * Make sure that crypto modules for the root filesystem are added
   to the image, but only if not specified as plain, as plain is 
handled
   internally in dm-crypt.
 * Use the same terminlogy as dm-crypt does (chainmode).
 (closes: #402417)



___
Pkg-cryptsetup-devel mailing list
[EMAIL PROTECTED]
http://lists.alioth.debian.org/mailman/listinfo/pkg-cryptsetup-devel

- End forwarded message -


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

Re: removal of svenl from the project

[Jonas Meurer]

On 14/03/2006 Andres Salomon wrote:
 Sven's behavior has always been combative (and some might argue
 hostile), but this is beyond what is acceptable.  He threatens bodily
 harm upon another developer in a public forum, and then a week later
 publically insults/taunts a developer (one of the Release Managers,
 even), behind his back.  This is incredibly childish, aggressive
 behavior, and should not be tolerated within the project (IMO).

don't you think that this proposal is childish as well?

it could be argued that it is even guardianship and censorship.

...
 jonas


signature.asc
Description: Digital signature

Re: [Pkg-cryptsetup-devel] Re: Status of partman-crypto

[Jonas Meurer]

On 07/03/2006 Max Vozeler wrote:
 Jonas, I'm going into some details about partman-crypto and
 detailed questions about dm-crypt and LUKS. I hope you don't
 mind that I bombard you with questions like this... :-)

no problem :-)

 I've uploaded a snapshot of partman-crypto in form of a bootable
 mini.iso image so you can see what it currently looks like:
 http://nusquama.org/~max/d-i/20060307/crypto-mini.iso

great, i'll give it a try during the next days.

   This is the part I'm most clueless about. :-)
   Which key types are supported and which are recommended
   for dm-crypt and LUKS respectively?
 
  what do you mean with key types? random keys are only supported
  by dm-crypt, luks requires a persistent key. but appart from
  that, i don't know of any limits. you can use whatever file you
  like as a key. binary, text, and also random data.
 
 To illustrate, the user will be presented with a dialog that
 looks roughly like this:
 
   Use as: Device-mapper encryption (dm-crypt)
   Encryption: cipher
   Key size:   key size
   Key type:   key type
 
   Use as: Device-mapper encryption (LUKS)
   Encryption: cipher
   Key size:   key size
   Key type:   key type
 
 I wonder which choices make sense to offer for the Key type
 option with LUKS and with plain dm-crypt respectively. From what
 I learned until now, I think the choices would be random and
 passphrase for plain dm-crypt and just passphrase for LUKS.
 Both dm-crypt and LUKS I think accept a plain passphrase and
 take care of hashing themselves.

i would add keyfile. random, passphrase and keyfile for dm-crypt,
passphrase and keyfile for luks. keyfile should be a file that the user
provides, or it should be created during the installation.

 To put my question in a different way: cryptsetup can use a
 passphrase and be told to use a random key. Are there other ways
 to produce keys that cryptsetup can use? For keyfiles, for
 example, how are they stored and made available to cryptsetup on
 the installed system? This probably again shows my lack of
 knowledge about both systems :-)

the keyfiles are provides through the filesystem. i may store a key in
/etc/keys/mykey. or i can store it on a usbstick, flashcard, cdrom,
floppy, whatever. cryptsetup currently has no facilities to support
removable media, but theoretically all this is possible.

  i don't know what loop-AES keyfiles are, but for dm-crypt and
  luks any random file can be used as key. the more random it's
  content is, the more secure it is. so when users choose to
  create a key file instead of using an existant one, i'dd
  suggest to use 'dd if=/dev/random of=keyfile'.
 
 This actually seems similar to loop-AES. So another stupid
 question from me :-) Can dm-crypt/LUKS setups be used with
 keyfiles in encrypted form (eg. using openssl or gnupg) and can
 /etc/crypttab be setup so that the user will be asked for a
 passphrase to decrypt the keyfile?

a wishlist bug against crypsetup adds support for openssl encrypted
keys. i planned to do some work related to this task within the next
weeks.

 For loop-AES it works like this: Actual encryption keys are
 created from /dev/random and then encrypted using gnupg and a
 passphrase (or a public key). When the system starts, mount or
 losetup call gnupg to decrypt the keyfile and use the keys
 therein to setup the loop encryption.

it's no problem to implent this in cryptsetup packages as well.

 It seems to me that, if it's possible, it would be preferred
 to use encrypted keyfiles. They have the advantage that the
 actual encryption keys are strongly random (as in /dev/random)
 while users need only memorize a passphrase that they can 
 choose and change.

ok, so you mean that the key for actually encrypting the disk is more
secure than a simple passphrase. i would also like to support
unencrypted keys, stored on removable media, but this needs some more
work to be done.

 Cool - this should all not be difficult to do. The part that
 probably involves most work is to build udeb versions of
 cryptsetup and the libraries it uses. It think some parts do
 already exist as udebs (libdevmapper?).

then we still need libgcrypt11, libgpg-error0, libpopt0, libuuid1,
dmsetup and cryptsetup.

i'll look into it soon.

  but /dev/zero is not really a good source for random data, is
  it? even /dev/urandom is considered as insecure, so i'dd rather
  try to give /dev/random more entropy instead of using less
  secure sources.
 
 The way I understand it we don't need the data that is written
 to be strongly random. For loop-AES - I suppose it's similar for
 dm-crypt - the initialization is used to make it more difficult
 for an adversary to see which blocks actually contain encrypted
 data and are worth trying to crack. If the data is indisting-
 uishable from random data, it should do. [0]

no, i don't mean filling the device with random data before encrypting
it. this is recommented too, and could be provided as an option function
in the 

Re: [Pkg-cryptsetup-devel] Re: Status of partman-crypto

[Jonas Meurer]

On 07/03/2006 Max Vozeler wrote:
  also, what exactly is partman-crypto intended to do?
 
 What you listed is basically what it does. I'll add some
 thoughts on the differences and on changes that might be
 required for plain dm-crypt and LUKS.
 
  - configure a partition as encrypted, specify type
   (loop-aes, dm-crypt, luks), cypher
 
 Yes. For loop-AES we ask about the cipher and type of
 encryption key. Keysize is implied for each cipher. This is
 probably different for dm-crypt setups: I suppose it would 
 need to ask about the keysize and volume name, and could 
 ask about hash function - and perhaps other options?

yes, keysize is usually 128, 192 or 256. cipher and type of key are also
important for dm-crypt and luks. hash might be useful for password based
encryption with plain dm-crypt.
and for sure a target name needs to be supplied, that is given to fstab
later.

  - prepare the partition for encryption
choose a passphrase or key)
 
 This is the part I'm most clueless about. :-)
 Which key types are supported and which are recommended 
 for dm-crypt and LUKS respectively? 

what do you mean with key types? random keys are only supported by
dm-crypt, luks requires a persistent key. but appart from that, i don't
know of any limits. you can use whatever file you like as a key. binary,
text, and also random data.
when i say that luks doesn't support random keys, i mean that a key for
a partition needs to be persistent. while it is perfectly possible to
create a key out of random data and use this key for luksFormat and
later for luksOpen, it is not possible to use random data directly. this
is because luks saves headers on the encrypted partition, and therefore
needs to initialize it first.
in other words, for luks you need to luksFormat a partition first, and
then you can open it with the supplied key/password via luksOpen.
for plain dm-crypt there exists no formatting, thus partitions can be
encrypted with /dev/random directly (what is interesting for swap and
tmp).

 partman-crypto currently knows about two key types: random
 and keyfile (loop-AES GnuPG-encrypted). It also has provisions
 for asking for a plain passphrase. Other key types will
 probably require some new code. crypttab(5) mentions keyfiles;
 Do you know if they are comparable to loop-AES keyfiles?

i don't know what loop-AES keyfiles are, but for dm-crypt and luks any
random file can be used as key. the more random it's content is, the
more secure it is. so when users choose to create a key file instead of
using an existant one, i'dd suggest to use 'dd if=/dev/random of=keyfile'.

  - start the decryption, make the decrypted device available in a way
that it can be mounted
 
 Yes. I suppose we do the LUKS format at the same time we
 currently do losetup for loop-AES, then we create a crypttab
 and do the equivalent of /etc/init.d/cryptdisks start. Am I
 understanding this correctly?

yes, sounds correct.

  - configure the system in a way that this is kept after reboot.
 
 Yes. I suppose we'd need to copy crypttab onto the target
 system and make sure cryptsetup is installed? This should be
 relatively easy to do. Scripts in finish.d/ are responsible 
 for doing this. The target system is mounted in /target.

sounds reasonable too.

  for LUKS setup this point is quite unimportant, but for
  preparing such a setup it might be important. as far as i know,
  cryptsetup itself doesn't use random entropy, but i might be
  wrong.  but ideally the device should be filled with random data
  before it is initialized as encrypted (choose_partition/crypto
  in the README). this indeed needs lots of random entropy.
 
 Here we could re-use what is done for loop-AES: Initialize an
 encrypted loop device with random key and just dd if=/dev/zero
 of=/dev/loop. The advantage being that it consumes rather
 little entropy and is relatively fast.

but /dev/zero is not really a good source for random data, is it? even
/dev/urandom is considered as insecure, so i'dd rather try to give
/dev/random more entropy instead of using less secure sources.

 Can plain dm-crypt and LUKS be used at the same time and
 within the same cryptsetup configuration file? Excuse my
 ignorance - I should really take a closer look at how
 cryptsetup works. :-) 

yes, the cryptsetup package in debian/unstable supports both, plain
dm-crypt and luks. luks partitions are configured via the 'luks' option
in /etc/crypttab. if this option is not present, cryptsetup treats the
partition as a plain dm-crypt one.

...
 jonas


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

Re: [Pkg-cryptsetup-devel] Re: Status of partman-crypto

[Jonas Meurer]

On 06/03/2006 Max Vozeler wrote:
 Here is a rough overview of the current status and my plans for
 it. I'm CCing cryptsetup maintainers to ask if you guys would
 be interested in helping with LUKS support in partman-crypto -
 please see below for more about this.

generally yes, i'dd be glad to help with cryptdisk support in
debian-installer. i cannot speak for the other members of the
pkg-cryptsetup team, but i believe that especially work related to
cryptsetup and LUKS could be done by us.

 [...]
   2. cryptsetup-LUKS support
 
  Work has not started on this yet. 
  
  My estimation is that it won't be difficult to get working.
  I don't have much experience with cryptsetup and don't know
  enough about what are considered best practices, so I've not
  started to work on this myself. I would be very happy to join
  forces with people knowlegeable about it and extend/change
  partman-crypto and get it working.
 
  This is a call and offer for help with LUKS :-) Please get 
  in touch if you are interested. It would be great to have a
  chat about how this support would look. Since I have some 
  free time in the next weeks, I'll start to look into this 
  and send lots of questions to cryptsetup maintainers :-)

don't hesitate to send questions. but i'm not sure where to start
currently. i read the partman-crypto wiki page, the meeting logs and the
README file in parman-crypto svn, but i'm not sure that i understood how
partman works. is partman a native d-i project, or is it a thirdparty
software that is used in d-i?

also, what exactly is partman-crypto intended to do?
- configure a partition as encrypted, specify type (loop-aes, dm-crypt,
  luks), cypher
- prepare the partition for encryption (initialize a LUKS partition,
  choose a passphrase or key)
- start the decryption, make the decrypted device available in a way
  that it can be mounted
- configure the system in a way that this is kept after reboot.

anything else?

   3. Random sources for key generation.
  
  For loop-AES it is essential that we have a good source of
  entropy to allow us to extract the required amount of random
  key data from /dev/random in finite time. Currently the low
  amount of entropy inside d-i makes the key generation block 
  for a long time. (I'm not sure how important this point is 
  for key generation in LUKS setups.)

for LUKS setup this point is quite unimportant, but for preparing such a
setup it might be important. as far as i know, cryptsetup itself doesn't
use random entropy, but i might be wrong.
but ideally the device should be filled with random data before it is
initialized as encrypted (choose_partition/crypto in the README). this
indeed needs lots of random entropy.

another issue is encrypted swap/tmp partitions. they should not have a
persistent key. ideally they use /dev/random as key. this makes them
incompatible with luks (luks needs a persistent key), but with plain
dm-crypt devices there is no problem.

  The plan here is to solicit input from people who maintain
  packages related to entropy gathering in Debian, and find a 
  solution that will make the key generation less painful. This
  may be possible to do by having a daemon like rngd that is fed
  from hardware rngs, audio-entropyd, video-entropyd and other
  potential sources depending on their availability.

sounds like a good plan ;-)

...
 jonas


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

ipchains in d-i

[Jonas Meurer]

Hello,

Why is ipchains still installed at debian install (with d-i), while d-i
depends on 2.4, where iptables does much better work?
I think this package is not needed for base install, he?

bye
 mejo

-- 
Efficiency and progess is ours one more
Now that we have the Neutron bomb
It's nice and quick and clean and gets things done
Kill kill kill kill kill the poor tonight


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

net-1440.img test report

[Jonas Meurer]

Hello,
I got the sources from cvs (24/11/02, ca. 14:30 CET) and built the
net-1440.img with tollef's build.sh script.

First these 'kmod: failed to exec /sbin/modprobe -s -k net-pf-1, errno = 2'
messages are annoying, but I know that this will be fixed if Herbert Xu
uploads new kernel-image-2.4.19-386-udeb with unix socket support in
kernel.

Booting on i386 (old Compaq deskpro with Pentium 133 MHz and 172 MB Ram)
Ethernet controller works with 8139too.
Setting up network hardware worked fine (discover doesn't work since
it's for 2.2 kernels and has still the rtl8139 module listed while it's
renamed to 8139too in 2.4 kernels).

Then the default was on Setting up network with dhcp-client while I
wanted to set up a static network. Maybe I would make both to one point
and ask as first question 'static or with dhcp?'.

Finish setting up Debian-Installer worked fine with http -
net-retriever - Germany - ftp.de.debian.org as mirror and no http
proxy entries. I choosed grub-installer and packet modules.
Detecting discs and loading modules worked fine.
Partition a hard disk was also ok, but fdisk is not very user-friendly,
so cfdisk would be much better since it's better known.

make filesystem was ok, but ext3 didn't work, so I took ext2.
Then mounting the hd on /.

Installing base system was no problem, when it's stable all these
'Downloading 234235' messages should be hidden.

Then installing grub was not successful:
Install GRUB on a hard disk:
GRUB needs to install the stage 1 boot loader on a bootable device. This
is usually the fist hard drive. Note that GRUB conuts devices diffently
than the linux kernel, so the fist one is usually '(hd0)'. Leave this at
default if unsure.
[default = (hd0)]
chroot: cannot execute /sbin/grub-install: No such file or directory
postinst exited with status 256
Debian installer Main Menu

ok, installing lilo (with this annoying default ${bootdev}), giving the
first disc as value worked.

rebooting, network broken (module 8139too not loaded), loaded manually
on tty2, restarted network, wrong gateway (192.168.3.1 while I set it to
192.168.3.5 at the beginning (setting up static network).
fixed, then install worked.

While I took sarge at finish setting up d-i, now install-process took
stable after choosing mirror. That also needs to be fixed.

And: at first entry I choosed 'low' for questions, that could be safed
as value for setting up debconf later.

and the questions on old installs to remove ppp and pcmcia packages
weren't there while I would like to have them.

Ah, and if you choose ReadLine at Debconf install, perl-modules should
be installed automaticly, because otherwise there will be problems.

Last memo: many default settings were wrong, but that's ok at this early
status of d-i ;)

bye
 mejo


-- 
Efficiency and progess is ours one more
Now that we have the Neutron bomb
It's nice and quick and clean and gets things done
Kill kill kill kill kill the poor tonight


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

Bug#149572: boot-floppies: [mipsel] debootstrap sets wrong resolv.conf

[Jonas Meurer]

Package: boot-floppies
Version: N/A; reported 2002-06-10
Severity: normal

When you install over bootp, tftp, nfs on a DECstation 5000/120
(mipsel), and you run debootstrap after booting, debootstrap links
resolv.conf to /target/etc/resolv.conf, which doesn't exist.

bye
 mejo

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux jonas 2.4.18 #1 Sun Jun 9 21:20:51 CEST 2002 i686
Locale: LANG=C, LC_CTYPE=de_DE@euro

-- no debconf information



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