Bug#548988: cryptsetup - uuid usage differs from what devmapper expects

[Milan Broz]

Bastian Blank wrote:
 I'm not sure, where this informations comes from, but LVM upstream
 decided to use the UUID of CRYPT-TEMP-* to detect the temporary luks
 devices. Also in the examples, they use CRYPT-PLAIN-* and CRYPT-LUKS1-*,
 which is not set this way by the current version of cryptsetup.

The rule is simple - all dm devices should have UUID set.

for cryptsetup = 1.0.6 it doesn't set dm-uuid at all.

for cryptsetup == 1.0.7 it set dm-uuid for luks device, but because of problems
(people are running snapshots of the whole header and then dm-uuid is 
duplicated...)
I changed it (see debian bug 538221 for example).

So now, all devices created by cryptsetup have DM-UUID set in the format
 CRYPT-devicetype-[uuid-]device name

For example:
 CRYPT-PLAIN-name
 CRYPT-LUKS1--name
 CRYPT-TEMP-name

(All dm devices have prefix which identifies subsystem - here CRYPT-, but we 
have LVM-, DMRAID-,
MPATH, etc.)


For udev rules, you should still detect temporary cryptsetup detect devices by 
name (because of
old version of cryptsetup), but since version 1.1 it have also uuid prefix 
CRYPT-TEMP-.
Name remains (temporary-cryptsetup-$PID)

The lvm code already contains proper rule for udev:

ENV{DM_UUID}==CRYPT-TEMP-?*, GOTO=dm_last_rule
ENV{DM_UUID}!=?*, ENV{DM_NAME}==temporary-cryptsetup-?*, GOTO=dm_last_rule


That's the story. What's the real problem now in this bug?
The old cryptsetup do not set dm-uuid, but I see no real problem with that.

Milan



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

Bug#548988: cryptsetup - uuid usage differs from what devmapper expects

[Milan Broz]

Bastian Blank wrote:
 On Wed, Sep 30, 2009 at 12:01:05PM +0200, Milan Broz wrote:
 That's the story. What's the real problem now in this bug?
 
 What you've shown is the theory. It does not look this way on my system
 nor in the 1.0.7 code.

Of course it is not theory but real implementation. Maybe there is bug.

You really should be more specific. What's your problem?

Milan




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

Bug#612452: cryptsetup: filesystem check with blkid script is not reliable

[Milan Broz]

On 02/08/2011 03:40 PM, Christoph Schindler wrote:
 Package: cryptsetup
 Version: 2:1.1.3-4
 Severity: minor
 
 
 With the upgrade to squeeze, the default cipher for crypt devices
 changed, but cryptdisks_start still accepts the (wronly decrypted)
 device as containing an ext3 filesystem.

Out of curiosity, can you paste dmsetup table for good and wrong
device mapping?

I cannot imagine the situation where it decrypts ext signature correctly
if mode changed.

(The only possibility is using null IV vs Plain IV, where first sector gets the 
same IV
but others differs but this is not the case here).

Milan



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

Bug#612947: cryptsetup: luksformat --help seems to report something

[Milan Broz]

On 02/11/2011 09:34 PM, Olivier Berger wrote:
 luksformat --help is unsupported.
 
 Still, it happens to invoke cryptsetup --help somehow, which won't report the 
 same as man luksformat. This is troublesome.

Neither --help nor --usage is not replacement for man page.

What is missing there?

Milan



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

Bug#612452: [pkg-cryptsetup-devel] Bug#612452: cryptsetup: filesystem check with blkid script is not reliable

[Milan Broz]

On 02/13/2011 02:10 PM, Jonas Meurer wrote:

 I'm able to reproduce this bug. Not sure what to do about it though. It
 seems like aes-cbc-plain and aes-cbc-essiv:sha256 give similar results
 for the bytes where ext filesystems store the filesystem header/stamp.

Well, I think it is expected...

- you get the same volume key in both cases, you have the same key length
and algorithm (aes256) because key is simple hashed passhprase of
the same input with the same hash (rmd160 here).

(Check with dmsetup table --showkeys.)

- the only difference is IV plain (32 sector number) vs essiv:sha256

IV is initial vector for block mode, block is here 16 bytes.

We are operating on 512B sectors, IOW every sector has different IV.

If you check how CBC mode *decryption* works
(http://en.wikipedia.org/wiki/Cipher_block_chaining#Cipher-block_chaining_.28CBC.29)
the second block does not depend directly on IV - it depends on ciphertext.

So logically if we have the same key and mode, only first block (16 bytes)
of every sector will differ, remaining 496 bytes of sector will be decrypted
the same (correctly).

So the ext3 signature is visible but device is unusable.

(Well, maybe I had to change default hash for plain mode to sha256
from ripemd160 to avoid this but it is to late now.)

Just another reason to not use plain mode with hashed passphrase as key but
use LUKS (where key is always generated from RNG).

Milan



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

Bug#601886: [pkg-cryptsetup-devel] Bug#601886: cryptsetup: luksformat leaves the Luks device open

[Milan Broz]

On 02/22/2011 02:22 PM, Jonas Meurer wrote:

 now the bad news: i'm still able to reproduce the bug with recent
 versions of lvm2 and device-mapper. I even replaced the debian udev
 rules by the upstream ones (LVM2.2.02.84/udev) restarted udev, and
 unfortunately still was able to reproduce the bugreport. It seems like
 now the luksClose error device is busy occurs less often than before,
 but i'm still able to reproduce it something like 3 out of 10 tries.

I probably misinterpreted the bug.

So, luksformat cals:

cryptsetup luksFormat
cryptsetup luksOpen x
mkfs x
cryptsetup luksClose

And the last luksClose fails with device busy?

If so:

Are there some WATCH rules? (I see this one in Debian)

# watch for future changes
KERNEL!=sr*, OPTIONS+=watch

So, after mkfs id finished, it closes device and watch rule triggers udev scan
(it uses inotify on read-write close).

This scan is not related to lvm udev, it is asynchronout device scan
(to create various uuid links etc).

Unfortunately it locks device for some time, so if it is not quick enough,
following luksClose fails.

You can verify it by commenting this watch rules out - then it should work
without any sleep.

I am afraid that in this case you must use udevadm settle before luksClose,
this is just wonderful world of udev watch...

(I think that mkfs should generate change event to fix uuid links and do not
rely on these asynchronous hacks but I know that udev/udisks upstream disagrees 
here:-)

Milan



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

Bug#601886: [pkg-cryptsetup-devel] Bug#601886: cryptsetup: luksformat leaves the Luks device open

[Milan Broz]

On 02/22/2011 02:53 PM, Milan Broz wrote:

 # watch for future changes
 KERNEL!=sr*, OPTIONS+=watch

blah, this is not called for dm devices, moreover there is nowatch set...

well, I need to reproduce it to check what is going on here.

Milan




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

Bug#570232: clvm: Missing cmirror means no pvmove support?

[Milan Broz]

On 02/17/2010 02:44 PM, Russell Howe wrote:

 Forgive me if I'm mistaken, but it seems impossible to use pvmove on
 lenny with clustered volume groups.

FYI: with upstream packages you can use pvmove on clustered LV without
cmirror if LV is activated exclusively (on one node only).

If you need pvmove on clustered LV activated on all nodes,
you have to use cmirror.

(I think lenny should behave the same.)

Milan
--
mb...@redhat.com



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b7bfa46.6020...@redhat.com

Bug#552273: Bug#551540: cryptsetup fails when EUID != UID

[Milan Broz]

 reassign 551540 cryptsetup 2:1.1.0~rc2-1

 It seems that cryptsetup luksOpen fails when EUID != UID.  In
 particular, this happens when it is run by pmount which is suid (I
 assume that the reporters above ran pmount as non-root).  If cryptsetup
 is run directly, then it works, because necessarily you become root
 before running cryptsetup; if I become root before running pmount, then
 also everything works.

Because there are still open bugs, let me explain the real source of problem:

- in previous versions (cryptsetup = 1.0.7) gcrypt was used only for plain 
device
hash and did not need initialise gcrypt library properly.

- since 1.1.0* all crypt functions are implemented through gcrypt and
gcrypt is properly initialised including secure memory (gcry_control 
(GCRYCTL_INIT_SECMEM...)

Unfortunately, there is feature in libgcrypt which drops some privileges
after initialisation of that secure memory, in particular

 - it drops UID if UID and EUID differ
 - it drops all capabilities if gcrypt is linked to libcap (not an issue in 
Debian for now)

Suggested workaround (use own memory allocator) is not possible in FIPS mode,
and upstream cryptsetup uses gcrypt to be FIPS compliant if needed.

(pmount workaroud currently uses UID=EUID=0 when calling cryptsetup as 
workaround AFAIK)

Anyway, I think that this is bug in libgcrypt, such side effect is not expected 
when running
from privileged application like cryptsetup and there is no way how to switch 
it off by default.

For more info see upstream cryptsetup bug
http://code.google.com/p/cryptsetup/issues/detail?id=47

and also libgcrypt upstream bug (This is not a bug but a feature.)
https://bugs.g10code.com/gnupg/issue1181

Milan



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

Bug#582481: [pkg-cryptsetup-devel] Bug#582481: initramfs-tools: System won't boot anymore if it was encrypted by debian squeeze setup

[Milan Broz]

On 05/22/2010 01:13 PM, Jonas Meurer wrote:

 kernel-provided name 'dm-0' and NAME='/mapper/sda2_crypt' disagree, please 
 use SYMLINK+=
 or change the kernel to provide the proper name

 i strongly believe it's a udev bug. the same warnings appear on my
 system since last udev upgrade. the apear both at cryptdisks and lvm
 initscript invokation.

Not a bug, feature:-)

Debian uses modified lvm2/dm udev rules (upstream rules do not have this NAME 
change)
which use deprecated renaming of base node.

Please read Peter's explaining comment
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581593#24

Milan



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

Bug#572463: cryptsetup: Please build-depend on autopoint

[Milan Broz]

On 03/04/2010 02:12 PM, Santiago Vila wrote:
 Package: cryptsetup
 Version: 1.1.0~rc2-1
 Severity: important
 User: gett...@packages.debian.org
 Usertags: switch-to-autopoint
 
 There is now an autopoint package. If your package uses the
 autopoint script (either directly or indirectly), please build-depend
 on the autopoint package. If you had cvs in build-depends only because
 of autopoint, you should drop it now.

FYI: upstream cryptsetup use directly autopoint since 1.1.0-rc3,
I suggest upgrade to 1.1.0 final version when adding that
build dependence, thanks.

Milan



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

Bug#574948: cryptsetup doesn't work if disk contains filesystem

[Milan Broz]

On 03/22/2010 01:20 PM, Dmitry E. Oboukhov wrote:
 I think that the fact that cryptsetup doesn't allow to create
 cryptdevice if filesystem exists is a bug. At least it would be nice
 to have an option to bypass this situation.

FYI: this is bug in cryptdisks_start Debian wrapper, not in cryptsetup.
plain cryptsetup allows mapping of any device, no fs check there.
(and in LUKS mode it wipes FS signature during luksFormat)

Milan



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

Bug#577923: cryptsetup is too chatty

[Milan Broz]

On 04/15/2010 10:40 AM, Tim Small wrote:
 Package: cryptsetup
 Version: 2:1.0.6-7
 Severity: normal
 
 Cryptsetup breaks normal unix conventions by being too chatty e.g. this
 command:
 
 cryptsetup luksOpen /dev/sdc Hitachi_500G_number_2a --key-file -
 
 ... outputs:
 
 Command successful.

FYI: This is fixed in 1.1.0 in testing/unstable long time ago.

Milan



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

Bug#573392: [pkg-cryptsetup-devel] Bug#573392: (no subject)

[Milan Broz]

On 03/16/2010 06:13 PM, Jan Engelhardt wrote:

 Oh I'm not from Debian, I just remember that BTS is the cryptsetup
 anchorpoint ;)

