[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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                      \


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]