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