well, upstream bug tracker is here http://code.google.com/p/cryptsetup/

But (as you see) Debian BTS works too :)

Please see the new libcryptsetup API (old calls all supported too but just
for backward compatibility).

If there is any problem, please let me know.

There is still a lot of cleanup in other parts of code needed,
but new API is stable now.

Debian, Fedora, Gentoo and probably others have build of cryptsetup
1.1.0 available (where is the new library API).

Milan
--
mb...@redhat.com




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

Bug#572820: dmsetup: Man page broken, does not give full argument syntax

[Milan Broz]

On 03/16/2010 09:13 PM, Bastian Blank wrote:

 The man page for demsetup fails to describe arguments,
 such as the --showkeys in dmsetup table --showkeys.
 From what I gather this seems to be a pass-through
 argument to the dm-crypt target, i.e. dmsetup can take 
 target specific oprtions without mentioning the target 
 device. THIS URGENTLY NEEDS TO BE DOCUMENTED! 
 
 Why?

I expect that that all this is because of request
to add passphrase with only master key knowledge
(admin forgotten password, but encrypted volume still active)

See http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/3982

Anyway, it is already documented upstream (lvm2 2.02.62/ dm-1.02.45).

Milan



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

Bug#590290: lvdisplay leaking file descriptors

[Milan Broz]

On 08/26/2010 03:54 PM, Christoph Anton Mitterer wrote:
 Not sure if this is actually your fd leak,... but there will be a leaked
 fd fix in 2.02.74 (see

please do not confuse people:-) it is completely unrelated problem,
lvm cvs fix is just code cleanup, fixed error is very uncommon.


Reported problem is
 File descriptor 5 (/tmp/tmpfYDdkby (deleted)) leaked on lvdisplay
   invocation. Parent PID 3291: /bin/sh

It means, that application running lvdisplay did not close file descriptor
before running lvm. See man lvm

On invocation, lvm requires that only the standard file descriptors
stdin, stdout and stderr are available.  If others are found, they get
closed and  messages  are  issued warning about the leak.

this is surely not bug in lvm but in cron or whatever forks lvm process..

Leaked descriptor can be security problem in theory, lvm closes
all such leaked descriptors on start and just screams here.
You should get similar warning on SElinux enabled systems.

Also read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466138#15

If it it not badly written cron job, it is probably bug in cron then.

Milan



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

Bug#594756: cryptsetup: Internal error: Maps lock … unlock …

[Milan Broz]

On 08/29/2010 08:14 AM, Paul Menzel wrote:
 today I noticed that after entering my password LUKS is asking for to
 unlock my root device, that the following message appeared. I do not
 know when this started.
 
   Internal error: Maps lock 13664256  unlock 13885440

It is not cryptsetup but lvm screaming probably. 
Missing kernel patch from 2.6.35.3.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d7824370e26325c881b665350ce64fb0a4fde24a

Anyway, you can ignore this message for now, Debian should patch kernel.

Milan



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

Bug#573073: regarding Bug#573073: delay at creating lvm devices

[Milan Broz]

On 09/25/2010 11:19 PM, Marco d'Itri wrote:
 On Sep 25, Jonas Meurer jo...@freesources.org wrote:
 
 the buglog of bug#573073 (filed against cryptsetup) indicates that the
 lvm2 initscript at boot process finishes before the devices are actually
 created by udev.
 There is nothing wrong with this.
 
 i guess this is a general problem concerning several initscripts which
 push udev, but it might be able to workaround it by invoking 'udevadm
 settle' in lvm2 initscript.
 No, it's not like we need to make the boot slower by adding more
 serialization points. The correct solution is to modify cryptsetup to
 install RUN rules and react to the appropriate events.
 e.g. (I do not know it this is correct for this specific case):
 
 SUBSYSTEM=block, ID_FS_TYPE=crypto_LUKS, RUN+=...

With the upstream dm rules yo do not need special udev rules.

It is just Debian lvm/device-mapper maintainer who ignores upstream
udev rules and tries to solve it differently.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593375#39

Please do not use udeavadm settle or any workaround here and try
to use the upstream way.

cryptsetup simply relies on device mapper udev rules when running
with udev support (it synchronizes link creation using these rules
so it cannot happen that you have device but not link in /dev/)

(DM udev rules are provided by lvm/device-mapper package).

Thank you.

Milan



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

Bug#573073: regarding Bug#573073: delay at creating lvm devices

[Milan Broz]

On 09/26/2010 05:38 PM, Bastian Blank wrote:
 On Sun, Sep 26, 2010 at 11:22:32AM +0200, Milan Broz wrote:
 With the upstream dm rules yo do not need special udev rules.
 
 Please provide a patch. The rules are RedHat specific (see the
 definition of DM_SBIN_PATH, which even is a workaround for dracut).

Thanks for answer, but I am not sure what you mean here.

dmsetup is in Debian in /sbin, this is upstream:

10-dm.rules.in:
# Set proper sbin path, /sbin has higher priority than /usr/sbin.   
   
ENV{DM_SBIN_PATH}=/sbin   
   
TEST!=$env{DM_SBIN_PATH}/dmsetup, ENV{DM_SBIN_PATH}=/usr/sbin   
   
TEST!=$env{DM_SBIN_PATH}/dmsetup, GOTO=dm_end   
   

What is Red Hat specific here?

Maybe it can be generated during configure but it is really detail.

The important thing is that link and node creation is synchronised
with the upstream rules.

Please try to accept that udev implementation is compromise
between udev and lvm/device-mapper upstream.
(I understand some of your concerns and I am not fan of some
concepts too but it was decided to go his way - and it works
in other distros already.)

We cannot have part of device-mapper programs using udev
(like cryptsetup) and other ignore it.

I am using Debian unstable too and see several udev related
warnings (lvm over LUKS) during boot - clearly caused by not updated
Debian udev dm rules.

Thanks,
Milan







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

Bug#585934: [udev] UUID discrepancy between cryptsetup luksUUID and udevadm info

[Milan Broz]

On 06/16/2010 12:01 AM, Marco d'Itri wrote:
 On Jun 15, Guy Heatley guy.encr...@member.fsf.org wrote:
 
 r2d2:/home/guy# blkid -o udev /dev/sdc1
 ID_FS_LABEL=/
 ID_FS_LABEL_ENC=\x2f
 ID_FS_UUID=5e6cf0a2-ac35-4d8b-b1cf-f75ad8427551
 ID_FS_UUID_ENC=5e6cf0a2-ac35-4d8b-b1cf-f75ad8427551
 ID_FS_SEC_TYPE=ext2
 ID_FS_TYPE=ext3
 And did udev create links to sdc1 in /dev/disk/ this time?
 
 r2d2:/home/guy# cryptsetup luksUUID /dev/sdc1
 bf6cfa88-8f0c-4e07-ae24-84b25e7e7960

 Hmmm... contradictory

Nope. You are mixing up two UUIDs:

luksUUID is the UUID from LUKS header of underlying device (/dev/sdc1),

ID_FS_UUID is UUID of fs on top of it (here labeled /, it is device 
/dev/mapper/sdc1_crypt or so).

(You can use luksUUID even if device is not active, but FS UUID and label is 
visible only on active LUKS device.)

Milan



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

Bug#585934: [udev] UUID discrepancy between cryptsetup luksUUID and udevadm info

[Milan Broz]

On 06/16/2010 12:57 PM, Guy Heatley wrote:
 On 16/06/2010 11:39, Milan Broz wrote:
 I'm not sure this is true - this device had not been opened by
 cryptsetup at this point: There was no entry in /dev/mapper , it was not
 an active Luks device.

If that device was LUKS formatted long ago, maybe you are seeing the old bug,
when some sectors were not properly wiped and there are both signatures of ext3 
and LUKS
on the device.

You can easily fix that, simply run luksHeaderBackup and luksHeaderRestore
with cryptsetup 1.1.x (this will wipe that problematic area).

If it is problem, please try
crypsetup luksHeaderBackup --header-backup-file file device
crypsetup luksHeaderRestore --header-backup-file file device

Milan



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

Bug#576186: [pkg-cryptsetup-devel] Bug#576186: cryptsetup: Setting up crypto device on Startup takes too long w/ ext3

[Milan Broz]

On 06/16/2010 09:46 PM, Jonas Meurer wrote:

 In order to check whether using so much time is normal, I bought another
 harddisk of the same type and mirrored my system to this new disk using
 the dd command. Mounting this disk (via usb) when the system is
 startet up already takes less then 2 seconds. 

You mean dd whole disk including LUKS or just fs?

 Therefore i believe that some bug is causing cryptsetup to wait 50
 seconds before doing something sensible.
 
 i cannot imagine that this is related to the filesystem at all. dm-crypt
 doesn't mind the content of the encrypted device.

