similar to: [PATCH v3 0/8] Windows BitLocker support.

Original version linked from here: https://bugzilla.redhat.com/show_bug.cgi?id=1808977#c8 There is no change in the code in this series, but feedback from the original series was we shouldn't lose the error message in patch 7. When I tested this just now in fact we don't lose the error if debugging is enabled, but I have updated the commit message to note what the error message is in the

These commits, along with the associated changes to common: https://www.redhat.com/archives/libguestfs/2020-March/msg00286.html support the transparent decryption and inspection of Windows guests encrypted with BitLocker encryption. To do the BitLocker decryption requires cryptsetup 2.3.0 (although cryptsetup 2.3 is not required for existing LUKS use). It also requires a new-ish Linux kernel, I

The following patch attempts to implement sparsification of LUKS-encrypted partitions. It uses lsblk to pair the underlying LUKS block device with its mapped name. Also, --allow-discards was added by default to luks_open(). There are several potential issues that I can think of: 1) If and entire device is encrypted (not just one of more partitions), the lsblk trick might not work. 2) The

On Monday, 7 September 2020 11:43:54 CEST Richard W.M. Jones wrote: > This commit deprecates luks-open/luks-open-ro/luks-close for the more > generic sounding names cryptsetup-open/cryptsetup-close, which also > correspond directly to the cryptsetup commands. > > The optional cryptsetup-open readonly flag is used to replace the > functionality of luks-open-ro. > > The

--- mltools/tools_utils-c.c | 8 ++++---- mltools/tools_utils.ml | 6 +++--- mltools/tools_utils.mli | 8 ++++++-- options/decrypt.c | 5 +++-- options/inspect.c | 2 +- options/options.h | 2 +- 6 files changed, 18 insertions(+), 13 deletions(-) diff --git a/mltools/tools_utils-c.c b/mltools/tools_utils-c.c index 6c43b8d..1dcebc4 100644 --- a/mltools/tools_utils-c.c +++

For links to the original patch series, see: https://bugzilla.redhat.com/show_bug.cgi?id=1808977#c8 The original feedback was that ignoring errors from guestfs_luks_uuid would ignore legitimate errors from non-BitLocker disks, so I have modified this series so that errors are only ignored in the BitLocker case. As noted in the 4th patch there is no actual error in the BitLocker case, cryptsetup

From: Jan Synacek <jan.synacek@redhat.com> --- daemon/listfs.ml | 19 ++++++++++++++++--- daemon/luks.c | 9 +++++---- generator/actions_core.ml | 3 ++- gobject/Makefile.inc | 2 ++ inspector/inspector.c | 2 +- sparsify/in_place.ml | 2 +- 6 files changed, 27 insertions(+), 10 deletions(-) diff --git a/daemon/listfs.ml b/daemon/listfs.ml index

Support transparent decryption/inspection of Windows guests encrypted with BitLocker encryption. This won't make much sense without the associated libguestfs patches which I will post momentarily. (Submodules, ho hum) Rich.

On Mon, Sep 07, 2020 at 10:41:20AM +0100, Richard W.M. Jones wrote: >For BitLocker disks cryptsetup does not (yet? ever?) support reading >UUIDs and this function will fail. This does not matter here so just >ignore the error. > >Note there is no error message, cryptsetup simply returns with a bad >exit code: > >><rescue> cryptsetup luksUUID /dev/sda2

This commit deprecates luks-open/luks-open-ro/luks-close for the more generic sounding names cryptsetup-open/cryptsetup-close, which also correspond directly to the cryptsetup commands. The optional cryptsetup-open readonly flag is used to replace the functionality of luks-open-ro. The optional cryptsetup-open crypttype parameter can be used to select the type (corresponding to cryptsetup open

This commit deprecates luks-open/luks-open-ro/luks-close for the more generic sounding names cryptsetup-open/cryptsetup-close, which also correspond directly to the cryptsetup commands. The optional cryptsetup-open readonly flag is used to replace the functionality of luks-open-ro. The optional cryptsetup-open crypttype parameter can be used to select the type (corresponding to cryptsetup open

On Tue, Oct 06, 2020 at 03:06:54PM +0100, Richard W.M. Jones wrote: >On Tue, Oct 06, 2020 at 03:25:20PM +0200, Martin Kletzander wrote: >> On Mon, Sep 07, 2020 at 10:41:20AM +0100, Richard W.M. Jones wrote: >> >For BitLocker disks cryptsetup does not (yet? ever?) support reading >> >UUIDs and this function will fail. This does not matter here so just >> >ignore

On Fri, Oct 09, 2020 at 05:02:57PM +0200, Martin Kletzander wrote: > Basically what I did was create a small disk, create one partition > over the whole disk, then cryptsetup luksFormat the partition, open > it and format it with a filesystem (without any LVM). That is one > of the things you were adding support for, but it is not limited to > Windows Bitlocker setup, it can just

This combined patch series enables to decrypt LUKS devices on inspection by allowing the UUID of the LUKS device with the --key syntax. I opted for reusing the option instead of adding another one, as I think that device names and UUIDs are different enough that can be properly distinguished. A test for this (patch #4) can be applied only when the patches for common are applied, and the

Initial discussion is here: https://www.redhat.com/archives/libguestfs/2018-January/msg00188.html. v2 was posted here: https://www.redhat.com/archives/libguestfs/2018-January/msg00246.html. v3 comparing to v2 is just a rebase with slightly changed commits comments.

If calling guestfs_list_filesystems with a disk image containing a corrupt btrfs volume, the library would segfault. There was a missing check for a NULL return from guestfs_btrfs_subvolume_list. This adds a check, returning the real error up through the stack and out of guestfs_list_filesystems. This is potentially a denial of service if processing disk images from untrusted sources, but is

This patch series: 1. Addresses comments from v5 series review 2. Large commit is splitted to more granular commits for better code review. Mykola Ivanets (6): daemon: Changing the way that we detect if a device contains partitions. daemon: list-filesystems: Ignore partitioned MD devices. tests: list-filesystems command ignores partitioned MD devices. daemon: list-filesystems: Change

v2 was here: https://www.redhat.com/archives/libguestfs/2017-June/msg00008.html This series gets as far as a working (and faster) reimplementation of ‘guestfs_list_filesystems’. I also have another patch series on top of this one which reimplements the inspection APIs inside the daemon, but that needs a bit more work still, since inspection turns out to be a very large piece of code. Rich.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168506 This small set covers the new /dev/mapper/VG-LV "--key" ID format in the libguestfs LUKS-on-LVM inspection test. Thanks, Laszlo Laszlo Ersek (3): update common submodule LUKS-on-LVM inspection test: rename VGs and LVs LUKS-on-LVM inspection test: test /dev/mapper/VG-LV translation common

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168506 This small set covers the new /dev/mapper/VG-LV "--key" ID format in the LUKS-on-LVM virt-inspector test. Thanks, Laszlo Laszlo Ersek (3): update common submodule inspector: rename VGs and LVs in LUKS-on-LVM test inspector: test /dev/mapper/VG-LV translation in LUKS-on-LVM test common