Re: [libvirt] [PATCH 04/10] Secret manipulation step 7: Local driver
Daniel Veillard wrote:
On Mon, Sep 07, 2009 at 04:12:39PM +0200, Miloslav Trmač wrote:
> This implementation stores the secrets in an unencrypted text file,
> for simplicity in implementation and debugging.
>
> (Symmetric encryption, e.g. using gpgme, will not be difficult to add.
> Because the TLS private key used by libvirtd is stored unencrypted,
> encrypting the secrets file does not currently provide much additional
> security.)
>
> Changes since the fourth submission:
> - Rewrite storage mechanism to use one or two files per secret
> - Use the separate virSecretDef API for XML manipulation
> - Update for <usage type='volume'><volume/></usage>
> - Replace the "libvirt_internal_call" parameter of setValue() by
> VIR_SECRET_GET_VALUE_INTERNAL_CALL.
> - Fix comment in src/libvirt_private.syms
>
> * include/libvirt/virterror.h, src/virterror.c (VIR_ERR_NO_SECRET): New
> error number.
> * po/POTFILES.in, src/Makefile.am: Add secret_driver.
> * bootstrap: Use gnulib's base64 module.
> * src/secret_driver.c, src.secret_driver.h, src/libvirt_private.syms:
> Add local secret driver.
> * qemud/qemud.c (qemudInitialize): Use the local secret driver.
> ---
> bootstrap | 1 +
> include/libvirt/virterror.h | 1 +
> po/POTFILES.in | 1 +
> qemud/qemud.c | 3 +
> src/Makefile.am | 14 +
> src/libvirt_private.syms | 3 +
> src/secret_driver.c | 1060 +++++++++++++++++++++++++++++++++++++++++++
> src/secret_driver.h | 28 ++
> src/virterror.c | 5 +
> 9 files changed, 1116 insertions(+), 0 deletions(-)
> create mode 100644 src/secret_driver.c
> create mode 100644 src/secret_driver.h
>
> diff --git a/bootstrap b/bootstrap
> index 8b81e0e..885b299 100755
> --- a/bootstrap
> +++ b/bootstrap
> @@ -65,6 +65,7 @@ gnulib_tool=$GNULIB_SRCDIR/gnulib-tool
> <$gnulib_tool || exit
>
> modules='
> +base64
Argh !
.gnulib/lib/base64.c
"This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version."
Looks like GPL code not LGPL, I'm not sure we can actually use it,
Jim any opinion ?
We have some base64 code in libxml2 but it's not part of the
exported APIs
That module's license is LGPLv2+, so we're fine.
$ grep -A1 Lic .gnulib/modules/base64
License:
LGPLv2+
Yes, it can definitely be confusing if you don't realize
that the module file is where the *real* license is recorded,
and the comment in the code is automatically substituted
by gnulib-tool when it imports the code into your project.
So best is to look at files (post-bootstrap) in gnulib/, not .gnulib/.
Note that any patch that adds a module and passes the check in ./bootstrap
should be fine, because we've told gnulib-tool to enforce
libvirt's LGPLv2+ requirement:
$ grep -A1 '^$gnulib_to' bootstrap
$gnulib_tool \
--lgpl=2 \