Unlocking time is calculated to take 1 second on the system where it
was formatted. Moving to another slower system will increase unlocking time,
but 50s is very long even for such situation...
(isn't it udev timeout instead?)

Can you try to unlock it manually, add debug and check whete it spend
most of time? I mean run
cryptsetup --debug luksOpen /dev/sda3 sda3_crypt

please also paste here crypsetup luksDump /dev/sda3

Anyway, if it is really problem with cryptsetup unlocking, you can fix it
by adding new passphrase (it can be the same) to new keyslot and then
kill old slot - this will recalculate iteration time leaving data intact.

Milan



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

Bug#576186: [pkg-cryptsetup-devel] Bug#576186: cryptsetup: Setting up crypto device on Startup takes too long w/ ext3

[Milan Broz]

On 07/08/2010 08:22 AM, Markus Melms wrote:
 r...@playstation:# cryptsetup luksDump /dev/sda3
 Aufruf fehlgeschlagen: /dev/sda3 is not a LUKS partition 
 # Aufruf fehlgeschlagen means sth. like Command failed
 
 r...@playstation:# cat /etc/crypttab 
 # target name   source device key file
 # options
 cryptofs  /dev/sda3   none
 check,tries=3,cipher=aes-cbc-essiv:sha256,loud

ok, so it is plain crypt device, not LUKS. So not problem
with cryptsetup itself - here it simply takes passwords, hash it and
use as key.

I think problem is either in some udev rule or in check script,
which waits for something but this is Debian specific.

Milan





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

Bug#586286: [pkg-cryptsetup-devel] Bug#586286: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-3433

[Milan Broz]

On 07/09/2010 09:41 AM, Γιώργος Πάλλας wrote:

 # WARNING: other process locked internal device
 temporary-cryptsetup-18450, retrying remove.
 # WARNING: Process PID 18473 (hald-probe-volu) [PPID 1711 (hald-runner)]
 spying on internal device /dev/dm-4.

Ha! So finally the debug code found something locking the device! :-)

HAL _must_ _not_ open temporary-cryptsetup device.
It can scan final device but not the temporary one.
(udev/udisks have this solved, I thought hal uses the same...)

Maybe it is not the real problem but please fix hal too here.

Milan



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

Bug#586286: [pkg-cryptsetup-devel] Bug#586286: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-3433

[Milan Broz]

On 07/09/2010 02:26 PM, Jonas Meurer wrote:
 But then still the problem is, how should hal distinguish temporary
 cryptsetup devices reliably, when '/dev/dm-X' is used? Milan, is there
 any better/cheaper solution than a lookup for symlinks in /dev/mapper/*?

this is infamous change which was reguired by udev
(/dev/mapper/xyz is now symlink to /dev/dm-X node)

HAL cat translate it to real name:
- with recent kernel (I think 2.6.31, not sure now) you can simple
read /sys/block/dm-X/dm/name
also DM UUID should start with CRYPT-TEMP-*

inside udev rule it should have defined in some variable also (DM_NAME, DM_UUID)

There is similar code in util-linux-ng (mount) which prefers /dev/mapper
name before displaying /dev/dm-X.

I think using /sys/blocks/*/dm/name is simple - if you can ignore old kernels:)

Milan



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

Bug#586286: [pkg-cryptsetup-devel] Bug#586286: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-3433

[Milan Broz]

With recent udev you can try add workaround I tried to write here

https://bugzilla.redhat.com/attachment.cgi?id=431413

(from Fedora equivalent bug https://bugzilla.redhat.com/show_bug.cgi?id=613909 )

Thanks,
Milan



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

Bug#585378: cryptsetup: segfaults on boot (on powerpc)

[Milan Broz]

On 06/10/2010 12:43 AM, Mourad De Clerck wrote:
 cryptsetup asks the password for the root (luks) partition and proceeds to
 segfault. After which it asks the password again. Critical because it made
 this laptop unbootable. I repaired it with another powerpc laptop, target
 mode and chroot. It's a bit tricky to figure out what's going on this early
 in the boot, and I'm a bit loath to upgrade to the current version of
 cryptsetup again. However, if I can help in any way, let me know.

Please can you try to run cryptsetup manually with --debug and post output?

(BTW There is patch for topology ioctl upstream which affects ppc arch,
but this code should not be called during luksOpen...)

Milan



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

Bug#587222: [pkg-cryptsetup-devel] Bug#587222: cryptsetup does not/cannot close dm-crypt devices, if root-fs is on it, but does also not warn about it

[Milan Broz]

On 06/27/2010 12:34 AM, Jonas Meurer wrote:

Milan, if you're reading this: does luksSuspend work for plain dm-crypt
devices as well?


yep, I am reading this just have no time to respond to all of these Debian 
reports:-)

You cannot use luksSuspend for plain device, but you can use dmsetup.

I described this long time ago here (probably before luksSuspend was even 
implemented)
 http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2859

Maybe I can add some kill key for plain device command to cryptsetup?

(The problem is that in LUKS you can check that calculated key is correct,
so luksResume is possible. In plain crypt device you are simple providing key
so there cannot be perfect equivalent of Resume - any key will fit and if
it is not correct, you data will be corrupted later.)

Milan



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

Bug#587501: [cryptsetup] cryptsetup luksDump /dev/mapper/sda2_crypt fails

[Milan Broz]

On 06/29/2010 12:26 PM, Georg Gast wrote:

Package: cryptsetup
Version: 2:1.1.2-1
Severity: normal

The following happens if i try cryptsetup luksDump /dev/sda2_crypt

cryptsetup luksDump /dev/mapper/sda2_crypt
Device /dev/mapper/sda2_crypt is not a valid LUKS device.


man crypsetup:
 status name reports the status for the mapping name.
 luksDump device dumps the header information of a LUKS partition.

IOW
status reports information about active mapping (including underlying
LUKS partition in report)

luksDump shows the information about LUKS on-disk metadata
(even if there is no mapping).


But see the following:
[code]
cryptsetup status /dev/mapper/sda2_crypt
/dev/mapper//dev/mapper/sda2_crypt is active:
cipher:  aes-cbc-essiv:sha256
keysize: 256 bits
device:  /dev/sda2


So you want cryptsetup luksDump /dev/sda2

Milan



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

Bug#554600: luksClose fails:Device (null) doesn't exist or access denied

[Milan Broz]

On 05/23/2010 09:54 PM, ilf wrote:
 Has anyone managed to work around this without having to reboot? 
 Restarting /etc/init.d/cryptdisks doesn't helk.

It is quite possible that this is regression upstream
(luksClose on underlying device which disappeared, I'll check it).

Anyway, you can use dmsetup remove device as temporary workaround
if you need clean something temporarily,
(device is the same like luksClose parameter)

Milan



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

Bug#583397: [pkg-cryptsetup-devel] Bug#583397: No key available with this passphrase

[Milan Broz]

Hi Jonas,
if I understand it correctly, the testing package is basically upstream svn 
snapshot?

If it solves this regression, please let me know and I release new upstream 
version,
I think more people have the same problem.

Just need to verify that current snapshot really fixes this issue.

Thanks,
Milan
--
mb...@redhat.com



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

Bug#583397: [pkg-cryptsetup-devel] Bug#583397: Bug#583397: No key available with this passphrase

[Milan Broz]

On 05/28/2010 11:33 PM, Jonas Meurer wrote:

 by the way, did you already think about issue 53, the request for
 support to remove already unplugged dm-crypt devices? dmsetup remove
 works, but it would be great if cryptsetup would support it as well.

Both problems should be fixed in upstream cryptsetup 1.1.2,
released just few minutes ago.

Thanks for reporting this!
Milan



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

Bug#538221: [codesite-nore...@google.com: Issue 34 in cryptsetup: Command failed: device-mapper: create ioctl failed: Device or resource busy]

[Milan Broz]

Stuart Pook wrote:
 hi Jonas
 
 On 04/09/09 00:11, Jonas Meurer wrote:
 for more information see the upstream issue at
 http://code.google.com/p/cryptsetup/issues/detail?id=34
 
 I did so but I still have problems and this time it is not a snapshot device.
 
 : root; cryptsetup luksOpen /dev/mapper/vg0-services_var services_var 
 --key-file /tmp/xx
 key slot 1 unlocked.
 Command failed: device-mapper: create ioctl failed: Device or resource busy
 
 I don't understand why this fails. I have never made a snapshot of this 
 device (I rebooted last night).

run dmsetup info -c and check UUID for all devices which have CRYPT- prefix.

run cryptsetup luksDump /dev/mapper/vg0-services_var services_var, see UUID 
field

and check that there is no active device from dmsetup above with that UUID 
(ignore CRYPT- prefix).

If so, it is why it fails - --non-exclusive as side effect create device 
without UUID set,
so for kernel it is new device and allows its creation.

If there is no device with the same UUID, it is probably different problem.

Milan




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

Bug#536415: cryptsetup: opening LUKS partitions takes several seconds

[Milan Broz]

Well, I think this is really not bug - I'll try to explain why
it is so slow here.

Note Iterations value for keyslots:

 Key Slot 0: ENABLED
 Iterations: 165980
 Key Slot 1: ENABLED
 Iterations: 435577

The # of iteration is calculated during luksFormat on the machine where
it is formatted/added new key (there is internal benchmark and it calculates
selected hash + PBKDF2 per second).

The calculated value is then used in keyslot, so on the same machine
keyslot should be opened in cca 1 second (depends on system load).

1) If you move such disk to other machine, it can calculate significantly
longer time (or quicker)!

2) The slots are scanned in sequence, beginning from slot 0.
So opening passphrase in slot 1 includes time to decrypt slot 0.
(The time for successful and unsuccessful attempt is the same).

So, for 1) - you can specify iteration time manually (using -i paramater)
if you know that device will be used on slow machine.

(You can also add new keyslot with the same passphrase with lower iteration
count and then delete old keyslot - so it is fixable even for old
LUKS devices).

for 2)
there should be option to specify which slot to use (if you know that
you want always open keyslot 1).

