[libvirt] [PATCH 04/10] Secret manipulation step 7: Local driver

[Daniel Veillard]

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 at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/