Jonas Meurer <jonas@xxxxxxxxxxxxxxx> wrote: > On 05/04/2006 Clemens Fruhwirth wrote: > > cryptsetup 1.0.3 final is out. > > Available at the regular URL: > > > > http://luks.endorphin.org/dm-crypt > > > > Changes since 1.0.3-rc3: > > > > * alignPayload patch Peter Palfrader > > * meaningful exit codes and password retrying by Johannes Weißl > > great, but i have some minor problems with this release: > - cryptsetup --help does not give information about -q|--batch-mode and > --version any more. > also the description for isLuks somehow changed to 'add key to LUKS > device'. > this got confused somehow, as both issues where fixed in 1.0.3-rc3. check your compile tree (unpack a fresh one?). I'm not seeing anything you described: ghanima:/home/clemens/.xemacs# cryptsetup --help cryptsetup-luks 1.0.3 Usage: cryptsetup [OPTION...] <action> <action-specific>] -q, --batch-mode Do not ask for confirmation .. --align-payload=SECTORS Align payload at <n> sector boundaries - for luksFormat .. isLuks <device> - tests <device> for LUKS partition header .. ghanima:/home/clemens/.xemacs# cryptsetup --version cryptsetup-luks 1.0.3 > - what is meant with 'password retrying'? it sounds like an option to > specify how often the command is retried in case that it fails. > if this is true, why is it neither documented in cryptsetup --help, > nor in man cryptsetup? how does the syntax look like? Right that's missing. When you are in interactive mode (no keyfile, password not read from file descriptor; short: from a terminal) then cryptsetup will retry password reading in case it wasn't able to find a valid key slot for the given password. > the debian package does it in another way. cryptsetup is built without > any "static" options the following way: > > $ make > $ gcc lib/.libs/*.o src/*.o luks/.libs/*.o -o src/cryptsetup.static \ > -lpopt -ldevmapper -luuid /usr/lib/libgcrypt.a \ > /usr/lib/libgpg-error.a > $ make install > $ cp src/cryptsetup.static $(CURDIR)/debian/cryptsetup/sbin/cryptsetup > do you think that using --enable-static in configure is a better way? > or does it do the same? in this case the configure option would be > better, as it ensures that compability is kept even for future releases. The configure option mostly tells libtool to take care of static linking. I think libtool adapts better to all strange host environments, so I think --enable-static is better. But debian isn't a strange host environment, and when the packager feels more confortable with the way above, I don't think he should change. It's a matter of taste. > ps: did you already investigate the bug with encrypted swap files? see > http://bugs.debian.org/351393 for more information. No, and frankly I don't consider myself part of the kernel developer community. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap@xxxxxxxxxxxxx --------------------------------------------------------------------- - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
