similar to: [PATCH 0/1] Allow UUIDs for --key identifiers.

Hi, the following series adds a --key option in the majority of tools: this makes it possible to pass LUKS credentials programmatically, avoid the need to manually input them, or unsafely pass them via stdin. Thanks, Pino Toscano (2): mltools: create a cmdline_options struct Introduce a --key option in tools that accept keys builder/cmdline.ml | 2 +-

v1: https://www.redhat.com/archives/libguestfs/2019-November/msg00036.html

The first patch fixes a rather serious bug, the second patch allows multiple --key parameters and default parameters. There is a third patch to libguestfs which adds a test, coming up. I did not yet review and fix the documentation. I think we need to centralize it in one place because at the moment the same documentation for --key is copy/pasted all over the tools. Rich.

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

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

In the future it will be also something else other than the device name. --- mltools/tools_utils-c.c | 4 ++-- options/key-option.pod | 7 ++++--- options/keys.c | 8 ++++---- options/options.h | 8 +++++--- 4 files changed, 15 insertions(+), 12 deletions(-) diff --git a/mltools/tools_utils-c.c b/mltools/tools_utils-c.c index 3b80091..6c43b8d 100644 --- a/mltools/tools_utils-c.c

The majority of the tools have already options (--echo-keys & --keys-from-stdin) to deal with LUKS credentials, although there is no way to automatically provide credentials. --keys-from-stdin is suboptimal, because it is an usable solution only when there is just one device to open, and no other input passed via stdin to the tool (like the commands for guestfish). To overcome this

This way it is possible to specify the UUID of the LUKS device instead of the libguestfs device name to decrypt a device during the inspection. Make the usage of the new luks_uuid API conditional, so other projects using the common submodule do not require a libguestfs version bump. --- options/decrypt.c | 8 +++++++- options/key-option.pod | 4 ++-- options/keys.c | 4 ++--

This allows multiple --key parameters on the command line to match a single device. This could either be specified as: tool --key /dev/sda1:key:trykey1 --key /dev/sda1:key:trykey2 which would try "trykey1" and "trykey2" against /dev/sda1. And/or you can specify default keys which are tried against each device (after more specific keys fail), eg: tool --key

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.

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

v1 was here: https://www.redhat.com/archives/libguestfs/2019-November/msg00271.html In v2 I just updated the way paths are handled. Note this series requires the following patch to common which adds the common/options/key-option.pod file: https://www.redhat.com/archives/libguestfs/2019-November/msg00269.html Rich.

The libguestfs part of this change. Also a virt-v2v part will be needed. The first patch adds a new feature to podwrapper so that we can use __INCLUDE:file__ directives within the POD itself (instead of using --insert, and one day replacing that). The second patch shows how this change could be used for the included parts of the guestfish man page, including the non-English pages under

As discussed in the emails today, this is the third version addressing most points from the v1/v2 review. You will need to pair this with the changes in libguestfs-common from this series: https://www.redhat.com/archives/libguestfs/2020-September/msg00050.html Rich.

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

This allows multiple --key parameters on the command line to match a single device. For example: tool --key /dev/sda1:key:trykey1 --key /dev/sda1:key:trykey2 would try "trykey1" and "trykey2" against /dev/sda1. --- options/decrypt.c | 41 ++++++++++++++++++++++++++++++++--------- options/keys.c | 45 +++++++++++++++++++++++++++++++++++---------- options/options.h | 6

Enhance the output in machine parseable mode, by outputting all the messages of OCaml tools as JSON to the machine parseable stream. Related, although not strictly needed for this (and thus can be split if requested), is the addition of the fd format for the machine readable stream. Pino Toscano (4): common/mltools: move the code for machine readable up common/mltools: make sure machine

Enhance the output in machine parseable mode, by outputting all the messages of OCaml tools as JSON to the machine parseable stream. Related, although not strictly needed for this (and thus can be split if requested), is the addition of the fd format for the machine readable stream. Changes from v1: - use Obj.magic to convert int -> Unix.file_descr - add tests Pino Toscano (4):

--- mltools/tools_utils-c.c | 8 ++++---- mltools/tools_utils.ml | 6 +++--- mltools/tools_utils.mli | 2 +- options/decrypt.c | 5 +++-- options/inspect.c | 2 +- options/options.h | 2 +- 6 files changed, 13 insertions(+), 12 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 +++