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

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.

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

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

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

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

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

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?

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

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... -

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bug#577923: cryptsetup is too chatty

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.

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

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

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

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

Bug#590290: lvdisplay leaking file descriptors

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.

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

Bug#624828: cryptsetup ignores --size option

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

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

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

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

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_

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

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

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

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

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

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

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

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

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

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

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

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

Bug#677127: relocation error

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

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

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

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

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

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

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

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

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

Bug#713852: dmsetup remove nonexistent_device waits forever

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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 use

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

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

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

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

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

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 "./-"

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

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

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 key

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

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

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

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

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

>> 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 >>

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

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

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

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/crypt

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

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

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

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

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

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

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

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

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

Bug#941814: libpopt: leaks memory for leftover arguments

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

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

Bug#1003273: pipewire: headset mic not working

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

Bug#1014675: thunderbird: Upgrade breaks NNTP

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

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

Bug#1016688: dieharder -h segfaults

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

Bug#1016688: Acknowledgement (dieharder -h segfaults)

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

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

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

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

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#1068117: dieharder: dab_monobit2 crashes with ntuple > 17

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          #

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

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

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

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:

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

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:

Bug#1061592: It is a Plymouth Bug

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