[pkg-cryptsetup-devel] Bug#1141580: cryptsetup-initramfs: cryptroot-unlock non-interactive mode is buggy in case of trailing newline character

[Guilhem Moulin]

Control: severity -1 minor
Control: retitle -1 cryptsetup-initramfs: cryptroot-unlock should clarify how newline character from the passphrase are handled

On Mon, 06 Jul 2026 at 19:06:16 +0200, Vincent Lefevre wrote:
> My bug report refers to cryptroot-unlock, which is a different command.

It's a wrapper, the passphrase is processed like for

    ssh root at remote.com crypsetup --key-file=- /dev/sda1 name </path/to/key/file

(binary key file) or

    ssh -t root at remote.com crypsetup /dev/sda1 name

(interactive mode on a TTY).

> So, either one considers that the conventions from cryptsetup(8) apply
> (thus from stdin), and this is clearly an unexpected behavior;

No it is not.  However the proper manual quote should have been:

|    --key-file, -d file
|
|        Read the passphrase from the file.
|
|        If the name given is "-", then the passphrase will be read from
|        stdin. In this case, reading will not stop at newline characters.
|
|        […]
|
|        See section NOTES ON PASSPHRASE PROCESSING in cryptsetup(8) for
|        more information.

> Thus the only documentation is in the README.Debian.gz file Section 8
> "8. Remotely unlock encrypted rootfs" (note that this section doesn't
> have any reference to the cryptsetup(8) man page), which does not say
> anything about newline characters.

Again, feel free to suggest to suggest an addition or alternative
formulation.  BTS ping pong is not going to improve things.

> But I don't see the point in including a newline character in
> a passphrase, since such a passphrase will never be accepted
> in interactive mode.

There are valid use cases where the passphrase never needs to be entered
interactively and where the key file should be processed in full,
including newline characters and null characters.  For instance

    cryptsetup open --type plain --key-file=/dev/urandom \
        --key-size 32 […] /dev/sda1 crypt_swap

or

    head -c32 /dev/urandom >/path/to/my/binary/keyfile
    cryptsetup luksFormat --key-file=/path/to/my/binary/keyfile […] \
        /dev/sda1 crypt_root

would end-up being potentially very insecure if the keyfile would be
truncated early.

-- 
Guilhem.