The progress function remained silent unless the speed was higher
than minimal delta for double type in MiB/s. That could confuse
users that progress got stucked, but it in fact it was only slow.
Now wipe and reencryption progess functions can report speeds
in B/s up to GiB/s.
When resuming reencryption operation (both LUKS2 and legacy offline
code) speeds were incorectly calculated from whole progress including
range already reencrypted in previous runs. Now we track speed only
for currently running session.
The JSON structures should not be printed by default to debug log.
This flag introduces new debug level that prints JSON structures
and keeps default debug output separate.
Move all messages to cryptsetup tools and print these
verbose messages:
- Key slot X unlocked.
- Key slot X created.
- Key slot X removed.
and
- Token X created.
- Token X removed.
Also print error, if unknown token is tried to be removed.
The function uuid_or_device is prone to a buffer overflow if a very long
spec has been defined. The range check happens against PATH_MAX, with
i being set to 5 (due to "UUID=" offset of spec), but "/dev/disk/by-uuid"
has been already written into device.
The difference between "/dev/disk/by-uuid" and "UUID=" is 13, therefore
the correct range check must happen against PATH_MAX - 13.
@@ -204,7 +204,7 @@ const char *uuid_or_device(const char *spec)
strcpy(device, "/dev/disk/by-uuid/");
The strerror_r call exists in POSIX and GNU variant,
if POSIX variant is used (like in musl libc replacement)
we cannot rely on char* pointer.
Fixes issue#237.
If password is entered through terminal (no keyfile specified)
and cryptsetup is compiled with --enable-pwquality, default
system pwquality settings are used to check password quality.