(seems that it doesn't work for CLI now, if you want that please report bug
upstream and I'll try to fix that for luksOpen.)

Milan



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

Bug#619249: cryptsetup: --key-size used instead of --keyfile-size

[Milan Broz]

On 03/22/2011 02:37 PM, Martin Kourim wrote:

just FYI:
This change was intentional, there was no other way because the operator was 
wrongly overloaded.
see  http://code.google.com/p/cryptsetup/wiki/Cryptsetup120

Anyway, your suggested fix is wrong for several reasons:

- -s argument takes size in bits, --keyfile-size in bytes

- Option --keysfile-size has -l short option, not -d, it is bug in cryptsetup 
man page
(fixed upstream already).

- specifying keysize for LUKS in cryptab makes no sense, keysize is read from 
LUKS header

IMHO this line
 data  /dev/sda8   none
 luks,checkargs=ext3,crypt=aes-cbc-essiv:sha256,size=128

should be equivalent to
 data  /dev/sda8   noneluks,checkargs=ext3

(specifying algorithm and keysize make sense only for non-LUKS devices)

I think Debian scripts should ignore these options if it is LUKS formatted 
device.

Milan



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

Bug#624828: [pkg-cryptsetup-devel] Bug#624828: cryptsetup ignores --size option

[Milan Broz]

On 05/10/2011 01:44 AM, Jonas Meurer wrote:
 Hey Milan,
 
 On 02/05/2011 Milan Broz wrote:
 On 05/01/2011 11:38 PM, RW Penney wrote:
 The '--size' option to cryptsetup is supposed to allow one to choose
 a subset of a block device when configuring an encrypted device-mapper 
 target.

 Hm. This is unintended change when switching to new api (internally),
 upstream bug. (Moreover that option was not documented properly.)

 You can workaround it by subsequent cryptsetup resize command for now.

 Anyway, I think this is quite confusing option (you cannot specify start 
 offset,
 so you can just limit end of device, not the mapped start), for these types
 of operation is dmsetup more versatile.
 
 Am I right, that you fixed this bug with a workaround in svn commit 518?

yes.

(As FIXME says, I'll extend crypt plain format parameters later
but that will change API - I plan this when removing old API.
So for now workaroud should be enough.)

(Btw do you plan to rebuild 1.3.0 in experimental? Or is there some problems
I do not know about?)

Milan



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

Bug#624828: cryptsetup ignores --size option

[Milan Broz]

On 05/01/2011 11:38 PM, RW Penney wrote:
 The '--size' option to cryptsetup is supposed to allow one to choose
 a subset of a block device when configuring an encrypted device-mapper target.

Hm. This is unintended change when switching to new api (internally),
upstream bug. (Moreover that option was not documented properly.)

You can workaround it by subsequent cryptsetup resize command for now.

Anyway, I think this is quite confusing option (you cannot specify start offset,
so you can just limit end of device, not the mapped start), for these types
of operation is dmsetup more versatile.

 # Measure size of cryptsetup device:
 dd if=/dev/mapper/cs-test of=/dev/null bs=1b

What about blockdev --getsize64 /dev/mapper/cs-test ?

Milan



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

Bug#601886: [pkg-cryptsetup-devel] Bug#601886: cryptsetup: luksformat leaves the Luks device open

[Milan Broz]

On 02/19/2011 04:48 PM, Jonas Meurer wrote:
 but i guess that the race condition is between libdevmapper and udev.
 maybe this is related to the outdated devmapper (+udev rules) in debian?
 
 on irc someone said that cryptsetup (luksClose) should wait for the
 device to become free in case that udev sync is enabled.

device-mapper udev rules are constructed such way that after cryptsetup
operation udev links processing should be finished.
(iow dmsetup udevcomplete must be the last udev rule which manipulates
with these links. Debian breaks it by reordering udev rules.)

(There is still race with watch udev rule but AFAIK only udisks
using that - but this is not the case here.)

Sorry but I cannot help here until Debian maintaner wakes up and updates
lvm/device-mapper udev rules. The changed Debian udev device-mapper rules
are not supported by upstream.

(You can add udevadm settle instead of sleep 1, but all these hacks are
workarounds which are not needed with upstream.)

Milan



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

Bug#614118: [ha...@afaics.de: [pkg-cryptsetup-devel] Bug#614118: error-prone command line options]

[Milan Broz]

On 02/20/2011 06:45 PM, Jonas Meurer wrote:
 To me it's a matter of taste whether the cryptsetup commands are
 case-sensitive or not. One might either argue that it doesn't hurt to
 support lowercase commands like 'luksformat' and 'luksopen' as well, or
 argue that commandline options are _always_ case-sensitive for common
 commandline applications.

and passphrases are also case sensitive:-)

 
 If you decide that cryptsetup commands stay case sensitive, then I'll
 simply tag the bugreport as wontfix.

Well, I did not invented that, I do not like combined case commands there
too much but I do not want to change it now (most users which have problems
here will use some GUI wrapper or so anyway).

Argument is the same like for type uppercase yes - it forces people
to think before it blindly answer yes or issue some command.
You should have some uppercase chars in passphrase so using it in command
should not hurt:-)

Milan



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

Bug#674027: cryptsetup: please document -r argument shorthand for --readonly in manpage

[Milan Broz]

On 05/22/2012 05:21 PM, Jon Dowland wrote:

 -r is an alias for --readonly but is missing from the manpage.
 Patch attached.

Fixed upstream in 
http://code.google.com/p/cryptsetup/source/detail?r=d0c98af4e6a07d95b87f22d2939b83ae6a22d725#

Thanks,
Milan



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

Bug#690551: libcurl3-gnutls: git fails for https repos

[Milan Broz]

Package: libcurl3-gnutls
Version: 7.28.0-1
Severity: important

After updating to libcurl3-gnutls=7.28.0-1, all git commands fail for https 
repos.
Downgrade to 7.26.0-1 (only libcurl3-gnutls) solves the problem.
e.g.

$ GIT_CURL_VERBOSE=1  git clone https://code.google.com/p/cryptsetup/

