[dm-crypt] [ANNOUNCE] cryptsetup 2.0.3

[dm-crypt] [ANNOUNCE] cryptsetup 2.0.3

[Milan Broz]

[-- Attachment #1.1: Type: text/plain, Size: 5461 bytes --]

Cryptsetup 2.0.3 Release Notes
==============================
Stable bug-fix release with new features.

Cryptsetup 2.x version introduces a new on-disk LUKS2 format.

The legacy LUKS (referenced as LUKS1) will be fully supported
forever as well as a traditional and fully backward compatible format.

Please note that authenticated disk encryption, non-cryptographic
data integrity protection (dm-integrity), use of Argon2 Password-Based
Key Derivation Function and the LUKS2 on-disk format itself are new
features and can contain some bugs.

To provide all security features of authenticated encryption, we need
a better nonce-reuse resistant algorithm in the kernel (see note below).
For now, please use authenticated encryption as an experimental feature.

Please do not use LUKS2 without properly configured backup or in
production systems that need to be compatible with older systems.

Changes since version 2.0.2
~~~~~~~~~~~~~~~~~~~~~~~~~~~

* Expose interface to unbound LUKS2 keyslots.
  Unbound LUKS2 keyslot allows storing a key material that is independent
  of master volume key (it is not bound to encrypted data segment).

* New API extensions for unbound keyslots (LUKS2 only)
  crypt_keyslot_get_key_size() and crypt_volume_key_get()
  These functions allow to get key and key size for unbound keyslots.

* New enum value CRYPT_SLOT_UNBOUND for keyslot status (LUKS2 only).

* Add --unbound keyslot option to the cryptsetup luksAddKey command.

* Add crypt_get_active_integrity_failures() call to get integrity
  failure count for dm-integrity devices.

* Add crypt_get_pbkdf_default() function to get per-type PBKDF default
  setting.

* Add new flag to crypt_keyslot_add_by_key() to force update device
  volume key. This call is mainly intended for a wrapped key change.

* Allow volume key store in a file with cryptsetup.
  The --dump-master-key together with --master-key-file allows cryptsetup
  to store the binary volume key to a file instead of standard output.

* Add support detached header for cryptsetup-reencrypt command.

* Fix VeraCrypt PIM handling - use proper iterations count formula
  for PBKDF2-SHA512 and PBKDF2-Whirlpool used in system volumes.

* Fix cryptsetup tcryptDump for VeraCrypt PIM (support --veracrypt-pim).

* Add --with-default-luks-format configure time option.
  (Option to override default LUKS format version.)

* Fix LUKS version conversion for detached (and trimmed) LUKS headers.

* Add luksConvertKey cryptsetup command that converts specific keyslot
  from one PBKDF to another.

* Do not allow conversion to LUKS2 if LUKSMETA (external tool metadata)
  header is detected.

* More cleanup and hardening of LUKS2 keyslot specific validation options.
  Add more checks for cipher validity before writing metadata on-disk.

* Do not allow LUKS1 version downconversion if the header contains tokens.

* Add "paes" family ciphers (AES wrapped key scheme for mainframes)
  to allowed ciphers.
  Specific wrapped ley configuration logic must be done by 3rd party tool,
  LUKS2 stores only keyslot material and allow activation of the device.

* Add support for --check-at-most-once option (kernel 4.17) to veritysetup.
  This flag can be dangerous; if you can control underlying device
  (you can change its content after it was verified) it will no longer
  prevent reading tampered data and also it does not prevent silent
  data corruptions that appear after the block was once read.

* Fix return code (EPERM instead of EINVAL) and retry count for bad
  passphrase on non-tty input.

* Enable support for FEC decoding in veritysetup to check dm-verity devices
  with additional Reed-Solomon code in userspace (verify command).

Unfinished things & TODO for next releases
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* There will be better documentation and examples (planned for 2.0.4).

* There will be some more formal definition of the threat model for integrity
  protection. (And a link to some papers discussing integrity protection,
  once it is, hopefully, accepted and published.)

* Authenticated encryption will use new algorithms from CAESAR competition
  https://competitions.cr.yp.to/caesar-submissions.html.
  We plan to use AEGIS and MORUS, as CAESAR finalists.

  NOTE: Currently available authenticated modes (GCM, Chacha20-poly1305)
  in the kernel have too small 96-bit nonces that are problematic with
  randomly generated IVs (the collision probability is not negligible).

* Authenticated encryption do not set encryption for a dm-integrity journal.

  While it does not influence data confidentiality or integrity protection,
  an attacker can get some more information from data journal or cause that
  system will corrupt sectors after journal replay. (That corruption will be
  detected though.)

* There are examples of user-defined tokens inside misc/luks2_keyslot_example
  directory (like a simple external program that uses libssh to unlock LUKS2
  using remote keyfile).

* The python binding (pycryptsetup) contains only basic functionality for LUKS1
  (it is not updated for new features) and will be REMOVED in version 2.1
  in favor of python bindings to the libblockdev library.
  See https://github.com/storaged-project/libblockdev/releases/tag/2.17-1 that
  already supports LUKS2 and VeraCrypt devices handling through libcryptsetup.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[dm-crypt] Mildly OT: LUKS and the Debian installer

[Diagon]

So I'm doing something that I've done many times with Ubuntu.  That is,
preparing my disks in the live system (usually /boot on a USB stick and
/ on luks, no partition table on that second drive), then running the
install, and finally pivoting in to fix crypttab and update the initramfs.

After many tries with the debian installer, I've almost been able to get
this to work, though it does need some tending to to get there.  The
problem comes after I've pivoted in.  I install cryptsetup, as I find
that it's not there, and then correct crypttab/initramfs.  Oddly, I find
the initramfs does not include cryptsetup.  Hmmm.

I'm getting crickets on the Debian user list, but I figure someone here
must have done something like this.  Any hope I might find help?

/D

Re: [dm-crypt] Mildly OT: LUKS and the Debian installer

[Arno Wagner]

The only advice I have is to roll your own initrd.
Not that hard, at least with sysVinit (no idea about 
systemd, I do not use it). 
FAQ Chapter 9 gives some pointers:

https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#9-the-initrd-question

Regards,
Arno

On Tue, May 22, 2018 at 09:50:39 CEST, Diagon wrote:
> So I'm doing something that I've done many times with Ubuntu.  That is,
> preparing my disks in the live system (usually /boot on a USB stick and
> / on luks, no partition table on that second drive), then running the
> install, and finally pivoting in to fix crypttab and update the initramfs.
> 
> After many tries with the debian installer, I've almost been able to get
> this to work, though it does need some tending to to get there.  The
> problem comes after I've pivoted in.  I install cryptsetup, as I find
> that it's not there, and then correct crypttab/initramfs.  Oddly, I find
> the initramfs does not include cryptsetup.  Hmmm.
> 
> I'm getting crickets on the Debian user list, but I figure someone here
> must have done something like this.  Any hope I might find help?
> 
> /D
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Mildly OT: LUKS and the Debian installer

[Jonas Meurer]

[-- Attachment #1.1: Type: text/plain, Size: 1463 bytes --]

Hi Diagon,

Am 22.05.2018 um 09:50 schrieb Diagon:
> So I'm doing something that I've done many times with Ubuntu.  That is,
> preparing my disks in the live system (usually /boot on a USB stick and
> / on luks, no partition table on that second drive), then running the
> install, and finally pivoting in to fix crypttab and update the initramfs.
> 
> After many tries with the debian installer, I've almost been able to get
> this to work, though it does need some tending to to get there.  The
> problem comes after I've pivoted in.  I install cryptsetup, as I find
> that it's not there, and then correct crypttab/initramfs.  Oddly, I find
> the initramfs does not include cryptsetup.  Hmmm.

You mean the initramfs created by debian-installer? Have you tried
recreating the initramfs from the installed system? 'update-initramfs
-u' recreates the initramfs for latest installed kernel.

If you have cryptsetup installed and an encrypted rootfs, cryptsetup
should be added to the initramfs automatically. If it doesn't, please
file a bug against cryptsetup to the Debian bugtracking system
(bugs.debian.org).

In case you file a bug, please do the following in advance:

* change the shebang in /usr/sbin/mkinitramfs to '#!/bin/sh -x'
* run 'update-initramfs -u >/tmp/mkinitramfs.log 2>&1'
* attach '/tmp/mkinitramfs.log' to the bugreport
* (don't forget to change back the shebang of mkinitramfs afterwards)

Cheers,
 jonas


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [dm-crypt] Mildly OT: LUKS and the Debian installer

[Diagon]

On 05/22/2018 02:26 AM, Jonas Meurer - jonas@freesources.org wrote:
> Hi Diagon,
> 
> Am 22.05.2018 um 09:50 schrieb Diagon:
>> So I'm doing something that I've done many times with Ubuntu.  That is,
>> preparing my disks in the live system (usually /boot on a USB stick and
>> / on luks, no partition table on that second drive), then running the
>> install, and finally pivoting in to fix crypttab and update the initramfs.
>>
>> After many tries with the debian installer, I've almost been able to get
>> this to work, though it does need some tending to to get there.  The
>> problem comes after I've pivoted in.  I install cryptsetup, as I find
>> that it's not there, and then correct crypttab/initramfs.  Oddly, I find
>> the initramfs does not include cryptsetup.  Hmmm.
> 
> You mean the initramfs created by debian-installer? Have you tried
> recreating the initramfs from the installed system? 'update-initramfs
> -u' recreates the initramfs for latest installed kernel.

Yes, as I say.  I pivot into the system after the installer is done.
Then I install cryptsetup, create the crypttab and `update-initramfs -k
all -v -c`

> If you have cryptsetup installed and an encrypted rootfs, cryptsetup
> should be added to the initramfs automatically. 

No, that doesn't happen.  Neither with the installer nor when I pivot in
later.

I do not expect it to happen with the installer, and here's why.  I
create the encrypted container myself since the debian installer only
allows me to create an encrypted container /in a partition/ and also has
limited options available.  So I create the container before, and then
do the install. It's delicate with Debian, but I can get the installer
to recognize my /dev/mapper/luks.root and install there.  But it does
not recognize that this is an encrypted container, so it does not
include cryptsetup in the install (or the resulting initramfs).  I have
tried other things, like dropping to the shell during the install to
edit the cryptab and `apt-install cryptsetup`, but none of that helps.

The Ubuntu installer is much more straightforward, but also fails to
create a proper initramfs; though I can fix it later by pivoting in.
The odd thing is that with Debian I can't.

> If it doesn't, please
> file a bug against cryptsetup to the Debian bugtracking system
> (bugs.debian.org).

I am not sure what I am to say the bug is.  It's rather mysterious to me
that the tactics I have used in the past are failing.  Maybe the problem
is with the installer?

> In case you file a bug, please do the following in advance:
> 
> * change the shebang in /usr/sbin/mkinitramfs to '#!/bin/sh -x'
> * run 'update-initramfs -u >/tmp/mkinitramfs.log 2>&1'
> * attach '/tmp/mkinitramfs.log' to the bugreport
> * (don't forget to change back the shebang of mkinitramfs afterwards)
> 
> Cheers,
>  jonas

Re: [dm-crypt] Mildly OT: LUKS and the Debian installer

[Diagon]

On 05/22/2018 01:53 AM, Arno Wagner - arno@wagner.name wrote:

> The only advice I have is to roll your own initrd.
> Not that hard, at least with sysVinit (no idea about 
> systemd, I do not use it). 
> FAQ Chapter 9 gives some pointers:
> 
> https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#9-the-initrd-question

Arno- I thank you for the input, and may consider it if I can't make any
other headway.  Regarding systemd, the reason I ended up at Debian is
that I was trying to install Devuan.  I failed there, and they told me
that their installer had not been forked from Debian, so any issues
should be raised there.  So I tried the same things in Debian and had
the same problems.  But then, why not in Ubuntu?

> Regards,
> Arno
> 
> On Tue, May 22, 2018 at 09:50:39 CEST, Diagon wrote:
>> So I'm doing something that I've done many times with Ubuntu.  That is,
>> preparing my disks in the live system (usually /boot on a USB stick and
>> / on luks, no partition table on that second drive), then running the
>> install, and finally pivoting in to fix crypttab and update the initramfs.
>>
>> After many tries with the debian installer, I've almost been able to get
>> this to work, though it does need some tending to to get there.  The
>> problem comes after I've pivoted in.  I install cryptsetup, as I find
>> that it's not there, and then correct crypttab/initramfs.  Oddly, I find
>> the initramfs does not include cryptsetup.  Hmmm.
>>
>> I'm getting crickets on the Debian user list, but I figure someone here
>> must have done something like this.  Any hope I might find help?
>>
>> /D

Re: [dm-crypt] Mildly OT: LUKS and the Debian installer

[Michael Ranft]

On Dienstag, 22. Mai 2018 00:50:39 CEST Diagon wrote:
> So I'm doing something that I've done many times with Ubuntu.  That is,
> preparing my disks in the live system (usually /boot on a USB stick and
> / on luks, no partition table on that second drive), then running the
> install, and finally pivoting in to fix crypttab and update the initramfs.
> 
> After many tries with the debian installer, I've almost been able to get
> this to work, though it does need some tending to to get there.  The
> problem comes after I've pivoted in.  I install cryptsetup, as I find
> that it's not there, and then correct crypttab/initramfs.  Oddly, I find
> the initramfs does not include cryptsetup.  Hmmm.
> 
> I'm getting crickets on the Debian user list, but I figure someone here
> must have done something like this.  Any hope I might find help?
> 
> /D


I did a similar thing with ascii 2 weeks ago (and wheezy years ago, ) because 
I wanted different cryptsetup parameters than the installer offered: plain-dm 
(no LUKS), hash sha512 and size 512.
So I started the installer and did every step of it, including the 
partitioning of crypted devices and choosing the modules for encryption etc 
before.
I stopped right before "install base-system". I opened a shell and copied 
_all_ installed files and dirs of the new system (under /target: crypttab 
etc). to secure them, then I destroyed the partitions with the unwanted 
cryptsetup parameters and recreated them with the new params, modified 
crypttab as desired.
Then I proceeded with "install base system" and the following steps as usual.
A minor difference: I used plain-dm-crypt and an underlying software raid 
(mdadm etc). System runs fine and performance is more than acceptable (x220/i5 
with 850 pro/840evo).
HTH
Michael

Re: [dm-crypt] Mildly OT: LUKS and the Debian installer

[Diagon]

On 05/22/2018 12:58 PM, Michael Ranft - m@michaelranft.com wrote:
> On Dienstag, 22. Mai 2018 00:50:39 CEST Diagon wrote:
>> So I'm doing something that I've done many times with Ubuntu.  That is,
>> preparing my disks in the live system (usually /boot on a USB stick and
>> / on luks, no partition table on that second drive), then running the
>> install, and finally pivoting in to fix crypttab and update the initramfs.
>>
>> After many tries with the debian installer, I've almost been able to get
>> this to work, though it does need some tending to to get there.  The
>> problem comes after I've pivoted in.  I install cryptsetup, as I find
>> that it's not there, and then correct crypttab/initramfs.  Oddly, I find
>> the initramfs does not include cryptsetup.  Hmmm.
>>
>> I'm getting crickets on the Debian user list, but I figure someone here
>> must have done something like this.  Any hope I might find help?
>>
>> /D
> 
> 
> I did a similar thing with ascii 2 weeks ago (and wheezy years ago, ) because 
> I wanted different cryptsetup parameters than the installer offered: plain-dm 
> (no LUKS), hash sha512 and size 512.
> So I started the installer and did every step of it, including the 
> partitioning of crypted devices and choosing the modules for encryption etc 
> before.
> I stopped right before "install base-system". I opened a shell and copied 
> _all_ installed files and dirs of the new system (under /target: crypttab 
> etc). to secure them, then I destroyed the partitions with the unwanted 
> cryptsetup parameters and recreated them with the new params, modified 
> crypttab as desired.
> Then I proceeded with "install base system" and the following steps as usual.
> A minor difference: I used plain-dm-crypt and an underlying software raid 
> (mdadm etc). System runs fine and performance is more than acceptable (x220/i5 
> with 850 pro/840evo).
> HTH
> Michael

Michael - I found the solution, which works on both Debian and Devuan.
I was given some kind help by someone on the Debian user's list, which I
am copying here:

------------
In the file “/etc/cryptsetup-initramfs/conf-hook”, there is a line
“CRYPTSETUP” which is commented and/or has the default value “n”. If
this is the case, replace the line with “CRYPTSETUP=y”. So, the next use
of the command “update-initramfs” should solve your problem if I
understood it correctly.

I think “CRYPTSETUP=y” is automatically set if you create an encrypted
partition by following the installer’s instructions, but not when you do
it outside these instructions.
----------

So, to explain my process for anyone who comes this way ...

(1) Create encrypted containers as needed using a live system.  Make
sure to create the filesystem you want in the containers
(2) Start the installer and run through "Load Installer Components".
Make sure you have loaded crypto-dm-modules
(3) Continue the installation through "Detect Hard Drives"
(4) Drop to the shell and run 'anna-install cryptsetup-udeb'.  Then open
your encrypted containers.
(5) Return and run "Detect Hard Drives" again.
(6) Continue to the partitioner.  You will see your /dev/mapper
device(s) listed.  Note that if there is no filesystem in the device,
when you select it, the partitioner will want to create a partition in
there.
(7) Now you can do the rest of the install, though the installer will
not recognize that cryptsetup has to be included.

While I exited the install and then pivoted in to 'apt-get install
cryptsetup', fix the crypttab/fstab and
/etc/cryptsetup-initramfs/conf-hook, after which I update-initramfs and
update-grub, someone else may want to see if it is possible to finish
the process through the installer.  You may be able to do it like this:

(8) After "Select and Install Software", drop to a shell and
'apt-install cryptsetup'.  Then edit cryptab/fstab and fix
/etc/cryptsetup-initramfs/conf-hook as describe above.
(9) Exit the shell and return to finish the install.

My guess is it may work.

/D

Re: [dm-crypt] sane distro-installer options for cryptsetup was: Mildly OT: LUKS and the Debian installer

[Michael Ranft]

On Mittwoch, 23. Mai 2018 01:18:55 CEST Diagon wrote:
> On 05/22/2018 12:58 PM, Michael Ranft - m@michaelranft.com wrote:
> > [...]
> 
> Michael - I found the solution, which works on both Debian and Devuan.
> I was given some kind help by someone on the Debian user's list, which I
> am copying here:
> [...]
> 
> So, to explain my process for anyone who comes this way ...
>  [...]

Glad to hear and good to know.

The installer options  for dm-crypt in  De[vu,bi]an seem a bit outdated, or at 
least not the standard dm-crypt is providing.
The maintainer is hopefully aware of that. 
Performance trade-off is IMHO not a sane reason for for example using hashsize 
of 128 or 256 and hash sha<512 nowadays. Maybe for raspi ...

I would really like to know what others (esp. Arno and Milan) would recommend 
to use as a mnimum for a today's new installation (in a distro's installer), 
may it be plain or LUKS[2].

Re: [dm-crypt] sane distro-installer options for cryptsetup was: Mildly OT: LUKS and the Debian installer

[Michael Ranft]

On Mittwoch, 23. Mai 2018 18:21:06 CEST Michael Ranft wrote:
> On Mittwoch, 23. Mai 2018 01:18:55 CEST Diagon wrote:
> > On 05/22/2018 12:58 PM, Michael Ranft - m@michaelranft.com wrote:
> > > [...]
> > 
> > Michael - I found the solution, which works on both Debian and Devuan.
> > I was given some kind help by someone on the Debian user's list, which I
> > am copying here:
> > [...]
> > 
> > So, to explain my process for anyone who comes this way ...
> > 
> >  [...]
> 
> 
> The installer options  for dm-crypt in  De[vu,bi]an seem a bit outdated, or
> at least not the standard dm-crypt is providing.
> The maintainer is hopefully aware of that.

I mean the installers' maintainer('s) ... even this is normally not the place 
to ask for and just a rhethorical question here, sorry for OT. 
Cannot speak for up-to-date-debian, wheezy was my last one.

> I would really like to know what others (esp. Arno and Milan) would 
> recommend to use as a mnimum for a today's new installation (in a distro's  
> installer), may it be plain or LUKS[2].

Nevertheless I'd like to hear about minimal recommendations of dm-crypt-folks 
in new installs.

Michael

Re: [dm-crypt] Mildly OT: LUKS and the Debian installer

[Jonas Meurer]

[-- Attachment #1.1: Type: text/plain, Size: 1695 bytes --]

Hello,

Am 23.05.2018 um 10:18 schrieb Diagon:
> Michael - I found the solution, which works on both Debian and Devuan.
> I was given some kind help by someone on the Debian user's list, which I
> am copying here:
> 
> ------------
> In the file “/etc/cryptsetup-initramfs/conf-hook”, there is a line
> “CRYPTSETUP” which is commented and/or has the default value “n”. If
> this is the case, replace the line with “CRYPTSETUP=y”. So, the next use
> of the command “update-initramfs” should solve your problem if I
> understood it correctly.
> 
> I think “CRYPTSETUP=y” is automatically set if you create an encrypted
> partition by following the installer’s instructions, but not when you do
> it outside these instructions.
> ----------

That's only partially correct. "CRYPTSETUP=y" is meant for special cases
where the crypsetup initramfs hook doesn't detect an encrypted device
that needs to be unlocked during initramfs. With setting "CRYPTSETUP=y"
you can enforce cryptsetup inclusion in the initramfs.

On most setups, this setting is superfluous. The cryptsetup initramfs
hook script automatically detects that cryptsetup is needed and includes
it into the initramfs.

Now that you have a working system with cryptsetup in the initramfs, I'd
be curious about the following:

If you comment out "CRYPTSETUP=y" in /etc/cryptsetup-initramfs/conf-hook
and recreate your initramfs with `update-initramfs -u` from your running
system, is cryptsetup still included in the initramfs? You can check
this by running the following command afterwards:

$ lsinitramfs /boot/initrd.img-$(uname -r) |grep cryptsetup

Cheers,
 jonas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [dm-crypt] Mildly OT: LUKS and the Debian installer

[Diagon]

On 05/23/2018 11:58 AM, Jonas Meurer - jonas@freesources.org wrote:
> Hello,
> 
> Am 23.05.2018 um 10:18 schrieb Diagon:
>> Michael - I found the solution, which works on both Debian and Devuan.
>> I was given some kind help by someone on the Debian user's list, which I
>> am copying here:
>>
>> ------------
>> In the file “/etc/cryptsetup-initramfs/conf-hook”, there is a line
>> “CRYPTSETUP” which is commented and/or has the default value “n”. If
>> this is the case, replace the line with “CRYPTSETUP=y”. So, the next use
>> of the command “update-initramfs” should solve your problem if I
>> understood it correctly.
>>
>> I think “CRYPTSETUP=y” is automatically set if you create an encrypted
>> partition by following the installer’s instructions, but not when you do
>> it outside these instructions.
>> ----------
> 
> That's only partially correct. [...]
> 
> Now that you have a working system with cryptsetup in the initramfs, I'd
> be curious about the following:
> 
> If you comment out "CRYPTSETUP=y" in /etc/cryptsetup-initramfs/conf-hook
> and recreate your initramfs with `update-initramfs -u` from your running
> system, is cryptsetup still included in the initramfs? [...]

Jonas - happy day!  I can report that it works, cryptsetup is still
there, and I can reboot into the system!

On not so happy a note, I can also report that when I tried to ask on
OFTC/#debian-boot whether my difficulty finding a way to install into
(1) a luks container that occupies a whole device or (2) use non-default
cryptsetup options, the response was not positive.  I did get one guy
working on calamares, who told me he thought it might work:

https://calamares.io/about/

Do you think I should try anyway to report a bug against the debian
installer?

> Cheers,
>  jonas