On Wed, May 30, 2018 at 02:41:01PM +0200, Peter Krempa wrote:
Some code paths can't use the unencrypted secret. Add a helper
which
checks and sets up an encrypted secret only and reuse it when setting up
the secret to decrypt the TLS private key in qemuDomainSecretInfoTLSNew.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
src/qemu/qemu_domain.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index cda3d00f75..67bf2f6718 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -1399,6 +1399,49 @@ qemuDomainSecretInfoNewPlain(qemuDomainObjPrivatePtr priv,
}
+/* qemuDomainSecretInfoNew:
+ * @priv: pointer to domain private object
+ * @srcAlias: Alias base to use for TLS object
+ * @usageType: Secret usage type
+ * @username: username for plain secrets (only)
AFAIK we have been using username with AES secrets since:
commit a1344f70a128921e7fe7213da7c1afbc962fba9c
qemu: Utilize qemu secret objects for RBD auth/secret
Just drop the plain secret reference and resort to tautological documentation.
+ * @looupdef: lookup def describing secret
+ * @isLuks: boolean for luks lookup
+ *
+ * Helper function to create a secinfo to be used for secinfo consumers. This
+ * possibly sets a encrypted secret object.
sets up
+ *
+ * Returns @secinfo on success, NULL on failure. Caller is responsible
+ * to eventually free @secinfo.
+ */
Reviewed-by: Ján Tomko <jtomko(a)redhat.com>
Jano