similar to: [PATCH common] options: Describe --key SELECTOR in a single file.

Displaying 20 results from an estimated 10000 matches similar to: "[PATCH common] options: Describe --key SELECTOR in a single file."

2019 Nov 26
4
[PATCH libguestfs 0/3] options: Describe --key SELECTOR in a single file.
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
2019 Nov 28
4
[PATCH v2 0/3] options: Describe --key SELECTOR in a single file.
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.
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
2018 Sep 19
5
[PATCH 0/2] RFC: --key option for tools
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 +-
2019 Nov 26
6
[PATCH options v2 0/3] options: Allow multiple and default --key parameters.
v1: https://www.redhat.com/archives/libguestfs/2019-November/msg00036.html
2019 Nov 12
4
[PATCH 1/2] options: Fixes and enhancements to --key parsing.
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.
2019 Nov 29
0
[common PATCH 1/2] options: rename key.device as key.id
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
2019 Nov 26
0
[PATCH common v2 1/3] options: Simplify selector parsing for --key options.
Refactor this code to use guestfs_int_split_string function which slightly simplifies it. This should have no effect. --- options/keys.c | 35 ++++++++++++++--------------------- 1 file changed, 14 insertions(+), 21 deletions(-) diff --git a/options/keys.c b/options/keys.c index f783066..74b5497 100644 --- a/options/keys.c +++ b/options/keys.c @@ -153,49 +153,42 @@ get_key (struct key_store
2014 Nov 02
3
[PATCH] customize: Add --ssh-inject option for injecting SSH keys.
This adds a customize option: virt-customize --ssh-inject USER[=KEY] virt-builder --ssh-inject USER[=KEY] virt-sysprep --ssh-inject USER[=KEY] In each case this either injects the current (host) user's ssh pubkey into the guest user USER (adding it to ~USER/.ssh/authorized_keys in the guest), or you can specify a particular key. For example: virt-builder fedora-20 --ssh-inject root
2020 Feb 12
3
[PATCH v2 0/1] tools: add '--blocksize' option for C-based tools
From: Nikolay Ivanets <stenavin@gmail.com> This patch depends on changes in 'common' sub-module posted here: https://www.redhat.com/archives/libguestfs/2020-February/msg00099.html v2: Almost the same as v1 except '--blocksize' option description is moved into a common submodule (similar to key-option.pod). v1 was here:
2020 Feb 11
2
[PATCH 0/1] tools: add '--blocksize' option for C-based tools
From: Nikolay Ivanets <stenavin@gmail.com> This patch depends on changes in 'common' sub-module posted here: https://www.redhat.com/archives/libguestfs/2020-February/msg00096.html Nikolay Ivanets (1): tools: add '--blocksize' option for C-based tools align/scan.c | 8 ++++++++ align/virt-alignment-scan.pod | 12 ++++++++++++ cat/cat.c
2019 Nov 26
1
Re: [PATCH common v2 3/3] options: Allow default --key parameters.
Hi Rich and Pino, Commenting after a test. I've installed a RHEL 7 virtual machine with 2 disks, using the graphical installer. During the installation, I selected the 2 disks as well as encryption checkbox. It asked me for only one password. After the installation, when the machine boots, it asks for the password (showing a device UUID) only once. When connected as root, I can see that there
2019 Nov 12
1
[PATCH] tests: luks: Test the --key options.
Requires this series: https://www.redhat.com/archives/libguestfs/2019-November/msg00036.html
2019 Nov 12
0
[PATCH 2/2] options: Allow multiple --key parameters and default keys.
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
2018 Sep 19
0
[PATCH 2/2] Introduce a --key option in tools that accept keys
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
2019 Dec 17
5
[PATCH 0/3] Various dist/build fixes
Fix one dist issue, and various builddir!=srcdir issues, also with the patch proposed in the Debian bug #946594. Patch #3 applies also to the virt-v2v repository, and will be committed there too (with references to the libguestfs commit). Pino Toscano (3): inspector: ship the actual test script tests: fix srcdir references build: fix make implicit dependencies on ml/mli files
2016 Sep 19
6
[PATCH 0/3] add crypto/LUKS support in some OCaml-based tools
Hi, this series refactors some guestfish code (not much), and exposes it via Common_utils, so it is possible to decrypt LUKS partitions when using virt-customize, virt-get-kernel, virt-sparsify, and virt-sysprep. This brings them closer in features with C tools. Most probably a couple more of other OCaml-based tools (virt-v2v to convert encrypted guests, and virt-builder to use encrypted
2019 Dec 16
3
[PATCH 0/2] tests: simpler way to use configure results
Add a single shell script to hold results of configure. Pino Toscano (2): build: add an empty config.sh tests: switch to config.sh for xmllint .gitignore | 4 +--- config.sh.in | 22 +++++++++++++++++++ configure.ac | 7 +----- ...luks.sh.in => test-virt-inspector-luks.sh} | 2 +-
2020 Sep 07
9
[PATCH v2 0/7] 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
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