On Tue, Sep 08, 2009 at 12:39:44PM +0200, Jim Meyering wrote:
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/.
okay, but this weren't imported yet :-)
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 \
Okay, cool :-) Thanks for clearing the issue ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/