Cloning into 'cryptsetup'...
* About to connect() to code.google.com port 443 (#0)
*   Trying 173.194.69.102...
* 0x6df5a0 is at send pipe head!
* STATE: CONNECT = WAITCONNECT handle 0x6e83b0; (connection #0) 
* Connected to code.google.com (173.194.69.102) port 443 (#0)
* Connected to code.google.com (173.194.69.102) port 443 (#0)
* found 152 certificates in /etc/ssl/certs/ca-certificates.crt
* STATE: WAITCONNECT = PROTOCONNECT handle 0x6e83b0; (connection #0) 
*server certificate verification OK
*common name: *.google.com (matched)
*server certificate expiration date OK
*server certificate activation date OK
*certificate public key: RSA
*certificate version: #3
*subject: C=US,ST=California,L=Mountain View,O=Google 
Inc,CN=*.google.com
*start date: Thu, 27 Sep 2012 01:23:05 GMT

*expire date: Fri, 07 Jun 2013 19:43:27 GMT

*issuer: C=US,O=Google Inc,CN=Google Internet Authority
*compression: NULL
*cipher: ARCFOUR-128
*MAC: SHA1
* STATE: PROTOCONNECT = DO handle 0x6e83b0; (connection #0) 
 GET /p/cryptsetup/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.7.10.4
Host: code.google.com
Accept: */*
Pragma: no-cache

* STATE: DO = DO_DONE handle 0x6e83b0; (connection #0)
* STATE: DO_DONE = WAITPERFORM handle 0x6e83b0; (connection #0)
* STATE: WAITPERFORM = PERFORM handle 0x6e83b0; (connection #0)
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
 HTTP/1.1 200 OK
 Content-Type: application/x-git-upload-pack-advertisement
 Expires: Fri, 01 Jan 1980 00:00:00 GMT
 Pragma: no-cache
 Cache-Control: no-cache, max-age=0, must-revalidate
 X-Content-Type-Options: nosniff
 Date: Mon, 15 Oct 2012 12:53:06 GMT
 Server: git_frontend
 Content-Length: 1044
 X-XSS-Protection: 1; mode=block

* STATE: PERFORM = DONE handle 0x6e83b0; (connection #0)
* Connection #0 to host code.google.com left intact
* Expire cleared
* About to connect() to code.google.com port 443 (#0)
*   Trying 173.194.69.139...
* connected
* Connected to code.google.com (173.194.69.139) port 443 (#0)
* found 152 certificates in /etc/ssl/certs/ca-certificates.crt
* SSL re-using session ID
* failed to get server cert
* Closing connection #0
error: RPC failed; result=51, HTTP code = 0
fatal: The remote end hung up unexpectedly


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.5.4 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libcurl3-gnutls depends on:
ii  libc6  2.13-35
ii  libgcrypt111.5.0-3
ii  libgnutls262.12.20-1
ii  libgssapi-krb5-2   1.10.1+dfsg-2
ii  libidn11   1.25-2
ii  libldap-2.4-2  2.4.31-1
ii  librtmp0   2.4+20111222.git4e06e21-1
ii  libssh2-1  1.4.2-1.1
ii  multiarch-support  2.13-35
ii  zlib1g 1:1.2.7.dfsg-13

Versions of packages libcurl3-gnutls recommends:
ii  ca-certificates  20120623

libcurl3-gnutls suggests no packages.

-- no debconf information


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

Bug#648367: [dm-devel] Bug#648367: device-mapper devices such as dm-crypt always have rotational=1; should inherit rotational setting from underlying devices

[Milan Broz]

On 11/14/2011 03:26 AM, Josh Triplett wrote:
 OK, I suppose I don't actually care what rotational shows for a
 device-mapper device backed by rotating media.  The case I care about:
 when the underlying media has rotational=0, the dm device definitely
 shouldn't have rotational=1.

Rotational flag is inherited in DM core, nothing dm-crypt specific.
And it works (for several kernel releases already):


create test scsi disk (also with discards)
# modprobe scsi_debug dev_size_mb=16 sector_size=512 num_tgts=1 lbpu=1
# grep scsi_debug /sys/block/*/device/model   
/sys/block/sdj/device/model:scsi_debug 

Map some crypt device over it
# echo password | cryptsetup create sdj_crypt /dev/sdj

And now see inherited ROTA flag (it is /sys rotational)

# lsblk -t /dev/sdj
NAME   ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE
sdj0512  32768 512 5120 cfq   128
`-sdj_crypt (dm-0) 0512  32768 512 5120   128


Please paste lsblk -t output tree if you think there is a bug, do not blindly
check all dm-X devices queues.

Milan



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

Bug#648367: [dm-devel] Bug#648367: device-mapper devices such as dm-crypt always have rotational=1; should inherit rotational setting from underlying devices

[Milan Broz]

On 11/15/2011 05:41 PM, Josh Triplett wrote:
 I didn't know about that command; very nice, thanks!  lsblk confirms
 that on my system, the physical disk has rotational=0 but the dm-crypt
 and LVM devices have rotational=1:
 
 NAME   ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED
 sda0512  0 512 5120 cfq
 ├─sda1 0512  0 512 5120 cfq
 └─sda2 0512  0 512 5120 cfq
   └─sda2_crypt (dm-0)  0512  0 512 5121 
 ├─leaf-swap (dm-1) 0512  0 512 5121 
 └─leaf-root (dm-2) 0512  0 512 5121 
 
 Does that help?

Thanks.

As noted on that bug earlier, it is already fixed in 3.2-rc1
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4693c9668fdcec229825b3763876b4744f9e6d5e

(I thought it is fixed long time ago!)

There is no problem in DM layer with this (dmcrypt does not have own io 
scheduler)
but perhaps FS can use this flag for some optimization tuning, dunno.

Milan



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

Bug#684086: cryptsetup: Passphase/passphrase typo in crypttab man page

[Milan Broz]

Package: cryptsetup
Version: 2:1.4.3-2
Severity: minor

The crypttab man page has has on several places passphase which shuld be
apparently passphrase.

E.g.
The third field, key file, describes the file to use as a key for decrypting 
the data of the source device.
Note that the entire key file will be used as the passphase; the passphase must 
not be followed by a newline character.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.4.7 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages cryptsetup depends on:
ii  cryptsetup-bin 2:1.4.3-2
ii  debconf [debconf-2.0]  1.5.45
ii  dmsetup2:1.02.74-4
ii  libc6  2.13-35

cryptsetup recommends no packages.

Versions of packages cryptsetup suggests:
ii  busybox 1:1.20.0-6
ii  dosfstools  3.0.13-1
ii  initramfs-tools [linux-initramfs-tool]  0.107
ii  liblocale-gettext-perl  1.05-7+b1
ii  udev175-5

-- debconf information excluded


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

Bug#676159: cryptsetup checks LUKS offset incorrectly with detached header

[Milan Broz]

On 06/05/2012 08:28 AM, Alex Roper wrote:
 When operating with a detached header,
 setup.c:crypt_check_data_device_size checks to make sure the detached
 header is at least as large as the offset specified in the header. This
 is fine for a regular header, but this causes a detached header to fail
 unless the header file appears to be at least as large as the offset.
 
 When --header is used, the check should consider the size of the backing
 device, not the LUKS header device.

Can you report it upstream please? 
http://code.google.com/p/cryptsetup/issues/list
(With some reproducer please. You need space for keyslots on LUKS header device,
not on data backing device, so I still do not see what problem exactly you see 
here,
header file must have a least space for header + all kesylots.)

Milan



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

Bug#677127: relocation error

[Milan Broz]

On 06/11/2012 09:31 PM, p...@spth.de wrote:
 /sbin/crpytsetup: relocation error: /sbin/cryptsetup: symbol
 crypt_activate_by_key_file_offste, version CRYPTSETUP_1.0 not defined in file
 libcryptsetup.so.4 with link time reference

 
just if it helps: crypt_activate_by_key_file_offset was added in 1.4.2 
libcryptsetup,
library is backward compatible but not forward compatible of course.

Isn't possible that you have in initramfs old libcryptsetup.4 but
new cryptsetup binary? (it should have proper version set, so it should be 
visible
even for *.so symlink)

Milan



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

Bug#662768: [cryptsetup] New cryptsetup version chokes on old LUKS header

[Milan Broz]

On 03/06/2012 10:38 AM, Konrad Zimmermann wrote:

Package: cryptsetup
Version: 2:1.4.1-2
Severity: normal

--- Please enter the report below this line. ---

I am running 3 LUKS encrypted disks in a software RAID5.
After upgrading to version 2:1.4.1-2 of cryptsetup

cryptsetup luksOpen /dev/sdb sdb_crypt

on any of these disks failed, returning the error

LUKS keyslot 4 is invalid.
LUKS keyslot 5 is invalid.


Hi, this is just new check in this version, your LUKS header is already
corrupted. (I guess corrupted kesylots offsets.)

Please can you paste output of
cryptsetup luksOpen /dev/sdb sdb_crypt --debug  ?

No need to worry, it is just additional check and if you are able to open
volume with old version it is easy to fix without any data loss.

Thanks,
Milan



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

Bug#662768: [cryptsetup] New cryptsetup version chokes on old LUKS header

[Milan Broz]

On 03/06/2012 12:19 PM, Milan Broz wrote:


LUKS keyslot 4 is invalid.
LUKS keyslot 5 is invalid.


So, as expected, there was partition table signature written
over LUKS header.

I added some code to fix it upstream, not enabled by default.
http://code.google.com/p/cryptsetup/source/detail?r=fff8b02b46cc85f22d1b938febdb2df924417cbf

For that particular header it produced:

LUKS keyslot 4 is invalid.
LUKS keyslot 5 is invalid.
Repairing keyslots.
Keyslot 4: offset repaired (318247672 - 1032).
Keyslot 4: stripes repaired (0 - 4000).
Keyslot 4: salt wiped.
Keyslot 5: offset repaired (0 - 1288).
Keyslot 5: stripes repaired (0 - 4000).
Keyslot 5: salt wiped.
Keyslot 6: bogus partition signature.
Keyslot 6: salt wiped.

(I think you can close this bug now :-)

Milan



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

Bug#659235: cryptsetup: Fails to detect crypted devices on LVM

[Milan Broz]

On 02/09/2012 12:33 PM, Kai Weber wrote:

Calling hook cryptroot
cryptsetup: WARNING: failed to find deps for vg--sda-root
cryptsetup: FAILURE: could not determine configuration for vg--sda-root


The result of the warning/failure is a missing cryptroot file in initrd.
Maybe a problem with the (strange) naming of my LVM volume group (vg-sda)?


it could be - note that lvm uses dash (-) to separate VG and LV name
in kernel device-mapper, so all other dashes are doubled (that's why
you see vg--sda-root).

Either the script should use /dev/VG/LV path (instead of /dev/mapper/...)
or you should decode lvm name using dmsetup:

# dmsetup splitname vg--sda-root
VG LV   LVLayer
vg-sda root

(there is --noheading as well)

just FYI...

Milan



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

Bug#707997: cryptsetup: Please package veritysetup and cryptsetup-reencrypt (with update, to version 1.6.1)

[Milan Broz]

Package: cryptsetup
Version: 2:1.4.3-4
Severity: wishlist
Tags: patch

Hi cryptsetup Debian maintainers :)

Please can you update cryptsetup to version 1.6.1 (at least in experimental)
(see also bug #704827)?

Reported separately, because this bug requests packaging of two new tools:

- veritysetup (setup of dm-verity block devices, e.g. used in Chrome OS)

- cryptsetup-reencrypt (LUKS device offline reencryption tool)

Patches needed for Debian package attached, I tested boot with fully encrypted
system (wheezy) and it still works.

Second attached patch fixes some compilation errors in Debian specific tools,
but these are just cosmetic fixes.

Thanks,
Milan

p.s.
Please let me know if you need any help - as upstream maintainer of cryptsetup
I am using Debian as primary platform now (but I am not Debian packager).

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.7.4 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages cryptsetup depends on:
ii  cryptsetup-bin 2:1.4.3-4
ii  debconf [debconf-2.0]  1.5.50
ii  dmsetup2:1.02.77-1
ii  libc6  2.13-38

Versions of packages cryptsetup recommends:
ii  busybox 1:1.20.0-8
ii  console-setup   1.92
ii  initramfs-tools [linux-initramfs-tool]  0.112
ii  kbd 1.15.5-1

Versions of packages cryptsetup suggests:
ii  dosfstools  3.0.16-2
ii  liblocale-gettext-perl  1.05-7+b1

-- debconf information excluded

diff -rupN debian.old/changelog debian/changelog
--- debian.old/changelog	2013-01-05 22:11:50.0 +0100
+++ debian/changelog	2013-05-12 14:52:10.866587706 +0200
@@ -1,3 +1,17 @@
+cryptsetup (2:1.6.1-1.1) UNRELEASED; urgency=low
+
+  * NOT RELEASED YET
+
+  * Non-maintainer upload.
+  * update to upstream package 1.6.1
+  * default LUKS encryption mode is now XTS (aes-xts-plain64)
+  * add native support for activation of Truecrypt and compatible on-disk format
+  * add benchmark command
+  * add veritysetup, tool for dm-verity block device verification kernel module
+  * add cryptsetup-reencrypt, tool to offline reencrypt LUKS device
+
+ -- Milan Broz gmazyl...@gmail.com  Sat, 11 May 2013 19:43:07 +0200
+
 cryptsetup (2:1.4.3-5) unstable; urgency=low
 
   * NOT RELEASED YET
diff -rupN debian.old/control debian/control
--- debian.old/control	2013-01-05 22:11:50.0 +0100
+++ debian/control	2013-05-12 14:15:37.0 +0200
@@ -90,3 +90,19 @@ Description: disk encryption support - s
  Setup (LUKS) support.
  .
  This udeb package provides libcryptsetup for the Debian Installer.
+
+Package: cryptsetup-reencrypt
+Section: admin
+Architecture: linux-any
+Depends: ${shlibs:Depends}, ${misc:Depends}, libcryptsetup4 (= 2:1.6)
+Description: disk encryption support - offline reencryption tool
+ Cryptsetup-reencrypt provides a tool which can be used for offline
+ reencryption of LUKS disk in situ.
+
+Package: veritysetup
+Section: admin
+Architecture: linux-any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: tool to setup dm-verity
+ Veritysetup provides an interface for configuring data verification
+ on block devices using dm-verity kernel module.
diff -rupN debian.old/copyright debian/copyright
--- debian.old/copyright	2012-06-11 21:49:20.0 +0200
+++ debian/copyright	2013-05-12 14:27:40.0 +0200
@@ -1,11 +1,12 @@
 Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
-Upstream-Contact: Milan Broz mb...@redhat.com
+Upstream-Contact: Milan Broz gmazyl...@gmail.com
 Source: http://code.google.com/p/cryptsetup
 
 Files: *
 Copyright: © 2004  Christophe Saout christo...@saout.de
© 2004-2008 Clemens Fruhwirth clem...@endorphin.org
-   © 2008-2010 Milan Broz mb...@redhat.com
+   © 2008-2012 Red Hat, Inc.
+   © 2008-2013 Milan Broz gmazyl...@gmail.com
 License: GPL-2+
 
 Files: debian/*
@@ -13,6 +14,7 @@ Copyright: © 2004-2005 Wesley W. Terpst
© 2005-2006 Michael Gebetsroither michael@gmx.at
© 2006-2008 David Härdeman da...@hardeman.nu
© 2005-2010 Jonas Meurer jo...@freesources.org
+   © 2013  Milan Broz gmazyl...@gmail.com
 License: GPL-2+
 
 Files: debian/askpass.c debian/passdev.c
diff -rupN debian.old/cryptsetup.docs debian/cryptsetup.docs
--- debian.old/cryptsetup.docs	2012-02-07 16:11:32.0 +0100
+++ debian/cryptsetup.docs	2013-05-12 14:43:56.0 +0200
@@ -1,5 +1,6 @@
 AUTHORS
 FAQ
+docs/*ReleaseNotes
 debian/README.keyctl
 debian/README.gnupg
 debian/README.initramfs
diff -rupN debian.old/cryptsetup-reencrypt.dirs debian/cryptsetup-reencrypt.dirs
--- debian.old/cryptsetup-reencrypt.dirs	1970

Bug#713852: dmsetup remove nonexistent_device waits forever

[Milan Broz]

Package: dmsetup
Version: 2:1.02.77-3
Severity: important

If you run dmsetup remove for non existent device, tool must
return immediately.

Now it waits for udev:

dmsetup remove loop0
...
open(/run/udev/queue.bin, O_RDONLY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fed62b0a000
read(4, \333\5\0\0\0\0\0\0, 4096) = 8
close(4)= 0
munmap(0x7fed62b0a000, 4096)= 0
open(/dev/urandom, O_RDONLY)  = 4
read(4, n\301, 2) = 2
close(4)= 0
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, 15) = 4
setsockopt(4, SOL_SOCKET, SO_ATTACH_FILTER, 
\n\0\0\0\0\0\0\0\220\277)I\377\177\0\0, 16) = 0
bind(4, {sa_family=AF_NETLINK, pid=0, groups=0002}, 12) = 0
getsockname(4, {sa_family=AF_NETLINK, pid=10887, groups=0002}, [12]) = 0
setsockopt(4, SOL_SOCKET, SO_PASSCRED, [1], 4) = 0
ioctl(3, DM_DEV_REMOVE, 0x6185f0)   = -1 ENXIO (No such device or address)
open(/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT 
(No such file or directory)
open(/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT 
(No such file or directory)
open(/usr/share/locale/en_US/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT (No 
such file or directory)
open(/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT 
(No such file or directory)
open(/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT (No 
such file or directory)
open(/usr/share/locale/en/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT (No such 
file or directory)
write(2, device-mapper: remove ioctl on l..., 70device-mapper: remove ioctl 
on loop0 failed: No such device or address) = 70
write(2, \n, 1
)   = 1
poll([{fd=4, events=POLLIN}], 1, 4294967295^C unfinished ...

^^^ it cannot receive event for device which doesn't exist!


After short search I found this upstream response to Debian approach
https://www.redhat.com/archives/lvm-devel/2013-June/msg00353.html

IMHO it is very good idea to use udev monitor but it must be done properly.

Seems like Debian uses untested patches and diverts from upstream. Why?

All other packages which use device-mapper are affected too
(only additional checks for device existence prevents to happen this
loop for cryptsetup close/remove command for example).


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.9.4 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dmsetup depends on:
ii  libc6   2.17-5
ii  libdevmapper1.02.1  2:1.02.77-3
ii  libudev0175-7.2
ii  util-linux  2.20.1-5.4

dmsetup recommends no packages.

dmsetup suggests no packages.

-- no debconf information


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

Bug#714391: [pkg-cryptsetup-devel] Bug#714391: cryptsetup-bin: build with support for pwquality?

[Milan Broz]

On 06/28/2013 09:59 PM, Jonas Meurer wrote:
 If you really consider password quality checking mechanisms a valid
 feature request for cryptsetup, please discuss this issue upstream.

It is already there (but only for LUKS), just not enabled as default,
see --enable-pwquality configure option.

libpwquality is central pw checker in system with common policy in RHEL/Fedora
(I was not fan of this feature as well but no single report since
we enabled it in Fedora.)

But in Debian this decision must be system wide and I think nobody is using
libpwquality there yet (but I see it is in repo already).

Milan


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

Bug#714391: [pkg-cryptsetup-devel] Bug#714391: cryptsetup-bin: build with support for pwquality?

[Milan Broz]

On 06/28/2013 11:47 PM, Christoph Anton Mitterer wrote:

 Milan, why has this do be done system wide?

The main goal of libpwquality feature in cryptsetup was that
you have one common place to set up system-wide policy for passwords.
(All system tools handling passwords must link to it.)
That's how is done in Fedora (where libpwquality originated).
See man pwquality.conf

Otherwise I do not think every program should implement own
pw quality checks. (And even here, it is only cryptsetup binary
doing this, not libcryptsetup itself - check is on higher level.)

Milan


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

Bug#768407: cryptsetup: dm-crypt disk unlocks on older Debian, does not on current testing

[Milan Broz]

On 11/07/2014 10:11 AM, clayton wrote:
 Package: cryptsetup
 Version: 2:1.6.6-3
 Severity: important
 
 I have an old dm-crypt partition that I have been using for long-term backups.
 This is the crypttab:
 
 backcrypt /dev/sdb2 none 
 cipher=aes-cbc-plain,size=256,hash=ripemd160,noauto,loud

If it is not passphrase, are you sure these were the correct parameters? Who 
added them there?
(mainly check mode: -plain /-essiv:sha256, key size 128/256 ?)

(it should be, these are old cryptsetup plain defaults but you should check
old crypttab backups for sure... really better use LUKS to avoid this problem,
or even better - if you have systtem which opens it correctly, use cryptsetup 
status
for active device and check it)

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

Milan


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

Bug#784129: [cryptsetup] Unlocking an aes:ecb-benbi volume with cryptsetup triggers input/output error

[Milan Broz]

 Cryptsetup  2:1.6.6-5 fails unlocking my aes:ecb-benbi crypted volume.

FYI this is fixed in 1.6.7, see
https://gitlab.com/cryptsetup/cryptsetup/issues/238

You have also workaround mentioned there (do not specify IV for ECB mode because
there is no initial vector in ECB mode - iow benbi is superfluous).

Anyway, ECB mode for disk encryption is not secure, I hope you do not use it 
for real data!

Milan


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

Bug#791944: [pkg-cryptsetup-devel] Bug#791944: udev: shutdown hangs because of missing swapoff

[Milan Broz]

On 12/15/2015 08:55 PM, Jochen Sprickerhof wrote:
> * Jonas Meurer  [2015-12-10 13:16]:
>> Could you try to replace 'cryptsetup remove' by 'dmsetup --check close'
>> and see whether the shutdown process still hangs?
> 
> I guess you mean `dmsetup --checks remove "$dst"`, at least that's what
> I've found in my unstable version of dmsetup (2:1.02.110-2). But the
> result is the same, it still hangs.

If this happens, it probably means that for some reason there is missing
(of ignored)  "dmsetup udevcomplete" call in udev rules.

This call decreases internal semaphore allowing libdevampper process to 
continue.
(I see this in /lib/udev/rules.d/55-dm.rules on Debian, part of dmsetup 
package).

Isn't possible that you have this rule missing, or that there are installed
other udev rules interference with it?
(Note that rules probably differes from device-mapper upstream.)

Milan

Bug#809686: cryptsetup: --header plus UUID plus initramfs gives "Requested offset beyond size of device"

[Milan Broz]

On 01/02/2016 10:02 PM, Benjamin Moody wrote:

...
> (although, incidentally, to make the third command work I also had to
> add 'loop' to /etc/initramfs-tools/modules - for some reason
> cryptsetup-in-initramfs uses a loopback device to read the header
> file, although cryptsetup-in-Debian doesn't.

Note
> # Userspace crypto wrapper cannot use aes-xts-plain64 (-95).
> # Using dmcrypt to access keyslot area.

The reason is that you are missing kernel userspace crypto API modules
in initram (af_alg, algif_skcipher, ...), then cryptsetup fall back to using
dmcrypt-device for keyslot processing (that requires loop driver).



But the real problem:
> === broken cryptsetup log ===
> Enter passphrase for /dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e: 
> Requested offset is beyond real size of device 
> /dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e.

...
> # Key length 64, device size 4040 sectors, header size 4036 sectors.

Here apparently device size 4040 sectors is wrong (too small).

Please check where link /dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e 
is pointing,
check with blockdev --getsz .

I would say that udev created link to used loop device instead of your 
ciphertext device.

(In fact, your command is wrong. If the underlying device has no LUKS header on 
it,
there cannot be link with LUKS UUID to it! I would guess you have old LUKS 
header
on it as well so witout loop activated it work by chance..)

Milan

Bug#809686: cryptsetup: --header plus UUID plus initramfs gives "Requested offset beyond size of device"

[Milan Broz]

On 01/03/2016 12:48 AM, Benjamin Moody wrote:
> On 1/2/16, Milan Broz <gmazyl...@gmail.com> wrote:

> It might be sensible for the cryptsetup package to add the
> algif_skcipher module (or any others that might be needed?) to the
> initramfs automatically if a header file is used.

IMHO it should be added there always if cryptsetup is in initram.

> 
>> But the real problem:
>>> === broken cryptsetup log ===
>>> Enter passphrase for
>>> /dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e:
>>> Requested offset is beyond real size of device
>>> /dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e.
>>
>> ...
>>> # Key length 64, device size 4040 sectors, header size 4036 sectors.
>>
>> Here apparently device size 4040 sectors is wrong (too small).
> 
> No, this message seems to refer to the size of the header file; the
> same size is shown when it works properly.

Yep, you are right, I mishandled own debug print :)

...

> It might be wise for cryptsetup to chase the symlink passed on the
> command line before doing anything else, or for the initramfs scripts
> to do so.

Managing links is completely dynamic and asynchronous work of udev threads,
close-on-write causes rescan (so even cryptsetup cannot be sure that
the link points to the same device as in the beginning).

There can be perhaps more debug info (just it should not say too much info
about your device in debug log, it can be private info (HW UUID etc).)
 
>> (In fact, your command is wrong. If the underlying device has no LUKS header
>> on it, there cannot be link with LUKS UUID to it! I would guess you have old
>> LUKS header on it as well so witout loop activated it work by chance..)
> 
> Yep.  I originally created these partitions using a normal luksFormat,
> and then made copies of the headers (which, naturally, doesn't change
> the UUID.)  As I said before, I like having the header on the disk for
> recovery purposes; and I also think it's probably a good idea to
> identify the source partition by UUID or some similar labelling
> mechanism, though I see how this can be problematic.  I suppose one
> option, to avoid problems in the future, would be to change the UUID
> stored in the header file.

You can keep LUKS header on device and wipe (kill) all keyslots.
In this case the device has still UUID but you cannot open it without external
header.
(But you cannot rely on uuid symlinks apparently here. Or you can change UUID,
luksUUID command allows that.)

Milan

Bug#815480: cryptsetup: versions before 1.7.1 incompatible with latest batch of Linux kernels (mainline and stable)

[Milan Broz]

On 02/21/2016 09:40 PM, Henrique de Moraes Holschuh wrote:
> Source: cryptsetup
> Severity: important
> Tags: upstream fixed-upstream
> 
> This bug is actually severity grave as it renders systems unbootable and
> data unaccessible, but since it can only trigger on non-Debian kernels ATM,
> I am reporting it at severity important.
> 
> https://gitlab.com/cryptsetup/cryptsetup/issues/284
> https://bugzilla.kernel.org/show_bug.cgi?id=112631
> 
> cryptsetup is rendered useless by the latest batch of upstream stable
> kernels, as well as by Linux mainline.

Only some of stable kernels are problematic because of incomplete backported
patch series.

See http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg17926.html
(I tried to backport missing part there.)

There is no problem in mainline kernel and 4.4.2 and 4.3.6 stable works.

...

> Regardless, it would be nice to have updated cryptsetup uploaded to unstable
> ASAP, and an eventual Debian stable backport...

Debian kernel should be fixed in the first place.

Milan

Bug#888162: [pkg-cryptsetup-devel] Bug#888162: cryptsetup: `loopaesOpen --key-file=-` doesn't read the key from stdin but tries to open key file "./-"

[Milan Broz]

On 01/24/2018 02:15 PM, Guilhem Moulin wrote:
>  Currently blocking on #888072; if fixing that bug (or
> removing volume-key from testing) takes too long we'll make sure
> cryptsetup 2:2.0.0-1 doesn't migrate to testing by raising the severity
> of #888162.

This bug have patch in upstream volume-key (we had the same problem in Fedora
and I talked with volume-key maintainer directly), actually it is based on my 
fix.

I'll post there link for the patch.

m.

Bug#888072: volume-key FTBFS with cryptsetup 2:2.0.0-1

[Milan Broz]

The upstream patch (that is compatible with older libcryptsetup as well so can 
be applied globally) is here

https://pagure.io/volume_key/c/ecef526a51c5a276681472fd6df239570c9ce518?branch=master

Thanks,
Milan

Bug#888162: cryptsetup: `loopaesOpen --key-file=-` doesn't read the key from stdin but tries to open key file "./-"

[Milan Broz]

Fixed upstream in
https://gitlab.com/cryptsetup/cryptsetup/commit/8728ba08e2e056a4c18b55407146eea7ac0043c6

It would be nice if this patch is on added on top of 2.0.1 in Debian ;-)

In the meantime, you can trick the cryptsetup2 to use stdin just specifying 
"--key-file /dev/stdin"
instead of "--key-file -".

Thanks,
Milan

Bug#908917: cryptsetup: argon2id as default PBKDF setting for new installs - Buster+

[Milan Broz]

On 16/09/18 00:08, procmem wrote:
> The recommended config paramters by Milan Broz:
> 
>   # cryptsetup luksConvertKey --key-slot 1 --pbkdf argon2id
> --pbkdf-force-iterations 50 --pbkdf-memory 1048576 --pbkdf-parallel 4
> 

NO!

This was an example, as you asked how to setup keyslot parameters.

Seems you do not understand what we said to you.

Forced iteration should not be used, ditto for forced threads, it must be 
benchmarked.

Debian maintainers: please ignore this, it is nonsense.

Thanks.

Bug#923513: [pkg-cryptsetup-devel] Bug#923513: cryptsetup-bin: Can no longer luksFormat as non-root: "Not compatible PBKDF options."

[Milan Broz]

On 02/03/2019 11:23, Christoph Biedl wrote:
> Thanks for looking into this and the insights given. For luksmeta
> however ... it's "to access metadata in a LUKSv1 header", and before the
> buster release I better shall refrain from checking how the related
> tools like clevis deal with LUKSv2 headers  B-)

Clevis/Tang already supports direct metadata store to LUKS2 token objects
(so the luksmeta package is obsolete for LUKS2 format).

IIRC they use cryptsetup token command in the wrapper.

Milan

Bug#923513: cryptsetup-bin: Can no longer luksFormat as non-root: "Not compatible PBKDF options."

[Milan Broz]

On 01/03/2019 11:09, Christoph Biedl wrote:
> $ echo foo | /sbin/cryptsetup luksFormat /tmp/blob -
> 
> Error message:
> Not compatible PBKDF options.

Please could you add --debug option and post output?
(If it is an upstream bug, I'll fix it directly there.)

BTW using LUKS2 with luksmeta does not make sense (there will be no gap for 
your metadata),
so you should use --type luks1 anyway.

Thanks,
Milan

Bug#924560: [pkg-cryptsetup-devel] Bug#924560: cryptsetup luksOpen requires 1GB of RAM in the default configuration

[Milan Broz]

>> I think diverging from upstream (and other distros) with respect to
>> default algorithms requires careful consideration.  And in that case,
>> compared to PBKDF2 Argon2 has interesting properties (such as resistance
>> to GPU cracking) which would be a shame not to benefit from out of the
>> box.

For this case you need to specify PBKDF parameters directly and skip benchmark
(these PBKDF options were added exactly for this use case).

This problem is there even with PBKDF2 for the iterations time - on some
IoT devices with LUKS device (formatted on developer's machine) the unlocking
time increases to many minutes. (With Argon PBKDF it is just worse because 
memory
can be unavailable.)

So the suggestion above is correct - you need to measure some viable
parameters and use them directly.

If you run luksFormat on a small IoT system directly, it trims parameters and
memory use according to system (it will never use more than half of physical
available memory).
...

> I guess dracut with systemd in the initrd might be affected worse,
> than initramfs-tools. I wonder if I should open a bug report in
> systemd, to potentially execute luks2 unlock with some locking /
> sequentially.

FYI we know about that parallel unlocking problem already and we are trying
to find (with systemd people) some solution (perhaps based on cgroups memory 
limits
and some locking).
(Parallel unlocking can cause OOM killer to kill even different processes here.)

You can change PBKDF parameters for existing device (preserving data) with
cryptsetup luksConvertKey command, it takes the same PBKDF options.
(So you can "downgrade" to PBKDF2 or decrease limits.)

Milan

Bug#935702: [pkg-cryptsetup-devel] Bug#935702: Wrong DM device size due to integer truncation

[Milan Broz]

On 26/08/2019 03:28, Guilhem Moulin wrote:
> On Sun, 25 Aug 2019 at 12:43:26 +, n...@waifu.club wrote:
>> Not only the access to protected data is lost, the integritysetup's "open"
>> operation actually succeeds. All reads on the incorrectly created DM device
>> will of course fail with I/O errors due to bad integrity tags, but all
>> writes will happily write wrong tags at wrong places! This makes it very
>> easy for the administrator to destroy the data while trying to recover with
>> --integrity-recovery-mode.
> 
> Would you mind sharing your test vector, either here or the upstream bug
> tracker at https://gitlab.com/cryptsetup/cryptsetup/issues ?  While it's
> clear there is a bug, I was unable to reproduce your observations in the
> arguably most common cases, namely block devices formatted as LUKS1 or
> LUKS2 with the default parameters (and a payload size exceeding ≥2³²
> 512-bits sectors).  The only function of the dm_*_target_set() family
> called is dm_crypt_target_set(), and always with 0 as segment offset and
> size.

No need to report it upstream, I'll fix it. This is really stupid bug, all 
sizes in code
must be uint_64t. I just wonder why no static analysis screamed here, I run it 
on 32bit...

Thanks for the report!

m.

Bug#935702: [pkg-cryptsetup-devel] Bug#935702: Wrong DM device size due to integer truncation

[Milan Broz]

On 26/08/2019 08:03, Milan Broz wrote:
> No need to report it upstream, I'll fix it. This is really stupid bug, all 
> sizes in code
> must be uint_64t. I just wonder why no static analysis screamed here, I run 
> it on 32bit...

Fixed here 
https://gitlab.com/cryptsetup/cryptsetup/commit/8f8f0b3258152a260c6a40be89b485f943f81484

I'll do minor release soon, but perhaps it would be better to cherrypick the 
patch directly.
(It should be possible to apply it to 2.1.0/2.2.0)

m.

Bug#932437: LUKS formatting of a 16 MB (sic!) device is possible, open not

[Milan Broz]

On 19/07/2019 12:40, Marc Haber wrote:
> I would like to luksFormat a really tiny device (which will only hold a
> single file) with LUKS or LUKS2. I have been doing this multiple times
> in the past, and was surprised that it doesn't work any more with
> current cryptsetup.

Default header size is much bigger because it reserves space for more
keyslots and optionally online reencryption. But it can be changed.

You can now create even smaller device with LUKS2, if you are
ok with a very small metadata size and only one keyslot (size of keyslot 
depends on
a key size, example is for XTS 512bit key).

I am able to create just 1MB LUKS header this way:

  cryptsetup luksFormat --type luks2 --luks2-metadata-size=16k 
--luks2-keyslots-size=256k img

or even smaller (here <300 kB), if you ignore default 1MB alignment

  cryptsetup luksFormat --type luks2 --luks2-metadata-size=16k 
--luks2-keyslots-size=256k --align-payload=1 img

> cryptsetup should be more clear about minimum space requirement, and it
> should use them consistently. Having a minimum size is ok, if I know of
> it, and being able to format but not open a device because it's too
> small is a bug.

For detached header you must be able to format header only (no data area).

But for the normal device, it is a bug, it should not format device and then 
complain
that it is too small :)

Also I think we should print default header size in --help output...

Anyway, this is upstream bug, so if you want to fill an issue for us, tracker
is here https://gitlab.com/cryptsetup/cryptsetup/issues

Thanks,
Milan

Bug#949336: Mapped integrity devices of size ≥2TiB are unusable on 32-bits platforms

[Milan Broz]

On 20/01/2020 14:11, Guilhem Moulin wrote:
> Milan, should I forward that upstream (verbatim)?

Sure, put it to the upstream, issue tracker , but I definitely need a clear 
reproducer (with the latest stable - 2.2.2 or 2.3.0-rc0) - ideally with 
attached debug and system log.
(Debug log will provide all versions I need - kernel and dm targets versions 
are important here)

It could be also kernel problem, so if you can attach .config for the kernel, 
it helps.

Milan

Bug#941051: cryptsetup: luksFormat crash with benbi IV generator and LUKS2 integrity option(s)

[Milan Broz]

Hi,

this is an apparent bug in upstream kernel.

I fixed it in my git, please could you verify it works for you? Patch is in 
this branch:
  
https://git.kernel.org/pub/scm/linux/kernel/git/mbroz/linux.git/log/?h=dm-cryptsetup

(and let me know if you want to add reported-and-tested-by tag with your name)

Thanks for the report!

Milan

Bug#941051: cryptsetup: luksFormat crash with benbi IV generator and LUKS2 integrity option(s)

[Milan Broz]

I sent patch upstream, if you could, please reply directly to the dm-devel list:

https://www.redhat.com/archives/dm-devel/2020-January/msg00012.html

Thanks!

Milan

Bug#969471: cryptsetup: CVE-2020-14382

[Milan Broz]

FYI There will be upstream stable release in a few hours fixing this.

If you are going to only backport the fix for this CVE, these master branch
git commits should be backported (the fix with followed simplification
of the validation code).

52f5cb8cedf22fb3e14c744814ec8af7614146c7
46ee71edcd13e1dad50815ad65c28779aa6f7503
752c9a52798f11d3b765b673ebaa3058eb25316e

Milan

Bug#941814: libpopt: leaks memory for leftover arguments

[Milan Broz]

Hello,

what's the status of the fix/patch in this bug?

We see many leaks for cryptsetup in valgrind tests if running under Debian
(while other distros apparently do not have this problem) and it seems
all reported problems are with poptGetNextOpt ...

Thanks,
Milan

Bug#996177: cryptsetup: please report fatal errors without having to use -v

[Milan Broz]

On 11/10/2021 22:09, Marc Lehmann wrote:
> 
> Specifically, the machine didn't have enough ram, probably because the
> default algorithm (argon) requires more ram than the machine had.
> 
> Unfortunately, cryptsetup silently fails - you get a password prompt, youc
> an enter any password, your shell prompt appears without any message but
> nothing happened.

If the process was killed by OOM (out of memory daemon), then it cannot
print anything - it is simply stopped by the kernel.

But if it really fails with return code 3 (out of memory), then it should print
a visible error - if not, we have to fix it.
(Verbose option only translates return code to something readable but there 
should
be an error message much earlier.)

Is it simple cryptsetup open activation (no systemd-cryptsetup magic)?
(If so, please add new issue upstream and link this bug, we will fix that.)

Thanks,
Milan

Bug#1003273: pipewire: headset mic not working

[Milan Broz]

On 27/01/2022 16:41, Dylan Aïssi wrote:


Pipewire 0.3.43 is now in testing, this version includes f8cdc05720bf1.
Could you check if it works without having to modify the config file?


I had the same problem - not working USB Jabra conference speakers.
(My workaround was to stay with pipewire 0.3.19-4, no changes in config.)

With 0.3.44-1 from unstable it works again.

Thanks!

Milan

Bug#1014675: thunderbird: Upgrade breaks NNTP

[Milan Broz]

Today's unstable update to 102.0.2-1 breaks NNTP completely for me.

Reading the upstream bug link, I tried to disable master password, then
it was somehow able to connect to one server, but never to others (I have 3 
NNTP accounts in my profile).

So this is a quite major regression...

Milan

Bug#1016474: cryptsetup: The system installed on encrypted LVM (both root and swap partitions) freezes during massive writes

[Milan Broz]

On 01/08/2022 23:00, Wojciech Zabołotny wrote:

Probably the number of affected people is quite big, but they have
simply accepted this situation.


This is much more complicated. The problem with the "freezing" system while 
writing to a dm-crypt device (whatever type) is not new, but also it is not one problem.
I know about several issues that caused this, and most of them should be fixed. 
Some are related to specific HW only.

Please do not mix observation now and years ago - always use a new kernel, and 
always describe what you see *now*.
The dm-crypt was several times heavily optimized for parallel processing, and 
each change usually caused another problem in some other specific situation :-)
If you can reproduce it reliably with new upstream kernel, please report it to 
the dm-devel list.

Just in short, what I know:

1) there was a problem that dm-crypt allocated too much IO in progress (and memory), and 
flushing the device causes "freezes" or OOM.
This should be fixed (in 2018) in recent kernels, and dm-crypt internally 
limits maximal allocated memory.

2) I remember that on AMD CPUs was a problem with the queue handling; the 
workaround was using that dm-crypt performance option.
(IIRC, nobody from DM devels was able to reproduce it, not sure if because of 
lack of HW or other reasons.)

3) External drives connected through USB cause problems, but this happens even 
without dm-crypt - encryption only worsens it.
It is a problem how USB handles storage devices; I do not think the problem is 
in dm-crypt itself.


There were a lot of problems with crypto algorithm drivers allocating memory on 
the hot path (these should not be used by dm-crypt anymore) or bad 
implementations (notable QAT driver that only recently was fixed).

Setting blocks device scheduler (CFQ, none) has also had an impact here.
Rotational drives behave completely differently from SSD and NVME.
...

TLDR: Reproducing issues is usually very complicated, usually it is something 
specific specific for your system - if you can help, please send report to 
dm-devel list.

Cryptsetup cannot "optimize" any performance flags to use, this would fix one 
issue and cause many others.

Milan

Bug#1016688: dieharder -h segfaults

[Milan Broz]

Package: dieharder
Version: 3.31.1.2-1+b1
Severity: normal

Dear Maintainer,

dieharder utility segfaults if standalone help (-h) option is used.

$ dieharder -h
Segmentation fault (core dumped)

Fix is trivial, see patch here
https://github.com/mbroz/dieharder/commit/3323d0d5ec0350f977d6dbe0fb20f6e7e4ad0e8a

(I can do pull request if you prefer.)

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.15 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dieharder depends on:
ii  libc6  2.33-8
ii  libdieharder3  3.31.1.2-1+b1
ii  libgsl27   2.7.1+dfsg-3

dieharder recommends no packages.

dieharder suggests no packages.

-- no debconf information

Bug#1016688: Acknowledgement (dieharder -h segfaults)

[Milan Broz]

Actually this patch is better, just displays usage and also check upper 
boundary (another segault with -d 10 ...)

https://github.com/mbroz/dieharder/commit/7d60208c8a8beabe6d3d5a88399b83ebf03240a5

Bug#1022703: dieharder: Broken output or infinite loop after sts_runs test

[Milan Broz]

We have the same issue with empty lines, temporarily workarounded by adding 
-fcommon to CFLAGS (on several places)
(so yes, it was gcc-10 introduced problem).

But that off_t fix works too, thanks!

Milan

Bug#1022703: dieharder: Broken output or infinite loop after sts_runs test

[Milan Broz]

On 12/13/22 14:30, Dirk Eddelbuettel wrote:


On 13 December 2022 at 14:23, Milan Broz wrote:
| We have the same issue with empty lines, temporarily workarounded by adding 
-fcommon to CFLAGS (on several places)
| (so yes, it was gcc-10 introduced problem).

:-/

| But that off_t fix works too, thanks!

But are you saying it is currently 'good' and fixed?  (There were two more
pending PR changes I belatedly merged yesterday.)


Yes, it is fixed in your "upstream" master branch.

For reference, my workaround was
https://github.com/crocs-muni/rtt-statistical-batteries/commit/80386d016073aca5d2e1570a9906f931b24b0589
(the patch is not needed anymore)

Milan

Bug#1032221: [pkg-cryptsetup-devel] Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work

[Milan Broz]

Just FYI - I think that the whole problem can be avoided by merging this patch
https://github.com/P-H-C/phc-winner-argon2/pull/331

(we have the patch applied in cryptsetup for embedded libargon already).

Just upstream is no longer responding here...

Milan

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Milan Broz]

On 4/12/24 9:11 AM, Jan Katins wrote:

I snooped around in the source code a bit and found that libgcc_s
seems to be dlopened and is special cased:
https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/master/hook-functions?ref_type=heads#L248-249
(original bugreport:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254). So my guess
is that nothing depends on libpthread anymore,


Just FYI (for upstream code): if cryptsetup/libcryptsetup is linked with OpenSSL 
>= 3.2,
it does not need libphtread (as threads are implemented in OpenSSL for Argon2 
internally).
Ditto for libargon2 and possible dependences of above (libgcc_s).

So if the reason is cryptsetup, all these dependences should be removed, we do 
not need it anymore.

Milan

Bug#1061592: It is a Plymouth Bug

[Milan Broz]

On 5/12/24 1:47 PM, Wolfgang Zarre wrote:

I am facing the very same issue however, I discovered that this is a bug
in plymouth version => 24.004.60-1, because if you install plymouth
version 22.02.122-3 including label and themes from 'bookworm' then
everything works as expected.


Yes, this stupid thing should be fixed in

https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/303

Milan

Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17

[Milan Broz]

On 4/6/24 4:33 PM, Lucas Thode wrote:
...

$ ./dieharder/dieharder -d 209 -n 17 -p 1
#=#
#            dieharder version 3.31.1 Copyright 2003 Robert G. Brown          #
#=#
    rng_name    |rands/second|   Seed   |
         mt19937|  1.75e+08  |2063877943|
#=#
         test_name   |ntup| tsamples |psamples|  p-value |Assessment
#=#
         dab_monobit2|  17|  6500|       1|1.|  FAILED


This should not be possible.

Are you sure you run the patched version with patched libdieharder (and not one 
from system)?
You can avoid it by "./configure --disable-shared" to force static link.

This is what I get from current code
(https://github.com/eddelbuettel/dieharder):

./dieharder/dieharder -d 209 -n 17 -p 1
Error:  Can only use ntup up to 15.
Read test description with dieharder -d 209 -h.

Milan

Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17

[Milan Broz]

On 4/6/24 5:34 PM, Lucas Thode wrote:

Even when built a statically linked libdieharder, I still get bogus results 
(using yesterday's HEAD):


Why yesterday's? The patch landed today. git pull?

The last patch in git log should be "Avoid overflow in DAB Monobit2 test."

With older code anything with -d 209 and -n over 15 corrupts memory and cannot 
get
any useful output.

Milan

Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17

[Milan Broz]

Hi,

the DAB Monobit2 test cannot use ntup higher thtn 15 due to the fixed 
allocations.

(It means it calculates data for block sizes up to 2^ntup blocks, so it make 
kind-of sense.)

I added check to prevent overflow, this is perhaps the best we can do here
(more details in description), see:

https://github.com/eddelbuettel/dieharder/pull/24

Milan