Displaying 20 results from an estimated 3000 matches similar to: "[PATCH v2 0/7] Windows BitLocker support."
2020 Mar 30
9
[PATCH 0/7] Support Windows BitLocker (RHBZ#1808977).
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
2020 Sep 17
13
[PATCH v3 0/8] Windows BitLocker support.
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.
2020 Jan 21
12
[PATCH 0/1] WIP: Support LUKS-encrypted partitions
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
2020 Jan 27
3
[PATCH v2 1/2] mltools, options: support --allow-discards when decrypting LUKS devices
---
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
+++
2020 Sep 17
2
Re: [PATCH v2 1/7] New APIs: cryptsetup-open and cryptsetup-close.
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
2020 Jan 22
3
[PATCH 1/1] sparsify: support LUKS-encrypted partitions
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
2020 Sep 07
5
[PATCH common v2 0/4] Windows BitLocker support.
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
2020 Mar 30
6
[PATCH common 0/4] options: Support Windows BitLocker (RHBZ#1808977).
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.
2020 Oct 09
3
Re: [PATCH v3 0/8] Windows BitLocker support.
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
2020 Oct 06
2
Re: [PATCH common v2 4/4] options: Ignore errors from guestfs_luks_uuid.
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
2020 Mar 30
0
[PATCH 1/7] New APIs: cryptsetup-open and cryptsetup-close.
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
2020 Sep 07
0
[PATCH v2 1/7] New APIs: cryptsetup-open and cryptsetup-close.
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
2020 Oct 07
2
Re: [PATCH common v2 4/4] options: Ignore errors from guestfs_luks_uuid.
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
2014 Feb 11
2
[PATCH] list-filesystems: Do not segfault if guestfs_btrfs_subvolume_list returns an error (RHBZ#1064008).
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
2018 May 02
6
[PATCH v7 0/6] daemon: list_filesystems: filter out block devices which cannot hold filesystem.
This patch series addresses comments after v6 series 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 the way we filter out LDM partitions.
daemon: list-filesystems: Filter out
2018 Jun 01
7
[PATCH v8 0/6] daemon: list_filesystems: filter out block devices which cannot hold filesystem.
v8: - Rebased on top of master.
v7: - Addresses comments after v6 series review.
v6: - Addresses comments after v5 series review.
- Large commit is splitted to more granular commits for better code review.
v5: - Addresses comments after v4 series review (part_get_mbr_part_type doesn't break original implementation in C).
- Rebased on top of master and little bit refactored for
2018 May 01
9
[PATCH v6 0/7] daemon: list_filesystems: filter out block devices which cannot hold filesystem
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
2011 Nov 10
5
[PATCH v2] Add tune2fs command.
The changes since the previous patch:
- safe ADD_ARG macro for adding arguments to a fixed size stack array
- support for testing functions that return RHashtable, ie. tune2fs-l.
- add tests that set (tune2fs) and get (tune2fs-l) various parameters.
- only one 'intervalbetweenchecks' parameter (in seconds)
Rich.
2019 Nov 29
8
[PATCH 0/1] Allow UUIDs for --key identifiers.
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
2023 May 19
3
[libguestfs PATCH 0/3] test "/dev/mapper/VG-LV" with "--key"
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